Though these rivalries have existed for years, the internet has given them a new lease of life, in the hands of pure, unabashed saddos. Usenet has been the site of a proxy war, pitting Glasgow Airport against its rival in Edinburgh. The revision history for the Glasgow article on Wikipedia shows frequent changes in the population column, as well as the recent deletion of the comment, “Glasgow is the largest city in Scotland and all the more mysteriously is not the capital. Edinburh the second largest city in Scotland is the capital.” I can even remember reading one message board post where the author had counted the number of A-roads in each city and concluded that, having more, Glasgow was the more important.
In the interests of full disclosure, I must admit that I did once subscribe to both alt.airports.uk.glasgow and the edit feed for the city’s Wikipedia article. But having lived first in Edinburgh, now in England, I’ve become more laid back in my civic pride. Until today, that is.

A BBC news article reported on fears during the Cold War that a nuclear strike would have a grave effect on the nation’s tea supply. It mentioned that, for the purposes of planning:

the Ministry of Food listed London, Birmingham, Merseyside, Manchester and Clydeside [Glasgow] as H-bomb targets.

Tyneside, Teesside, Leeds, Sheffield, Hull, Derby, Purfleet in Essex, Southampton, Portsmouth, Bristol, Plymouth, Cardiff, Coventry and Belfast were named as A-bomb targets.

And all I could think was, ‘Ha, take that, Edinburgh….’

I am a little worried, however. Like just about everyone to whom I’ve talked, I’m hoping for a Democrat in the White House next year, and I’ve been following the primaries intently. But some of the recent pronouncements on trade have troubled me a little. So I’m hoping that, by writing something so naïve and ill-informed as this, someone will come out of the woodwork and tell me where I’m going wrong. Okay, here goes.

Let’s start by assuming that we’re all liberals. We probably want Barack Obama to be the next president, but maybe we’d rather it was Hilary Clinton. Either way, for the purpose of this discussion, it doesn’t matter.

We want things to be better for people in developing countries. To a first approximation, this could mean raising the standard of living in these countries by alleviating poverty. One way of doing this would be to spend more money in these countries. (Is this not why we’re all drinking fair-trade coffee, and eating fair-trade chocolate? Actually, scratch that, as I’m not convinced that the fair-trade movement doesn’t suffer from the exact same problems as what I’m about to describe. And sorry for the double-negative there.)

We are more likely to spend money in a country if we have free trade with that country, than if prices for goods from that country are inflated by duties or tariffs. We ensure free (or, perhaps more accurately, “freer”) trade by making free trade agreements with other countries.

So it’s heartening that, sometimes at least, both Obama [1] and Clinton [2] have supported NAFTA, which enables free trade between the US, Canada and Mexico.

Except, there’s a problem: free trade can cost jobs, especially manufacturing jobs in countries where the standard of living is so high that it is uneconomical to pay workers a living wage, when the same output could be obtained at a fraction of the price from one of our trading partners.

Especially jobs in traditionally blue-collar states like Ohio, where voters go to the polls today. And, therefore, both Clinton [3] and Obama [4] have attacked the other for supporting NAFTA, at the expense of American jobs.

So I have three questions:

• Which of the above assumptions is incorrect?
• I’d like to believe in Obama’s message of hope and change, but does this change stop at US border?
• If, as is now being reported, at least one of the candidates is engaging in disingenuous political posturing when making these statements [1] (and I’d be surprised if his opponent wasn’t also doing the same), then why should we believe in the rest of the rhetoric that goes along with it?

Now, I’m not an idealist, but I don’t particularly enjoy being cynical. Indeed, I hope I’ve made a mistake somewhere above, and someone will come along and correct me. However, it seems that, in an election that will probably be won on the strength of aspirational oratory, we should be especially critical of what is said.

Storage

DejaView: A Personal Virtual Computer Recorder

• The MEMEX Vision: We lack tools to store all of our books, records and communications quickly and with great flexibility. (Vannevar Bush.) We need to archive, search, view and manipulate what we have seen. Web/desktop search is inadequate: no record of what we have seen but not saved.
• DejaView: PVCR that provides complete, transparent, fast recording of the desktop computing experience. Tivo for the desktop. Records display like a video (playback, browse, ff, rw); and text and context to use as an index.
• Display recording: transparent, efficient and full-fidelity. Uses a virtual display driver that can redirect the display anywhere: to the user (on the screen) and to persistent storage. Has a standard device interface, intercepting updates at the low level and logs all display updates.
• Text/context recording: naïve approach would be do to OCR on the framebuffer, which is too slow and inaccurate. Instead leverage accessibility infrastructure (screen reader technology), which is integrated in most standard GUI toolkits. Also provides useful contextual information: name/type of application, window in focus, special properties (e.g. menu text).
• Execution recording: be able to revive execution state at any time, including the entire desktop session, not just a single process, and it needs to be fast enough to save frequently without degrading user experience. Use a virtual execution environment that decouples the desktop from the underlying OS by interposing on the syscall API. Only saves the desktop state and not the entire OS, which cuts down on the size of the checkpoint. Requires some downtime for the application during saving and snapshotting the filesystem, which must be optimised for interactivity. Checkpoint rate must be limited to make the overhead manageable. Also avoid taking pointless checkpoints (like when the desktop clock changes). A checkpoint per second is sufficient granularity.
• On revival, use UnionFS to put a CoW R/W layer on top of the R/O checkpointed file system. Can therefore fork history.
• Evaluation: based on real implementation - overhead, impact on interactivity and storage requirements; and access to data (latency etc.). Ran a bunch of benchmarks, based on normal workloads, like web browsing, video playback, catting a large file to screen, doing a kernel build, or something in Matlab. Also evaluated based on real desktop usage by grad students.
• Little overhead for display or execution recording; 100% overhead for text recording; 125% for full recording when web browsing (due to a bug in Firefox’s accessibility). All other use cases have much less overhead. Checkpoint latency: 5ms to 22ms downtime; total checkpoint time from 80 to 200ms. Storage growth is very low for the real usage scenario (lower than a PVR with equivalent display resolution). Browse and search latency no more than 200ms, which is good enough for interactive use. Playback speedup about 200x for real usage. Session revive takes 1.5 to just over 4s.

Improving File System Reliability with I/O Shepherding

• Storage systems are becoming complex, which can lead to complex failures. Want to manage disk and individual block failures. Addressed by checksumming, parity, mirroring, versioning, etc. However, these techniques are insufficient, and poorly understood (unlike performance and consistency). There is no good strategy in commodity FSs, only coarse-grained policies.
• Reliability treatments are diffuse and inflexible. Different apps require different policies (e.g. desktop workload versus web servers).
• I/O shepherd: localised, flexible policies for different types of storage. e.g. Mirroring for archival data, checksumming for scientific data, or different levels of protection based on the quality of the drive. These policies can be composed.
• I/O shepherding layer interposed between the FS and the disk subsystem. Includes >=1 policy tables, linking to policy code, policy primitives and policy metadata.
• Policy table: for specifying policies. Different kinds of block types and volumes, and levels of reliability and importance. So we have a write policy and read policy for each block type (like a function pointer); and a policy table for each volume (or mount point?).
• Policy metadata: need remapping, mirroring and sanity checking. Must be integrated with the FS. Also need I/O Shepherd Maps, to identify e.g. mirror locations.
• Primitives and Code: want to make reliability management simple. Primitives like “Checksum”, “Parity”, “Sanity Check”, “Allocate Near”, “Allocate Far”. These are then composed into a full policy, in the policy code.
• Challenge is to keep the new data and metadata consistent in the presence of crashes. Need consistency management.
• CrookFS: ext3 with shepherding capabilities. 900LOC changes to the OS, and 3500LOC for the shepherding infrastructure. Small overhead. Integrates reliability policy with journalling: execute policies during checkpoint.
• However, we can’t run e.g. remapping during checkpointing, because the checkpoint might fail, leaving us in an inconsistent state. If we keep the remap table in memory, the remap succeeds, but the program crashes before we can sync the table, we have the disk in an inconsistent state. At present, there is no consistency for any checkpoint recovery that changes state. Consistent reliability with the current journalling system is impossible!
• Thus we need “chained transactions”, which says that only after a chained transaction (updating the remap table) can the previous transaction (doing the remapping) be released. This fixes the flaw in journalling. It is repeatable across crashes, as long as we have idempotent policies.
• Evaluation: [see the paper].

