Decentralized Information Flow Control (DIFC) [24] is an approach to security that allows application writers to control how data flows between the pieces of an application and the outside world. As applied to privacy, DIFC allows untrusted software to compute with private data while trusted security code controls the release of that data. As applied to integrity, DIFC allows trusted code to protect untrusted software from unexpected malicious inputs. In either case, only bugs in the trusted code, which tends to be small and isolated, can lead to security violations.We present Flume, a new DIFC model and system that applies at the granularity of operating system processes and standard OS abstractions (e.g., pipes and file descriptors). Flume eases DIFC's use in existing applications and allows safe interaction between conventional and DIFC-aware processes. Flume runs as a user-level reference monitor on Linux. A process confined by Flume cannot perform most system calls directly; instead, an interposition layer replaces system calls with IPC to the reference monitor, which enforces data flow policies and performs safe operations on the process's behalf. We ported a complex Web application (MoinMoin wiki) to Flume, changing only 2% of the original code. The Flume version is roughly 30-40% slower due to overheads in our current implementation but supports additional security policies impossible without DIFC.

No abstract

RESIN is a new language runtime that helps prevent security vulnerabilities, by allowing programmers to specify application-level data flow assertions. RESIN provides policy objects, which programmers use to specify assertion code and metadata; data tracking, which allows programmers to associate assertions with application data, and to keep track of assertions as the data flow through the application; and filter objects, which programmers use to define data flow boundaries at which assertions are checked. RESIN's runtime checks data flow assertions by propagating policy objects along with data, as that data moves through the application, and then invoking filter objects when data crosses a data flow boundary, such as when writing data to the network or a file.Using RESIN, Web application programmers can prevent a range of problems, from SQL injection and cross-site scripting, to inadvertent password disclosure and missing access control checks. Adding a RESIN assertion to an application requires few changes to the existing application code, and an assertion can reuse existing code and data structures. For instance, 23 lines of code detect and prevent three previously-unknown missing access control vulnerabilities in phpBB, a popular Web forum application. Other assertions comprising tens of lines of code prevent a range of vulnerabilities in Python and PHP applications. A prototype of RESIN incurs a 33% CPU overhead running the HotCRP conference management application.

Some web sites provide interactive extensions using browser scripts, often without inspecting the scripts to verify that they are benign and bug-free. Others handle users' confidential data and display it via the browser. Such new features contribute to the power of online services, but their combination would allow attackers to steal confidential data. This paper presents BFlow, a security system that uses information flow control to allow the combination while preventing attacks on data confidentiality.BFlow allows untrusted JavaScript to compute with, render, and store confidential data, while preventing leaks of that data. BFlow tracks confidential data as it flows within the browser, between scripts on a page and between scripts and web servers. Using these observations and assistance from participating web servers, BFlow prevents scripts that have seen confidential data from leaking it, all without disrupting the JavaScript communication techniques used in complex web pages. To achieve these ends, BFlow augments browsers with a new "protection zone" abstraction.We have implemented a BFlow browser reference monitor and server support. To evaluate BFlow's confidentiality protection and flexibility, we have built a BFlow-protected blog that supports Blogger's third party JavaScript extensions. BFlow is compatible with every legitimate Blogger extension that we have found, yet it prevents malicious extensions from leaking confidential data.

Abstract²3D TSV technology will soon be widely available and consumer products with embedded TSVs will be the norm rather than the exception. The roadmap envisioned by most for 3D development shows CMOS image sensors and TSVs as mainstream items in 2009 with heterogeneous stacked systems and logic-on-memory following in 2010 and 2011. By 2015, we expect to see complex embedded devices combining sensors, CPUs, and memories. This roadmap is, however, conditioned on the appropriate 3D design software being available. We present the fundamental elements required for a true 3D design flow. We discuss the requirements for standards, design for manufacturing and test guidelines, and WRROV QHHGHG WR VROYH WRGD\ ¶V DV ZHOO DV WRPRUURZ ¶V SUREOHPV. Alongside the 3D technology roadmap we propose a 3D EDA roadmap that will have to be followed in parallel if progress is to continue at the anticipated pace. I. THE 3D PRODUCT ROADMAPOne thing is clear today: we are no longer in an era where 3D integrated devices are just academic research curiosities or a dream of the future. Commercial products with Thru-Si Vias (TSVs) are being manufactured in volume today for cellphone imagers [1], [2]; and many other products are in the planning / prototyping stages for release in 2010 / 11. Figure 1. 3D TSV Product RoadmapSeveral versions of the 3D product roadmap have appeared in the press in recent years [3]. We offer a simplified vision in Figure 1 based on the major trends that we see developing. For simplicity, we leave out of this diagram the 3D System-InPackage (SiP) components that will progress into 3D-TSV systems. It is obvious that industry will transition to a new technology only when it cannot remain competitive with the one it is currently using. This has happened in the case of CMOS imagers where the TSV package enables the production of ultra-scaled down camera module sizes²(savings of up to 1.6 mm in X and Y and up to 400 Pm in Z height in one case [1])²with increased reliability. The next major product releases will be in the mobile and multi-media areas. 3D integration of IP components from heterogeneous technologies will speed time-to-market and offer cost savings over retooling and recharacterizing new technology nodes. In many of these applications, transistor leakage is such a performance problem that it is not clear that transitioning to 22nm will offer any economic or performance advantages. Prototype production of several such devices has already been announced. Commercial production will follow in 2010.Logic-on-memory devices, including FPGAs-on-memory, are next in line for production. The only question is whether it will be in 2011 or 2012 that we will start seeing them in volume applications. Beyond 2013 the crystal ball is a little bit cloudier as to ground-breaking product releases. We will certainly see improvements in the afore-mentioned systems and will probably also see other smaller-market applications jump on the TSV bandwagon once the technology is widely available to fabless companies. One thing that ...