CS-522 (POCS) One-Pagers

Below are the one-page writing assignments; instructions appear at the bottom of this page. After grading the OPs, we select some that stand out in one way or another. These are not “perfect OPs” but rather OPs that put forth a clear design and make for an intellectually interesting read.

OP2 (due 19-Oct-2018)

We want to build an emergency response service (EMS) that enables a user to place an emergency voice call to an operator and satisfies the following requirements: (1) As long as the device (e.g., smartphone) used to make the call can transmit/receive at the rate that is necessary to perform a voice call, the system will reliably deliver the call; (2) If the call is disrupted due to a technical/network failure or the caller being incapacitated, the operator will dispatch emergency help to the physical location where the call originated from. Can we build such a service over the current Internet architecture (i.e., if the caller and the operator communicate only over the Internet)? If yes, describe the architecture of the system and how it could meet the two requirements. If not, explain the minimum changes we would need to make to the Internet architecture (the network stack) in order for the system to meet the two requirements.

  • Matteo Rizzo [view] proposes marking and prioritization of emergency packets, routing of emergency packets through all available routes, and geolocation through link-layer and network-layer extensions. What makes this OP stand out is the clear statements, lack of redundancy, and excellent use of references to support the OP’s position.
  • Aunn Raza [view] proposes DiffServ to identify and prioritize emergency packets, combined with SMS as backup: when the caller cannot communicate with the emergency operator over the Internet, her device simply SMS’s her physical location to the operator, and the operator dispatches help. What makes this OP stand out is the simplicity and practicality of the proposed solution.

OP1 (due 12-Oct-2018)

Linux Kernel Modules are a representative example of soft modularity. Explain why they only provide soft modularity and propose a way to implement enforced modularity for Linux Kernel Modules. Describe the implications of your solution and discuss the associated trade-offs between fault isolation and performance.

  • Sachin John [view] proposes isolating LKMs by virtualizing the LKM/kernel interface via a userspace library
  • Matteo Rizzo [view] proposes to use formal verification to guarantee that LKMs do not escape their module boundary, and relies on a formalization of the interface between the LKM and the Linux kernel.
  • Thanassis Xygkis [view] proposes separate page tables per kernel module, with compiler-enforced switching of the page directory base register upon entry in an LKM, effectively implementing in-kernel processes.
  • Rishabh Iyer [view] proposes to run drivers in user-space processes, then memory-isolate their respective devices via the IOMMU to protect the system from rogue writes, and mirror into user-space the kernel interfaces needed by the LKMs via a duo of an in-kernel proxy plus an in-user-space server process.
  • Aunn Raza [view] proposes to leverage Mondriaan memory protection—a way for protecting domains at finer granularity than address spaces with arbitrary permissions control at the granularity of individual memory locations—as a way to isolate each LKM in its own protection domain without the overhead of address space switching.

Instructions for writing an OP

Use a maximum of 500 words for the body of your writeup; in the words of Antoine de Saint-Exupéry, “perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” OPs require in-depth consideration of the assigned materials, along with good technical writing.

Your submission must be in PDF and consist of one single-spaced A4 page, including all figures, tables, and references. References should have complete citations at the bottom of the OP, which in turn are hyperlinked to electronic versions of the cited materials, whenever possible. The OP should be single-column and use Times New Roman font with 10-point type or greater. Not respecting these rules will be severely penalized. The title and references do not count toward the 500-word limit.

Submit your OP through the POCS submission system. It must be received by 23:59 CEST on Friday. If you submit on time a first version of the OP, then you get an automatic extension to finalize the OP until 23:59 CEST on Sunday. Please prefix your title with the number of the OP, that is “OP1: Title” for the first week’s OP. Do not write your name on the OP.

Before submitting your first OP, you have to create an account on the system. Registration is straightforward: simply enter your email address and choose “I’m a new user and want to create an account using this email address”. The system will shortly send you an email with instructions on how to complete your registration. Once you register, you should fill in the new paper form.

You are not allowed to discuss the topic of the OP with anyone else until after Sunday. The OP must be 100% your own work.