Generalized File System Dependencies

• A new architecture for constructing file systems, using the “generalised dependency abstraction”.
• e.g. for consistency, we must keep FS consistent after every write, by, e.g. journalling. However must tradeoff durability features against performance. A file system must pick one tradeoff, but why can it not be extensible? This is difficult because it’s difficult to implement, complicated due to caches, and because correctness must be maintained.
• What is a simple, general mechanism for implementing any consistency model? The “patch” abstraction in their implementation, Featherstitch.
• Featherstitch contributions: the patch and patchgroup abstractions (explicit write-before abstractions, and FS-agnostic). Replaces Linux’s FS and buffer cache layer with implementations of ext2 and UFS. Journalling, WAFL and soft updates implemented just by using patch arrangements.
• Patches: a disk data change and any dependencies it has on other disk data changes. Includes some undo data. The dependency says which data must be written by which others. Benefits of this are to separate write-before specification and enforcement, and makes these relationships explicit. Inspired by soft updates, but don’t enforce a particular FS and consistency model.
• Example of rename: involves adding a directory entry and removing the old one. So we could write the source with the removed entry, then write the new entry. But what if we crash in between?
• Soft updates: inc ref count for the file inode, then add the new dirent, then remove the old dirent, then dec the ref count. However, this has a cyclic dependency for block updates. But, in patches, this is not a cycle. So we can do the increment patch, then do the other patches, with no cycle.
• Also showed how this would be done with journalling and WAFL: somewhat more complicated.
• Patchgroups: arise from application-defined consistency requirements. Commonly just syscall to the buffer cache (fsync, sync), or depend on the underlying FS. Instead, the patch interface is extended to user space, using patchgroups, which enables the specification of write-before requirements between syscalls. Can make things more efficient by not doing a bunch of syncs.
• Patch optimisations: massive dependency graph between patches even when allocating a few blocks for a new file, and so patches must have a lightning-fast implementation. Main primary overhead is unused undo data (150% overhead on some benchmarks). How do we detect where this is unused? Theorem is that undo data is only necessary when there are block-level cycles. So we should specify all dependencies when creating a patch.
• Next: the patch data structures take a large amount of memory. Therefore try to merge them, i.e. if they are on the same block (hard patch merging) and when they overlap. There are several other optimisations in the paper!
• Evaluation: measure optimisation effectiveness, compare with ext2 and ext3, check consistency, and run a benchmark (UW IMAP).
• The optimisations are successful in reducing the number of patches, system time and undo data overhead.
• Comparison with Linux: Featherstitch is between 19 and 26% slower at the PostMark benchmark. It’s faster on other benchmarks, where differences in the block allocation strategy outweigh the overhead.
• Consistency correctness: under random crashes, is the FS consistent. Works on Soft updates, Journalling as expected.
• Benchmark: moving 1000 messages from one IMAP folder to another. Patchgroups are much faster than using fsync.

Operating System Security

Information Flow Control For Standard OS Abstractions

• Problem: vulnerabilities in websites can lead to exploits. Solution: decentralised information flow control (DIFC). Example: admin wants to secure web app that handles secret and non-secret data. Use a “declassifier” which decides who gets to see what data. User authenticates to the declassifier then passes all requests through it. Even a bug in the webapp cannot leak data, because the declassifier makes the final decision on who can see what. So why is nobody using this, if it’s so good?
• Too hard to write the declassifier, requires smart people to develop all aspects of the system. Label systems are complex. Programming with DIFC can lead to unexpected behaviour. And it prevents the reuse of existing code, such as commodity operating systems.
• Unexpected behaviour: unreliable communication between two processes of different security types; mysterious failures when a secret process elevates the security of another process, and therefore prevents it from continuing with a task such as writing to an unsecure file (so that it can’t leak data from the secret process).
• Solution: Flume to solve DIFC problems (user-level DIFC on Linux with a simple label system, and glue between Unix API and labels). Then develop an application and evaluate it. Goal: want to be able to install this on existing machines using a apt-get.
• Uses system call delegation which forwards system calls to a user-level Flume reference monitor.
• Three process classes: confined (all syscalls go through refmon), Flume-oblivious (with no access to secret data), and unconfined/mediators (a mix of the two).
• Simple label system: each process gets a secrecy label which summarises the categories of data that a process is assumed to have seen. (e.g. Financial Documents, HR Documents.) Single category is a tag; set of tags is a label. Any process can add any tag to its label, but it cannot remove it without special privileges. A process can create a new tag, and is given the ability to declassify it (and hence remove it from its secrecy label).
• Communication rule: process p can send to q if p’s label is a subset of q’s label.
• Endpoints: intermediaries between processes for communication (per file-descriptor?), which can be labelled independently from the processes, and which declassify data. This is only possible if the owning process is able to declassify a tag in the secrecy label of the endpoint (better specified in set notation). A process can have many endpoints. This addresses some of the mysterious failures by eagerly revealing errors (which would violate the endpoint invariant).
• Example application is the Python-based MoinMoin wiki (100KLOC). 43 instances of the same check to see if the current user is able to access a bit of data, which have led to bugs, and plugins further complicate this. Instead add a 1KLOC declassifier. TCB is server + declassifier. Untrusted code is the Wiki plus any plugins.
• Apache is Flume-oblivious. Declassifier is a mediator. MoinMoin is confined, i.e. must syscall through the refmon.
• Results: Flume allows the adoption of existing Unix software: just 1% of MoinMoin had to be changed (no change in Python interpreter or Apache). By using Flume, two ACL bypass bugs were solved automatically. Performance is within a factor of 2.
• Limitations: bigger TCB than HiStar or Asbestos (Linux stack + 22KLOC refmon). Disk quotas are a covert channel.
• Q: On the example showing how endpoints are made, and secrecy labels may be changed, what if a malicious plugin attempts to perform declassification? This isn’t a problem, because, if the secrecy were critical to other applications, it wouldn’t be able to declassify the tag (because the tag would have been created by another application). Untrusted software would not have the elevated privilege to declassify tags.
• Q: Can the described policies be implemented inside SELinux? For a single application, probably yes, but the policies would become complex if it were possible to add applications to the change. Fluke simplifies system administration and transfers these decisions to the content provider.

SecVisor: A Tiny Hypervisor to Provide Lifetime Kernel Code Integrity for Commodity OSes

