<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel rdf:about="http://hdl.handle.net/1903/6">
    <title>DRUM Collection: Technical Reports of the Computer Science Department</title>
    <link>http://hdl.handle.net/1903/6</link>
    <description />
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://hdl.handle.net/1903/13946" />
        <rdf:li rdf:resource="http://hdl.handle.net/1903/13941" />
        <rdf:li rdf:resource="http://hdl.handle.net/1903/13700" />
        <rdf:li rdf:resource="http://hdl.handle.net/1903/13688" />
      </rdf:Seq>
    </items>
    <dc:date>2013-06-20T04:17:27Z</dc:date>
  </channel>
  <item rdf:about="http://hdl.handle.net/1903/13946">
    <title>SymDroid: Symbolic Execution for Dalvik Bytecode</title>
    <link>http://hdl.handle.net/1903/13946</link>
    <description>Title: SymDroid: Symbolic Execution for Dalvik Bytecode
Authors: Jeon, Jinseong; Micinski, Kristopher K.; Foster, Jeffrey S.
Abstract: Apps on Google's Android mobile device platform are written in Java, but are compiled to a special bytecode language called Dalvik. In this paper, we introduce SymDroid, a symbolic executor that operates directly on Dalvik bytecode. SymDroid begins by first translating Dalvik into mu-Dalvik, a simpler language that has only 16 instructions, in contrast to Dalvik's more than 200 instructions. We present a formalism for SymDroid's symbolic executor, which can be described with a small number of operational semantics rules; this semantics may be of independent interest. In addition to modeling bytecode instructions, SymDroid also contains models of some key portions of the Android platform, including libraries and the platform's lifecycle control code. We evaluated SymDroid in two ways. First, we ran it on the Android Compatibility Test Suite, and found it passed all tests except ones that used library or system routines we have not yet implemented. On this test suite, SymDroid runs about twice as slow as the Dalvik VM, and about twice as fast as the Java VM. Second, we used SymDroid to discover the (path) conditions under which contacts may be accessed on an Android app, and found it was able to do so successfully. These results suggest that SymDroid, while still a prototype, is a promising first step in enabling direct, precise analysis of Android apps.</description>
    <dc:date>2012-07-31T00:00:00Z</dc:date>
  </item>
  <item rdf:about="http://hdl.handle.net/1903/13941">
    <title>Hierarchical O(N) Computation of Small-Angle Scattering Profiles and their Associated Derivatives</title>
    <link>http://hdl.handle.net/1903/13941</link>
    <description>Title: Hierarchical O(N) Computation of Small-Angle Scattering Profiles and their Associated Derivatives
Authors: Berlin, Konstantin; Gumerov, Nail A.; Fushman, David; Duraiswami, Ramani
Abstract: Fast algorithms for Debye summation, which arises in computations performed in crystallography, small/wide-angle X-ray scattering (SAXS/WAXS) and small-angle neutron scattering (SANS), were recently presented in Gumerov et al. (J. Comput. Chem., 2012, 33:1981). The use of these algorithms can speed up computation of scattering profiles in macromolecular structure refinement protocols. However, these protocols often employ an iterative gradient-based optimization procedure, which then requires derivatives of the profile with respect to atomic coordinates. An extension to one of the algorithms is presented which allows accurate, O(N) cost computation of the derivatives along with the scattering profile. Computational results show orders of magnitude improvement in computational efficiency, while maintaining prescribed accuracy. This opens the possibility to efficiently integrate small-angle scattering data into structure determination and refinement of macromolecular systems.</description>
    <dc:date>2013-05-25T00:00:00Z</dc:date>
  </item>
  <item rdf:about="http://hdl.handle.net/1903/13700">
    <title>Memory Trace Oblivious Program Execution</title>
    <link>http://hdl.handle.net/1903/13700</link>
    <description>Title: Memory Trace Oblivious Program Execution
Authors: Liu, Chang; Hicks, Michael; Shi, Elaine
Abstract: Cloud computing allows users to delegate data and computation to cloud&#xD;
service providers, at the cost of giving up physical control of their&#xD;
computing infrastructure.  An attacker (e.g., insider) with physical&#xD;
access to the computing platform can perform various physical attacks,&#xD;
including probing memory buses and cold-boot style attacks.  Previous&#xD;
work on secure (co-)processors provides hardware support for memory&#xD;
encryption and prevents direct leakage of sensitive data over the memory&#xD;
bus.  However, an adversary snooping on the bus can still infer&#xD;
sensitive information from the memory access traces.  Existing work on&#xD;
Oblivious RAM (ORAM) provides a solution for users to put all data in an&#xD;
ORAM; and accesses to an ORAM are obfuscated such that no information&#xD;
leaks through memory access traces.  This method, however, incurs&#xD;
significant memory access overhead.&#xD;
&#xD;
In this work, we are among the first to leverage programming language&#xD;
techniques to offer efficient memory-trace oblivious program execution,&#xD;
while providing formal security guarantees.  We first formally define&#xD;
the notion of memory-trace obliviousness, and provide a type system for&#xD;
verifying that a program satisfies this property.  We then design a&#xD;
compiler that transforms a program into one that satisfies memory trace&#xD;
obliviousness.  To achieve optimal efficiency, our compiler aims to&#xD;
minimize the usage of ORAM whenever possible, and would partition&#xD;
variables in smaller ORAM banks (which are faster to access than larger&#xD;
ORAM banks) without risking security.  We use several example programs&#xD;
to demonstrate the efficiency gains our compiler achieves in comparison&#xD;
with the naive method of placing all variables in the same ORAM.</description>
    <dc:date>2013-02-06T00:00:00Z</dc:date>
  </item>
  <item rdf:about="http://hdl.handle.net/1903/13688">
    <title>The compiler for the XMTC parallel language: Lessons for compiler developers and in-depth description</title>
    <link>http://hdl.handle.net/1903/13688</link>
    <description>Title: The compiler for the XMTC parallel language: Lessons for compiler developers and in-depth description
Authors: Tzannes, Alexandros; Caragea, George C.; Vishkin, Uzi; Barua, Rajeev
Abstract: In this technical report, we present information on the XMTC compiler&#xD;
and language. We start by presenting the XMTC Memory Model and the&#xD;
issues we encountered when using GCC, the popular GNU compiler for C and&#xD;
other sequential languages, as the basis for a compiler for XMTC, a&#xD;
parallel language. These topics, along with some information on XMT&#xD;
specific optimizations were presented in [10]. Then, we proceed to give&#xD;
some more details on how outer spawn statements (i.e., parallel loops)&#xD;
are compiled to take advantage of XMT’s unique hardware primitives for&#xD;
scheduling flat parallelism and how we incremented this basic compiler&#xD;
to support nested parallelism.</description>
    <dc:date>2011-02-18T00:00:00Z</dc:date>
  </item>
</rdf:RDF>