• Kernel rootkits: malware inserted in OS kernels to avoid detection by user-level scanners. Becoming increasingly common in the wild. DMA-based attacks are becoming common. Current (user-space) security tools are insufficient because they assume kernel integrity, and cannot find all attacks (as they are detection-based).
• Aim: a hypervisor that prevents injected code from executing at kernel privilege. Permit only user-approved code to execute a kernel privilege, based on a user-specified approval policy. Goals: security and ease of porting (not performance).
• ~1100LOC hypervisor, that operates at a ring below the kernel, but doesn’t attempt to do anything with hardware. Enforces approved code execution in kernel mode, which holds over system lifetime.
• Assumes: attacker can perform all attacks except HW attacks against CPU and memory. Can modify memory contents, perform DMA writes and modify system firmware. Can also have knowledge of 0-day kernel exploits. Single CPU with SVM or VT. Executed in 32-bit mode without the use of self-modifying code. No vulnerabilities in SecVisor (going to formally verify that).
• Require: constrained instruction pointer, which should be within approved code regions whenever CPU is in kernel mode. Approved code regions must be immutable, and so cannot be modified by an attacker.
• Constrained IP: kernel mode entry should set IP to being within approved regions. IP must remain within approved regions as long as we stay in kernel mode. Each kernel mode exit should set the CPU privilege level to user mode.
• Kernel Entry: exception/interrupt happens, looks up handler in the interrupt vector, and jumps to that IP in kernel mode. So all entries in the vector must point to approved code.
• During execution: place write XOR execute protection over kernel memory. But the problem is that the kernel and application share the same address space, so what if the attacker attempts to jump to user-space code, maybe by performing a buffer overrun. Solution: mark all application memory as non-executable (NX) on kernel entry.
• Intercepting user-to-kernel switch: all CPU entry pointers point to approved code; mark approved code regions as NX during user mode execution; all user-to-kernel switches raise exceptions.
• Kernel exit: intercept all kernel-to-user switches by using the exception that is raised by trying to execute NX code in user space after the switch back to user space.
• Immutable approved code: memory may be written by software executing on CPU or by DMA writes by peripherals. Approved code must be marked read-only. IOMMU protects from DMA writes.
• Implementation of memory protection: set protection independent of OS, using shadow (or nested) page tables. DMA exclusion vector to protect approved code.
• [I don’t think I need to include the explanation of shadow page tables.]
• Shadow PT is used to set memory protections. Approved code regions are set read-only in the SPT, and DEV prevents DMA writes. We also need to prevent aliasing of pages that are in the approved regions to non-approved VAs.
• Check entry pointers to ensure they contain VAs of approved code. GDT, LDT and IDT must be protected by shadowing these (to protect them from DMA writes).
• Overhead from intercepting all switches, and the shadow PT synchronisation and kernel PT checks. I/O-intensive workloads will perform poorly.
• Specint benchmarks show that SecVisor is about 2 to 5% slower than Xen (except for the gcc test, where it is much slower). Some optimisation has been done in the latest version.
• Q: Many past kernel exploits change the uid of user processes to overwrite kernel memory; does SecVisor address this? It doesn’t protect the integrity of kernel data structures. This is future work.
• Q: Performance effect of nested page tables? Shadow overhead goes away, but you still have to check and protect the kernel page tables.
• Q: Knowing everything you know about the system, how would you attack it as an intruder? Try to attack the TCB, but it is very small, so we don’t expect that this will be a problem.
• Q: Deal with loadable modules? Paper discusses this: you could have a hash-based approval policy, and SecVisor performs code relocation on behalf of the kernel.
• Q: How to protect the stable storage off which SecVisor is loaded? Use skinit, along with trusted computing techniques.

Secure Virtual Architecture: A Safe Execution Environment for Commodity Operating Systems

• Safe execution environment: such as that provided by Java or C#. Array indexing within bounds, no use of uninitialised variables, type safe operations, no dangling pointers, control flow follows semantics, etc.
• Commodity OSs do not use these kind of languages.
• Using as secure exec env would provide security, novel design opportunities and the ability to develop new solutions to higher-level security challenges (such as information flow policies, for example).
• Secure virtual architecture: interpose a compiler-based VM between a commodity OS and hardware. The VM provides a virtual instruction set architecture.
• Contributions: a compiler-based VM that can host a commodity OS. First to provide security guarantees for a complete commodity OS.
• Safety-checking compiler: similar to a C compiler which translates C into the virtual ISA (application level). Generates bytecode rather than native code. Bytecode has a type system which enables alias analysis in the VM.
• VM contains a safety verifier (which ensures that the compiler has done the right thing; may insert runtime checks), native code generator, and OS and memory safety runtime libraries. The compiler is outside the TCB; only the verifier and code generator are inside.
• Virtual ISA based on LLVM. Added OS-neutral operations (SVA-OS) that remove difficult to analyze assembly code and encapsulates privileged operations. Porting to SVA-OS is like porting to a new arch.
• Goals: maximise safety guarantees, minimise reliance on OS correctness, minimise changes to the kernel, and retain original kernel memory allocators.
• Guarantees: just like Java or C#, but type safety only for a subset of objects (due to the use of C code), and dangling pointers are harmless (rather than never used). These limitations do no compromise the other guarantees.
• Checks: load/store, bounds, illegal free and indirect call. Transforms: stack to heap promotion to deal with dangling pointers, and initialising memory. Need to track object bounds: use object lookups. Naïvely, the security verifier would add code to register all allocations in the VM metadata. All uses of these objects would have to follow a lookup to see if the access is within bounds. Can improve this by alias analysis, which groups objects into logical partitions, reducing overhead from between 400 and 1100% to between 10 and 30%.
• Implementation: ported Linux to the SVA ISA, compiled using LLVM. SVA-OS is a runtime library linked into the kernel. Guarantees safety of everything apart from the kernel memory management code and [blink and you’ll miss it, see the paper]. Around 5KLOC had to be changed in Linux.
• Memory safety overhead is less than 59% (for a web server benchmark). Latency is bad with many small transfers. 80% of exploits caught (the non-caught one was in a library that isn’t currently ported to the VM).
• Several performance improvements are possible, by changing the code, using smarter checks and smarter static analysis.
• Q: To what extent does the analysis equate to type safety? Do not guarantee that pointers point to the correct object, but that it is a valid object.
• Q: Must the number of memory pools be statically allocated? No. What if memory pools are allocated at run-time? Even then, its use is statically identifiable.
• Q: Is the overhead really small enough to make this approach suitable for use today? Improving the overheads is future work.

And, with that, I’m off to Portland for an afternoon of shopping in a city where £1 buys $2.03, and there’s no sales tax. See you when I get back!

Software Robustness

Bouncer: Securing Software by Blocking Bad Input

• Filters block bad input before it is processed. Low overhead and no false positives. Programs can keep running even when under attack.
• Performs symbolic execution of programs to perform analysis and generate input filters. Works on machine code.
• Pre-condition slicing: compute a subsequence of trace instructions, executing which is sufficient to create a vulnerability. Find instruction with vulnerability (e.g. call to sprintf), then move backwards through the trace, adding the instructions on which the vulnerable instruction depends.
• Deployment in a distributed scenario. When an exploit is found, run Bouncer, calculate an improved filter, and deploy this. Or run centrally on a cluster to find exploits in parallel.
• Nirvana generates traces. Phoenix implements slicing.
• Evaluated against four real vulnerabilities (including the Slammer worm). Ran experiment for 24 hours.
• Filters have no false positives. Found perfect filters for two vulnerabilities. Some false negatives for two others.
• Throughput is much closer to 100% when using filters, compared to having to restart on each attack. Can still maintain 80% throughput with 18000 attack probes per second.

Triage: Diagnosing Production Run Failures at the User’s Site

• What to do with a production run failure (send error report)? At present, we just send a core dump, which takes a lot of manual effort to diagnose. At the same time, these failures cause damage to end users.
• Reproduction is hard, because user environment is unique. Furthermore, there are privacy concerns.
• Core dumps tell you what the failure is. Bug detection tells you about some errors. Diagnosis is a means of tracing back to the underlying fault, but existing tools are offline (e.g. requiring programmer input).
• To diagnose: (i) need information about the failure (fault, error, propagation tree), but off-site techniques don’t work on-site; (ii) need guidance about what to do next, the kind of analysis to perform, the interesting variables to investigate (but there is no programmer to do this, so decisions must be taken automatically); (iii) need to be able to test “what-ifs”, such as changing input and seeing what happens, but most techniques focus on replaying the same thing.
• Triage enables on-site diagnosis, using systems techniques to make offline analysis tools useful on-site, addressing the three challenges. It introduces a new technique called delta analysis. Tested in a human study with real programmers and real bugs.
• Uses checkpointing and re-execution to capture the bug. Allows replaying the failure repeatedly, using different analysis tools. Little overhead in the normal-run case. Checkpoints every 200ms, keeping 20 previous checkpoints, in memory to lower overhead.
• Uses a human-like “diagnosis protocol”. Repeated replay enables an incremental diagnosis. e.g. If the bug doesn’t always repeat, it may be a race condition.
• But the replay isn’t identical: it can either be deterministic (plain), loose (tolerating some variance, such as the introduction of analysis tools which change the syscalls) or wild (including potentially large variations, maybe changing input or the code itself). Delta analysis is similar to diffing a pair of (successful and failing) runs. Triage doesn’t need to be safe when it replays execution: it only cares about why the bug happens.
• Failure analysis variety of methods (bounds checking, taint analysis, symbolic execution, etc.) and delta generation (rearrange allocations, drop inputs, mutate inputs, drop code(!)).
• Delta analysis: compute the basic block (of code) vector (1 if executed, 0 if not), and subtract them. The two closest runs are diffed (finding the edit distance and shortest edit script). So a basic block that differs could for example be to return NULL, and it is then dereferenced.
• Human study: 15 programmers from faculty, researchers and grad students. Measured times to repair bugs with and without Triage. (People got core dumps, sample inputs, instructions for how to replicate, and access to debugging tools.) The evaluation didn’t expect the participants to work out how to replicate the bug, and set a maximum time.
• 47% time saving on diagnosing real bugs, significant with probability of null hypothesis < 0.01%.

/* iComment: Bugs or Bad Comments? */

• Many bugs are due to mismatches between the code and the programmer’s assumptions. Such as assuming that a lock is held when a piece of code is executed. Comments express these assumptions. 20% of Linux is comments (excluding blank lines and copyrights), but they are not utilised by compilers or bug detection tools.
• However, comments are imprecise, compared to code, and cannot be tested. Therefore they tend to become less reliable as software evolves. Nevertheless, they are easier to understand for programmers. So wrong comments are likely to mislead programmers. Difficult to infer assumptions from source code (but see the MUVI paper from yesterday).
• Mismatches indicate either bugs or bad comments. Challenge is to understand the natural language of comments. NLP techniques are not enough: POS tagging (97% accurate), chunking (90%) and semantic role labelling (70%). But they assume correct grammar, which comments don’t always have.
• Therefore, also use machine learning, staistics and program analysis (with NLP). 1832 rules extracted, detecting 60 new bugs or bad comments (19 of these confirmed). Looking at call and locking bugs only.
• Focus on the comments that contain rules (rather than explaining code), as these are more likely to be inconsistent with the code.
• Example rule: must be held before entering .
• Comment classifier is trained using a decision tree building algorithm. Some manual training is required (at least once per topic).
• Validated using Linux, Mozilla, Wine and Apache, looking at lock- and call-related topics. Overall, 60 mismatches, 33 (12 confirmed) bugs, 27 (7) bad comments and 38 false positives, from 1832 rules. Training accuracy is between 90 and 100% (for lock-related comments). Cross-software accuracy is between 78 and 90% (saves the amount of training).

Distributed Systems

Sinfonia: A New Paradigm for Building Scalable Distributed Systems

• The protocols in current distributed algorithms are complicated, error-prone, and often difficult to understand. We want to avoid such protocols. Focus is on data centre systems, with small and predictable latencies, and occasional crashes. Focus also on infrastructure applications, like cluster file systems, lock managers and communication services.
• Sinfonia is a data sharing service, comprising a set of memory nodes which each export a linear address space (no structure imposed). Protocol design becomes the easier problem of shared data structure design. Minitransactions are used to access the memory nodes.
• Minitranscations have ACID properties, balance power and efficiency. Reduce network round-trips, but are still flexible and easy to use. Semantics: perform a bunch of compare items (for equality over an address range), if all of these match then retrieve the read items and perform the write items. Execution of the transaction is piggybacked on the two-phase commit process, to minimise round-trips.
• Commit coordinator runs at the application, which may crash, so a new two-phase commit protocol was necessary. Based on all memory nodes logging a “yes” vote, rather than the coordinator logging a “commit” decision.
• Applications: sinfoniaFS (a cluster file system) and sinfoniaGCS (a group communication service - i.e. a chatroom with ordered notifications).
• sinfoniaFS performs as well as LinuxNFS in the Andrew benchmark. sinfoniaGCS scales better than Spread.

PeerReview: Practical Accountability for Distributed Systems

• Fault in a distributed system with distributed state can lead to incomplete information. In the general case, there could be multiple admins with different interests (and possible malicious intent).
• Many faults are not fail-stop but instead change behaviour of a node. Dealing with general faults is difficult, because of a lack of control over the system. How can faults be detected or the faulty nodes identified. Then how do you convince others that a node is faulty (or not faulty) and must be fixed.
• Real-world systems rely on accountability. e.g. signed receipts, double-entry bookkeeping and auditing. These can be used to detect, identify and convince about faults.
• A fault is when a node deviates from expected behaviour. We want a system that generates a proof of misbehaviour against a faulty node. Difficult if we consider a fault that affects only a node’s internal state (requires an online trusted probe at each node). So we focus on observable faults: those that causally affect a correct node, and don’t require a trusted component.
• Verifiable evidence: a proof of misbehaviour or a challenge that a faulty node cannot answer.
• Accountability: whenever a fault is observed by a correct node, the system eventually generates verifiable evidence against a faulty node.
• Implementation: as a library, PeerReview. Assumes that nodes modelled as a collection of deterministic state machines, with each node holding a reference implementation of all state machines. Also that correct nodes can eventually communicate and nodes can sign messages.
• All nodes log all inputs and outputs. Each log is audited periodically by witnesses (a set of nodes for each node). If misbehaviour is detected, evidence is generated and distributed to other nodes.
• Log entries form a hash chain to prevent forgery of a log. Keeping multiple logs or forking logs is prevented by checking the signed hashes to ensure that a single linear log is kept. Faults in a log are recognised by replaying the state machine with the known inputs and checking outputs against the log.
• PeerReview guarantees that faults will be detected and good nodes cannot be accused.
• Applicability: NFS server in the Linux kernel, overlay multicast, and P2P email system. Deals with small latency-sensitive requests, large transfers, and complex, large and decentralised systems.
• Dominant cost depends on the number of witnesses per node.
• Normal P2P email scheme scales as O(log n) with n being the number of nodes. PeerReview can scale O((log n)^2) if you accept a 99.999% probability of detecting faults. (100% accuracy is prohibitive (linear, I think)).

Dynamo: Amazon’s Highly Available Key-Value Store

• Amazon architecture: loosely coupled SOA, with stateful services that manage their own state. Requirements on latency, availability and scale.
• State management is the primary factory affecting scalability and availability. Data is only ever accessed by primary key, in self-describing blobs, so key-value is better than RDBMS (don’t need a query optimiser, triggers, etc.). RDBMS scale up, not out, and (strong, transactional) consistency is less important than availability.
• Dynamo requirements: always writable (accept writes during failures), e.g. to add an item to a shopping cart must always be possible; user-perceived consistency (so can’t be too weak on consistency); performance with latency in the 99.9th percentile; low cost; incremental scalability; and tunable knobs for cost, consistency, durability and latency. No production-ready systems met these requirements
• Replicated DHT with consistency management, using: consistent hashing, optimistic replication, sloppy quorum; anti-entropy mechanisms; and object versioning.
• DHT is similar to Chord, using MD5 as the hash function. Clique for routing between replicas. Each storage node given many locations on the ring for load-balancing. Trade-off between balancing load and keeping membership tables concise.
• Configurable for different scenarios e.g. consistent, durable, interactive user state; a high-performance read engine; or a distributed web cache.
• Able to meet a 500ms SLA on latency, for the implementation of a shopping cart.
• Drawbacks: no indefinite scaling, not appropriate if transactional semantics required, more challenging to program than using ACID properties.

System Maintenance

Staged Deployment in Mirage, an Integrated Software Upgrade Testing and Distribution System

• Typically test on a couple of vendor machines, then a bunch of beta tests in the outside world, but despite this, the software will still fail on user machines in the outside world (due to dependencies, odd configurations, etc.). Mirage enables vendors to cluster outside world machines in terms of the their configurations/environment, so as to ensure coverage of beta testing before public release (and hence improve reliability). This reduces “upgrade overhead”: the number of machines that fail.
• Environment must be identified and fingerprinted, before clustering. Then the order and speed of deployment must be chosen by the vendor.
• In a cluster, all machines “behave identically wrt an upgrade”. Benefit depends on quality of clustering and the quality of testing.
• Identification: instrument the application to determine the resources (libraries, config files, environment variables and dependent applications) that it uses during a normal run. Filter out noise (log files, temp files and data) based on heuristics and vendor-provided rules. A library becomes a (name, version, hash of binary) tuple. The hash is used in case there are different builds, for example.
• Tradeoff between low upgrade overhead (few failures) and fast deployment. Choice between deploying in parallel to many clusters (fast, but high overhead), or sequentially (slow, but low overhead). Fixing a problem for one environment might also fix it for another environment (benefit of serialisation).
• Evaluated the quality of clustering (identification and clustering), and staged deployment (the upgrade overhead and deployment speed).
• Accurate identification: between 200 and 850 environment resources (on firefox, apache, php and mysql), between 0 and 7 vendor rules, yielded 0 errors in any case.
• Accurate clustering: 21 different environments, with 2 distros of linux, PHP and Apache and various MySQL configurations. Yielded 0 misplaced machines within 15 clusters. Varying the fingerprinting granularity can vary the number of clusters.
• Controlling the tradeoff: simulation with 100,000 machines, 3 problems and 2 staging protocols. Upgrade overhead reduced very significantly, with, in the worst case, a 25% increase in deployment time.
• Studying “real machines” and deployments is the subject of future work.

AutoBash: Improving Configuration Management with Operating System Causality Analysis

• Current approach to configuration management is to ask friends, search online, read manual, try potential solutions. Frustrating, time consuming and tedious! Hard to undo a wrong solution or know if the problem was solved. A solution can cause new problems.
• AutoBash: tries many solutions at once, provides an undo capability, explains to the user how it solves a problem and automatically runs regression tests.
• When a problem is detected, there are two modes: Replay mode which automatically searches for a solution; and Observation mode which helps the user to fix the problem. All the time, there is a Health monitoring mode.
• Observation mode: a modified bash where user tries to fix a problem by typing a command then testing if the app works, then possibly undoing the command and rolling back the command, before trying again. Has “predicates” which test if an application functions correctly and returns true iff the test passes. Idea is for application to be shipped with a testsuite of predicates. Speculator (SOSP’05) is used to perform process-level speculative execution, and make predicate testing safe (undoable). Shell provides a rollback command, used in conjunction with the speculative execution, to undo the attempted command.
• Regression testing is handled by running all predicates in some database. This can be slow, however, so causality tracking is used to find which predicates might be affected by a change.
• Tracking causality: Output set of kernel objects that an action causally affects, and Input set of kernel objects on which a predicate causally depends. If the output set of an action and input set of a predicate intersect, then the predicate must be checked. The output set can be tracked by syscall tracing, and then trimmed by excluding temporary objects (such as processes, or temporary files). Similarly, this can be done to determine the input set of a predicate.
• Generating a causal explanation: the important actions are the ones whose output sets intersect with the input sets of the newly-passing predicates.
• Replay mode: assume that vendors ship “common solutions” with their software, so that these may be automatically tested (safely, using speculative execution) in the background, while the user gets on with work.
• Evaluation: overhead of speculative execution and effectiveness of causality analysis? Looked at CVS, GCC cross compiler and webserver. Created 10 bugs and 10 solutions.
• Very little overhead (non-significant) of speculative execution. Causality analysis almost halves the total replay time, with a slight increase in the predicate testing time.

Energy

Integrating Concurrency Control and Energy Management in Device Drivers

• Concentrating on wireless sensor networks. Concurrency of I/O operations are considered (synchronous versus asynchronous). Energy management is considered in terms of the necessary power state of devices to perform I/O.
• The more workload information the app can provide the scheduler, the less energy needs to be used.
• Hard to tell OS about application workloads: API extensions for hints to energy management. Done for CPU voltage scaling and disk spin-down. Sensor networks need a unique solution, however: harsh requirements, small power source, and need to run unattended for periods ranging from months to years. 1st generation OSs push all decisions to the applications.
• ICEM: a driver architecture that automatically manages energy, implemented in TinyOS 2. New concept of Power Locks: split-phase (asynchronous) locks with integrated energy and configuration management. Dedicated, shared and virtualised drivers and a component library for building them.v Energy efficiency is 98.4% of hand-tuned implementation. Also much easier to program.
• Case study on the TMote platform: three interfaces to six total devices. Logging application with producer, which writes sensor samples out to flash every 5 minutes, and a consumer that sends all samples from flash over the radio every 12 hours. Code complexity of hand-tuned implementation is very complex: need to order the power-on and -off of each different device. ICEM hides these calls, greatly simplifying the code.
• Split-phase I/O operations: single thread of control, where read() call is given a callback, readDone(), that allows the driver to poke the application when it is done. These can then be scheduled efficiently, because the driver has information about what has to be done before it considers switching the device off.
• Virtualised driver: only a functional interface. Assume multiple concurrent users, buffering requests for concurrency management, and managing energy by looking at pending requests. Such drivers have longer latencies, because the underlying device has to have synchronous access. Suitable for high-level hardware (like a block device?)
• Dedicated driver: functional and power control interfaces. A single user only with no concurrency control and explicit energy management. Suitable for low-level hardware.
• Shared driver: functional and lock interfaces. Multiple users, explicit concurrency control (using the lock), and implicit energy management based on pending requests.
• Power locks: hardware-specific configuration and power interfaces, and a lock interface. Talk to a dedicated driver. First, request access to the lock, which powers on the underlying device and configures it and calls back the application (split-phase). Other locking requests are queued after the current user. Power down only happens when all pending lock requests have been fulfilled and released.
• Arbiter: performs concurrency control and queuing/scheduling (FCFS and round-robin). Configurator: calls h/w-specific configuration interface on the dedicated driver. Power Manager: powers down device when it falls idle, and powers it back up when a new lock request comes in (with immediate and deferred policies).
• Evaluation: comparing hand-tuned, ICEM, optimal serial and worst-case serial orderings, in the sensor logging application described above. ICEM performance very close to hand-tuned, and better than both serial versions.
• ICEM overhead is 5.60% of total sampling energy. Node lifetime for ICEM is between 98.4% and 100% of the hand-tuned version, as the sampling period is increased.

VirtualPower: Coordinated Power Management in Virtualized Enterprise Systems

• Two key benefits of integrated power management: power savings are proportional to cost savings, and cooling capability is proportional to rack utilisation. Information and capabilities exported ACPI have led to application-specific power management policies. How do we do this in the context of virtualisation?
• Problems: what should be exposed? Are there issues with isolation? Are there power benefits arising from resource sharing? VPM can give a 34% power improvement.
• Data centres have a heterogeneous collection of platforms. Virtualisation should abstract this (e.g. because of migration), but this is tricky with different power characteristics in the underlying hardware. The workload stays the same, so we should virtualise the power management states: therefore we can have a consistent view of manageability across migrations.
• What about isolation? Disassociate changes to virtual state from the management of the physical state: front-ends in DomUs, back-end in Dom0, the latter of which manages the physical state. Notion of soft scaling which allows the possibility of “scaling” a virtual CPU, which enables consolidation of soft-scaled virtual resources. (Two soft-scaled VCPUs on a single full-power CPU, but you might be able to turn off another physical CPU, for example.)
• VPM rules in Dom0 which control the physical PM. Virtualisation layer policies are driven by VPM state requests from the VMs, which makes an implicit feedback loop. Might need some learning algorithms to derive rules.
• e.g. Dom1 changes VPx state via a hypercall and creates a VPM event (comprising the VM soft state, and a shadow state (the physical manifestation of the current soft state). This leads to a new set of shadow states being calculated.
• Workloads: tiered web service (RUBIS) (Linux on-demand gonvernor); transactional workload (select policy based on the transaction processing rate and the amount of slack); web service with quality of information metric (Travelport (Worldspan)) (policy based on the QoI and processing time of requests across different client classes).
• Complex analysis has up to 4% degradation on throughput. Seems to work with multiple VMs too. [Lots of fairly convincing graphs but I think it’ll be necessary to take a good look at the paper to judge what we’re actually being presented.]

N.B. If you’re reading this through Facebook or are not a die-hard Computer Scientist, you might want to ignore it!

Web Meets Operating Systems

Protection and Communication Abstractions for Web Browsers in MashupOS

• Adding inline modules to a single page involves trusting those modules not to interfere with each other or snoop data (e.g. from Google cookie). Want multiple principals in the web browser for client mashups.
• “Same origin policy” is currently all or nothing: either no cross-domain interactions allowed (iframe) or external scripts run with the privilege of the enclosing page (included script). With latter, risk of cross-site scripting attack (Samy worm: 1 million MySpace users in 24 hours), leads to scripts being disallowed and flexibility being lost.
• Browser should be a multi-principal OS. Balance ease-of-use and security.
• Protect: memory (heap of script/DOM objects), persistent state (cookies) and remote data access (XMLHttpRequest).
• What if integrator (Google) is trusted to access provider (e.g. widget developer) content, but provider is not able to access integrator content? New sandbox and openSandbox tags for “unauthorised” content. Invoking code inside sandbox only happens after a setuid call. Put user input in a sandbox and so prevent XSS attacks.

AjaxScope: Remotely Monitoring Client-side Web-App Behavior

• Windows Live Local client-side codebase: 70kloc (1MB in size), 2855 functions, interacts with >14 backend services, and all this executes on the host, not in the cloud.
• Web 1.0 all done on the server then serves static content: developer has control over machine and can profile it or debug it. How does developer address bugs or performance issues when code is largely running on the client? And of course there are mashups….
• On-the-fly rewriting to add instrumentation, by a proxy between webapp and the client.
• Goals: performance optimisation, debugging, testing (code coverage and A/B tests), user interaction feedback (feature discovery etc.).
• No changes to original webapp or client-side browsers.
• Experiments tested prototype against 90 websites, including Google Maps, Live Local and 88 other sites.
• Adaptive instrumentation: don’t log every function with timestamps; instead profile whole script and, if it’s slow, drill down to discover the particular function that’s taking time (then recurse).
• Distributed instrumentation: monitoring for JS memory leaks by looking for runtime patterns indicative of a leak. Check all object assignments for potential cycles: involves an expensive heap traversal, which wouldn’t scale to all assignments. So give each user a random N% of the assignments to check.
• Need to address information protection: should it be possible for credit card information to be stored in the logging DB? At present, don’t instrument HTTPS pages, but in future could allow developers to mark state that should not be logged.

Swift: Secure Web Applications via Automatic Partitioning

• Web development methods lack security reasoning. Swift makes interactive web applications secure and easier to write. Write a single program in a single language, which is automatically split by the compiler. Rich security policies as declarative annotations. Attempts to optimise the partitioning for performance.
• For example, want to download state (e.g. a secret number in a guess-the-number game) and behaviour (input validation, checking the guess against the secret) to the browser to reduce number of server roundtrips, but (i) want to keep this secret from a malicious user, and (ii) preserve the integrity of any guess sent back to the server.
• Swift code looks like regular Java code with an event-driven GUI.
• Security policy on data denoted by labels with named principals (e.g. Alice->Bob == “Alice permits Bob to read”; Alice<-Bob == "Alice permits Bob to write"). e.g. int {server->server; server<-server} secretNumber; int {server->client; server<-server} numberOfTries;
• Endorsements after, say, a bounds check, allows a client-provided value to be trusted.
• Placement constraints (based on who can read and write), and architectural constraints (e.g. database access must be located on server).
• Performance optimisation: minimise number of network messages. Construct weighted control flow graph (with weights estimated by interprocedural dataflow analysis), then execute MIN-CUT/MAX-FLOW on it to find the optimal partitioning. (Slightly more subtle, since nodes could be placed on both the client and server: could for example replicate input validation for fast responsiveness at the client (if wrong) but proper integrity at the server.)
• Server keeps state about expected control flow to prevent client attempting to execute arbitrary server code by falsifying a message. Client cannot corrupt server-local variables because server does not accept (non-endorsed?) client-supplied values to update high-integrity variables.
• Evaluated by writing a suite of example applications and comparing the number of messages sent by the Swift-generated and hand-optimised versions of the apps.

Concurrency

TxLinux: Managing Transactional Memory in an Operating System

• Hardware transactional memory is a reality! Sun “Rock” chip supports it, and so should Solaris 10.
• Locks are hard (deadlock, priority inversion, etc.). Transactional memory in the OS benefits user programs and simplifies programming.
• Conventional wisdom maps lock_acquire and lock_release to tx_begin and tx_end, respectively. Transactionalising Linux this way took six person-years, mostly due to issues with I/O and idiosyncratic locking.
• Reject conventional wisdom and insist that locks and transactions must cooperate! Retain legacy code. Flexibility to aid performance: TM is good when contention is rare; locks are good when contention is high.
• Innovation: Cooperative Transactional Spinlock. Critical sections choose dynamically between locks and transactions. If csec attempts I/O then rollback and use a lock instead. (This took one person-month to implement on Linux.)
• Implemented as x86 extensions, using the Simics machine simulator. Benchmarks on pmake, bonnie++, MAB, (parallel) configure, and (parallel) find. Only kernel is using transactions, not user code. 2.5% speedup over Linux (16 CPUs); 1% speedup over Linux (32 CPUs).
• Scheduling-aware transactions to eliminate 100% of priority inversion: contention manager decides in favour of higher priority process.
• One pathological behaviour (in the Bonnie++ benchmark) which is caused by the exponential backoff in transaction retry.

MUVI: Automatically Inferring Multi-Variable Access Correlations and Detecting Related Semantic and Concurrency Bugs

• Variable Access Correlation: programs contain many variables which are not isolated. Correct programs consistently access correlated variables. (e.g. an array and the length of that array, in two variables; different views of the same information (number of packets and bytes received); different aspects of related information (RGBA values in a framebuffer); iterator in a data structure).
• Need to ensure consistent access (e.g. when updating array, must update length).
• If x and y are correlated, an access (read or write) to x is correlated with an access to y. So we can detect where a programmer forgets to access a correlated variable (e.g. initialise RGB but forget alpha). Or where two correlated variables are updated concurrently (leaving the possibility of reaching an incorrect state due to a race condition).
• Statistically infer access correlation based on variable access pattern in source code, assuming that a mature program is mostly correct. Correlation is inferred where variables commonly appear together, and seldom appear separately. Use static code distance between accesses.
• Frequent itemset mining to determine potentially-correlated variables. Every variable is an item. Every function is an itemset. The accessed variables, tagged with the type of item, is placed in the itemset. Flow-insensitive, inter-procedural analysis, considering globals and structure-typed variables. IPA means that callee accesses are incorporated in the itemset. This yields frequent variable sets.
• Post-processor prunes this set by identifying where items an a sub-itemset appear separately too many times, or are very popular (e.g. stdout and stderr). Then it categorises based on the type of access (read or write).
• Inconsistent update bug detection by getting all write(x)->access(y) correlations. Concurrency bug detection by looking for common locks surrounding different accesses to a set of variables. Look for where the variables are accessed without holding that lock.
• Approximately 13 to 19 per cent false positives on correlation inference. Analysis time takes on the order of two hours. Bad programming shows up even when it is not a bug.

Byzantine Fault Tolerance

Zyzzyva: Speculative Byzantine Fault Tolerance

• State of the art in BFT is too complex for system designers. Zyzzyva outperforms existing approaches, gives performance comparable to unreplicated services, and has overhead that approaches lower bounds.
• State machine replication to replicate failures. Two phases: agreement and execution. Agree on the request order (three-phase agreement), followed by execution.
• In Zyzzyva, replicas execute requests without agreement, so much less overhead. The output commit happens at the client. Only the client needs to know that the system is consistent, not the replicas. So client only commits if it can confirm that the system is consistent (if it can verify that the reply is stable).
• Verify the stable reply by using the request history. Replicas include request history in the replies. If all of the replies and histories match, then all replicas are in a consistent state, and we are done.
• What if there are failures? We can commit output if a majority of the replies and histories are available and match. Commit phase: the client sends the histories to the replicas, and if it receives a majority of acks, then it can commit.
• Same consistency guarantees as traditional BFT.
• A faulty client cannot block progress or compromise safety.
• Performance is at least twice as good as existing BFT methods, and about 35% of the unreplicated case (with no failures).

Tolerating Byzantine Faults in Database Systems using Commit Barrier Scheduling

• 50% of errors in DBMSs are “non-crash” errors.
• This is the first practical BFTDB
• 3f+1 replicas, protocol globally orders requests, replicas execute in order: no concurrency. We want to be able to extract concurrency in the database context.
• Introduce “Shepherd” into the architecture: centralised and cannot handle faults in this (but it’s small compared to the DB replicas). Many clients -> single shepherd -> many replicas. Need f+1 matching votes from the replicas.
• Pre-determine which statements conflict to extract concurrency. Difficult to inspect SQL.
• Commit Barrier Scheduling: run transactions first on the primary, then duplicate the ordering from the primary on the secondaries. Works best if primary is “sufficiently blocking”. Primary sends back result, shepherd responsible for running the same-ordered statements on the secondaries.
• For correct execution: execute that statements of a transaction in the same order, and all replicas commit transactions in the same order.
• This assumes a non-faulty primary! Concurrency on both primary and secondaries, but there is an increase in latency.
• Faulty secondaries are not a problem, because of voting. Faulty primary is a problem, because it could generate an invalid schedule for the whole system. Assuming faulty primaries are rare.
• Asymptotically, 17% performance penalty on MySQL or PassThrough scheme (measured in Transactions per second). But a 10x speedup on the serial case.
• Masked bugs by using heterogeneous vendors and heterogeneous versions. Found concurrency bugs in MySQL (now patched).

Low-Overhead Byzantine Fault-Tolerant Storage

• Block storage protocol that can tolerate arbitrary Byzantine faults with similar performance to systems that can handle crash-faults.
• Crash fault-tolerant (erasure-code based) storage performs much better than replicated BFT storage (for write bandwidth). So they introduce erasure-coded BFT storage, with a relatively small overhead over the CFT method (within 10% for sufficiently large writes).
• Write overhead = two rounds plus a cryptographic checksum. Read overhead = cryptographic checksum.

Attested Append-Only Memory: Making Adversaries Stick to their Word

• BFT protocols enforce linearisability and liveness on a replicated system, with up to 1/3 faulty replicas.
• Problem of servers equivocating to clients. Does preventing it help? Can it improve on the 1/3 bound? If so, how do we prevent equivocation?
• Introduce a trusted equivocation guard to prevent equivocation.
• Attested Append-Only Memory: a set of numbered logs, with sequence #, stored value, and crypto digest of entire log for attestation.
• Run A2M as a 3rd party service, in a process, in a virtual machine or even in the VMM, or even in a secure coprocessor (cf. IBM’s vTPM implementation). Different levels of isolation or sizes of TCB.
• Trustworthy systems are built from untrusted components. Looking at what trusted small components can be put together to make better systems.
• A2M is simple and easily implementable, and prevents equivocation. It has broader implications on structuring trustworthy systems.

Work in Progress

• GIGA+: Scalable Directories for Shared File Systems: FS used as a lightweight database of small files. Want scalability to billion-to-trillion entries, striped on many servers; 100K inserts/sec. Usually use fast, dynamic indexing structures, but are synchronised. GIGA+ is more parallel, with incremental growth over many servers, and high concurrency through minimal synchronisation. Client cache consistency is expensive, so GIGA+ uses stale partition-to-server maps, but without affecting the correctness of operations. Decentralised and concurrent indexing, using increasing prefixes of hashed filenames. Servers can then split partitions independently and in parallel.
• Sequoia: Prediction Trees to Support Network-Aware Applications: Virtual trees to provide properties of the network to support applications like “What is the server that can provide this file with the greatest bandwidth?” Predicts bandwidth and latency. Tree position yields coordinates in the network, which can be used to estimate distance and the quality of paths in the network. Free hierarchical partitioning of the network.
• Flexible, Wide-Area Storage for Distributed Systems with WheelFS: Can’t just use existing tools to make a cooperative web-cache (Apache caching proxy plus network file system). Cache can use old copies of data, and always can fall back to the origin. So why not tell the FS about this? Introduce semantic cues to help apps control behaviour in event of failure. Only one line change to make Apache distributed. Semantic cues embedded in the pathname. Useful for PlanetLab, Parallel Grid computations and Distributed make.
• Reforming Software Delivery using P2P Technology: Analysed managed service department at HP. An edge node spends 1.8 hours daily synchronising its image. Idea is to combine P2P technology and rsync. Large chunk sizes give low per-chunk overhead, but less opportunities to exploit similarity. Pure P2P is not feasible because different clients use different tools, and also want to avoid using customer bandwidth. Related to CDNs. Decentralisation makes security and optimisation hard.
• Ostra: Leveraging trust to thwart unwanted communication: i.e. spam, mislabeled videos on YouTube. Usual defenses don’t work because you can’t do Bayesian filtering on video. Ostra uses social networking trust relationships, which are assumed to be hard to form. If a source sends unwanted communication to a destination, the destination will cut off the source. For multi-hop transmission, the links along the path from source to destination are all penalised. No requirement of strong identities: can create a network of sybils, or use different identities for friends.
• Enabling BITE: High-Performance Snapshots in a High-Level Cache: Applications control when snapshots are taken, and can get and put objects that reside in pages. Does CoW to save storage. Provides time travel in a storage system. (BITE = Back In Time Execution.) Approach is virtualised, crash consistent and requires a Write-Ahead Snapshot invariant. High-level: database or file system, because lower level makes it difficult to achieve consistent application-requested snapshots. Therefore they sync from higher levels when a snapshot is requested. Need to make declaration of snapshots more efficient (currently transactional).
• Kernel Memory Management in Verified Small Kernels: Constructed a small, highly-assured microkernel. Formal assurance that the abstract model translates to the kernel code, which must be rigid. seL4 exports all memory allocation and freeing to the user, with no implicit allocations within the kernel. Something of a capability model. Formally proved spatial partitioning. Haskell prototype and C/C++ version of the kernel. Ongoing work to evaluate and refine the performance.
• The Case for DDoS Resistant Membership Management in P2P Systems: Malicious node M acts as index and says that a victim node is the source for a file (even though it is not), which, if there are millions of requests, could lead to DDoS. Exploitable mechanisms include: push-based mechanisms and the ability to have multiple logical IDs per physical ID (such as IP address). Achieved an attack magnitude of 700Mbps on a real network. Idea is to have self-validation of membership information. Instead of dumbly sending requests to a victim node, count the number of failures, and, past a threshold, stop hitting it.
• Adaptive File Transfers for Diverse Environments: Goal to correctly and efficiently transfer files in a wide range of scenarios. Existing tools are scenario-specific (files in place, other files, peers, identical peers). Challenges: resources have varying performance, which changes dynamically; receivers may have different initial state (e.g. software version); and resources should not need to be set up in advance. Novel optimisation framework: first decide which resources are available, then schedule across them “in an intelligent fashion”. Defers disk operations when network is faster than disk.
• Fine-Grained Isolation for the Apache Web Server: Restructuring legacy apps for the principle of least privilege. Apaches Web Server has a sensitive private key, and a complicated parser, which could be compromised, leading to the private key being exposed. 222 heap objects and 389 globals. Manual isolation took 5 weeks. Crowbar is a binary instrumentation tool that tells you what memory a function accesses, what functions access what memory items and where a sensitive-data-generating function propagates.
• A Social Networking-Based Access Control Scheme for Personal Content: Presently done messily, for example using an email service (but limited bandwidth, file size; plus push-based model is inefficient for content delivery where not all recipients would want the content). Or using a social networking site (but little support for access control on content-specific sites; plus users end up having a bunch of social networks that may get out of sync between sites). Idea is to separate the social network (which we can let people manage), and the sites that serve content. Social relations are captured by digital social attestations, and maintain this in one’s personal address book. Enables social ACLs (e.g. restrict access to family only, or friends only, etc.). Enables “social firewalls” (access only to people whom you know), or a social calendar (provides different views to different people, based on relationship).
• Improving Virtual Appliances through Virtual Layered File Systems: Problem is existing file systems are not sufficient for management of large numbers of machines. Provisioning takes too long; existing file systems treat machines as fully independent; and security models treat every file in the same way(?). A layer is a self-contained set of files, which can be shared in a read-only manner. e.g. a library or an application can be a layer. Layers are composable into a traditional file system view, along with a private read-write layer to make the file systems independent. Layers can be composed into templates for provisioning. Updating is easy: just replace the layer! Security is improved because it is easier to keep machines up to date, and tell which files have been modified.

Up at 4:30am, I left my (new-but-that’s-another-story) house at 6, caught the 6:30 bus from Cambridge to Gatwick (and was dismayed at the lack hostess, jolly or otherwise, on the National Express), then left Gatwick at 12:45 on an American Airlines flight to Raleigh/Durham, NC. Those with a keen, or even extremely vague, sense of geography will see immediately the flaw in my plan!

The transatlantic leg was fine, nothing special, and I got a good amount of work done on the plane. Arriving at the backwoods “Raleigh/Durham International Airport” was something of a come down. I’m no stranger to queues at immigration (although the hall was so small that they had to let us off the plane in stages), or having to recheck my luggage having cleared customs, but I was dismayed to find that, after doing this, all 300 tired and cranky passengers off the fully-loaded 777 were forced through a full laptops-out, shoes-off security checkpoint, even if they were leaving the airport! A little artefact of those halcyon pre-9/11 days when airport security was such that the entire townsfolk would congregate in the departure lounge for a barn dance….

Two hours there, and a bag of Fritos later, I was on another flight, this time to Dallas Fort Worth. A narcoleptic episode beginning just before take-off left me quite disoriented, but now I’m at DFW, tapping out an unnecessarily sardonic blog post, just trying to stay awake and not miss my four-hour flight to Portland. If you’re reading this, Henry, the AAdvantage miles just weren’t worth it.

the broadcaster took “such errors of judgement seriously” and was working with production company Optomen to ensure there was no repeat.

Perhaps the fact that this story was filed under “Entertainment” should be the giveaway clue: this is about as troubling as the use of stuntmen in action films, or identical twins to portray a single young child in a heartwarming soap opera. If such “errors of judgement” are to be taken “seriously”, will we not be left with utterly anaemic entertainment? Will all television be reduced to something like Blue Peter? (Oh, wait, never mind.)
The obvious reason for this banal mea culpa is the storm in a teacup over that documentary about the Queen. Yes, it was bad journalism, but an apology was issued, and that should be the end of the story. I’m a fan of the monarchy (on utilitarian grounds), but Betty is ill-served by calls for heads to roll.

Perhaps I’m a hypocrite, though. For eight years now, I’ve been selectively editing this blog to give me the appearance of a international playboy and raconteur. I apologise if you’ve been taken in.

• “Oh but I can understand your accent.”
• “Oh but I thought Scottish people were meant to be thrifty and you’ve clearly just got a round in for everyone.”
• “Oh but I can’t help noticing you haven’t knifed me to death.”
• “Is it true about the kilts?”

In the face of such blatant stereotyping, I emit a beleaguered sigh, and launch into the prepared script that I have for just these occasions; I wonder why people cling on to these old-fashioned notions about Scottishness, surely cribbed from an episode of the Russ Abbot show. But then….

On Saturday, I was outside my house, pouring concrete for the foundations of a new wall. Such is the crucible of the front garden that many passers by stopped for a chat, some just to ogle. One of the former introduced himself as William, from Glasgow. In the space of a few short minutes, he:

• Was drunk to the point of staggering
• Raised the spectre of Scotland’s 1967 football victory over England
• Complained about the price of beer
• Started getting extremely worked up about the price of his fish supper
• Swore a lot

So, thanks to William, the drunk, aggressive, tight-arsed, anti-English Scotsman with a penchant for fried food. When presented with this evidence, it’s perfectly clear that the battle is lost. Now, if you’ll excuse me, I think my head’s going to explode.

Now, bear in mind that I only watched the last two episodes, so I’m not basing this on all the evidence, but in business, as the cliché goes, you’re only as good as your last job/performance/trade/idea/etc., so I think that gives me the right to comment. (Well, that and the fact that, as a blogger, I’m clearly a narcissist.)

So we had Simon versus Kristina. And I’ll put my cards on the table, I really thought Kristina should have won. If this is a meritocracy, the winner should have been chosen on merit, and, in my opinion, all the merit belonged to her. We saw her give a confident performance in the interview, in which they made no successful attempt to impeach her. By contrast, we saw Simon fail-to-look-the-interviewer-in-the-eyes as his litany of misdeeds as a landlord were reeled off (there is a special place in hell…), and his supposed advantage was that he knew so much about the company and Alan Sugar himself. So he read the company profile, and practically quoted it verbatim, in the form, “I know . I know .” Perhaps he thought that if he repeated “I know” over and over, this would be proof of his intelligence, but any fool can repeat a list of facts. In fact, even a computer can do it: someone clearly taught the Amstrad web server, so it can’t be that hard.
So his two advantages, coming into the last round were intelligence and class: quite literally, “He went to a good school; he went to a good university.” (Disclosure: I work for the university in question.) Allow me to advance a theory. He went to a good public school because his father is a multi-millionaire [1] [2]. He was disproportionately likely to go to Cambridge because he went to a public school [3].

All of which sounds like so much armchair socialism and inverse snobbery. But it’s not. If you come from a well-off background, or, for whatever reason, attend an independent school or an elite university, then I wish you no harm. But if you use any of these facts alone as an a priori reason to employ someone then you fully deserve society’s wrath. It’s not where you came from or where you went that should matter in this world; it’s who you are and what you can do.

But should that be the deciding factor in the cut-throat world of business? Perhaps not. By all accounts, in the final episode, Simon delivered an excellent presentation (although this was hardly clear from the programme; and let’s not forget that life was imitating art when the building he presented looked like (not one but) three semi-erect penises), and his charm well-spokenness was an asset when dealing with customers. I would ask you, though, what use is it to be well-spoken, if one has to be told what to say?

Which brings me to my punchline. When was the last time we saw a “nice”, “charming” guy, who came from a distinguished background and went to a good university, chosen in a major contest?
Oh yeah. Never mind.

It seems to me a common problem that when people try to build Xen from source, they come unstuck when trying to boot their new dom0 kernel. Usually, they get an error like:

VFS: Cannot open root device “hda1″ or unknown-block(0,0)

Obviously, or maybe not, hda1 could be replaced by a number of different labels. What it boils down to is that your kernel and initial ramdisk pairing is incorrectly configured to access your root device. And so you can’t get to any of your files.

The first step is to make sure that you have an initial ramdisk. And this is where the advice usually ends. So, boot up your system using a functioning kernel, and enter the following as root (assuming your version of Xen uses 2.6.18 as the dom0 kernel):

mkinitrd -f /boot/initrd-2.6.18-xen.img 2.6.18-xen

Then edit your GRUB menu.lst to make sure that this is being loaded (it should be on a line beginning “module”, immediately following your dom0 kernel).

In many cases, this will fix the problem, but not if you didn’t build the correct modules in the first place! What you have to do, then, is get a copy of a working kernel .config for your system. For example, if you set up Fedora Core 5, you should be able to get a copy of the FC5 .config files for your kernel version (2.6.15, in my case). Follow the instructions for downloading kernel headers sources, and you should find them in a resulting directory. If you’re extra-lucky, you might get specific Xen .config files (for the distributions that ship with Xen support). Now that you have a working configuration, copy this over $XENROOT/buildconfigs/linux-defconfig_xen_x86_32 (use your smarts to select the appropriate source file for your architecture, and modify your move-target appropriately).
Now, hit `make world`, and go and make some coffee. Do the same mkinitrd shuffle as before, then reboot into Xen. If you’re lucky like me, it’ll work.

I know that this might be obvious to anyone who’s done serious kernel development before, but it wasn’t to me, and maybe you’ll come across this page in Google and it’ll help you out.

A little aside: I was doing all this in order to get Xen to run in HVM mode, on top of Xen. A big hat-tip must therefore go to Mark Williamson, who set me on this path and helped me out along the way.
As for the blog, expect normal service to return, with a mild rant about customer service and the iniquities of pedestrian access to suburban shopping centres, real soon now….