;login FALL 2018 VOL. 43, NO. 3 : & Capacity Prediction Rick Boone & BeyondCorp: Fleet Mangement Hunter King, Michael Janosko, Betsy Beyer, and Max Saltonstall & Transactional File System Yige Hu, Zhiting Zhu, Ian Neal, Youngjin Kwon, Tianyu Cheng, Vijay Chidambaram, and Emmett Witchel & Serverless, Optimized Containers Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Caraza-Harter, Andrea C. Arpaci- Dusseau, and Remzi H. Arpaci-Dusseau Columns Shared Objects in Python Packages Peter Norton GraphQL David N. Blank-Edelman LDAP in GoLang Chris “Mac” McEniry Perusing Data Lakes Dave Josephsen Numbers Are Where You Find Them Dan Geer UPCOMING EVENTS SREcon18 Europe/Middle East/Africa SREcon19 Americas August 29–31, 2018, Dusseldorf, Germany March 25–27, 2019, Brooklyn, NY, USA www.usenix.org/srecon18europe 2019 USENIX Annual Technical Conference OSDI ’18: 13th USENIX Symposium on Operating July 10–12, 2019, Renton, WA, USA Systems Design and Implementation Co-located with USENIX ATC ’19 October 8–10, 2018, Carlsbad, CA, USA HotStorage ’19: 11th USENIX Workshop on Hot Sponsored by USENIX in cooperation with ACM SIGOPS Topics in Storage and File Systems www.usenix.org/osdi18 July 8–9, 2019 LISA18 HotCloud ’19: 11th USENIX Workshop on Hot October 29–31, 2018, Nashville, TN, USA Topics in Cloud Computing www.usenix.org/lisa18 July 8, 2019 HotEdge ’19: 2nd USENIX Workshop on Hot Topics Enigma 2019 in Edge Computing January 28–30, 2019, Burlingame, CA, USA July 9, 2019 www.usenix.org/enigma2019 FAST ’19: 17th USENIX Conference on File and 28th USENIX Security Symposium Storage Technologies August 14–16, 2019, Santa Clara, CA, USA February 25–28, 2019, Boston, MA, USA Co-located with NSDI ’19 Submissions due September 26, 2018 www.usenix.org/fast19 NSDI ’19: 16th USENIX Symposium on Networked Systems Design and Implementation February 26–28, 2019, Boston, MA, USA Co-located with FAST ’19 Paper titles and abstracts due September 13, 2018 (Fall deadline) www.usenix.org/nsdi19 USENIX Open Access Policy USENIX is the fi rst computing association to off er free and open access to all of our conference proceedings and videos. We stand by our mission to foster excellence and innovation while supporting research with a practical bias. Your membership fees play a major role in making this endeavor successful. Please help us support open access. Renew your USENIX membership and ask your colleagues to join or renew today! www.usenix.org/membership www.usenix.org/facebook www.usenix.org/gplus www.usenix.org/linkedin twitter.com/usenix www.usenix.org/youtube FALL 2018 VOL. 43, NO. 3 EDITOR Rik Farrow [email protected] MANAGING EDITOR EDITORIAL Michele Nelson 2 Musings Rik Farrow [email protected] COPY EDITORS OPINION Steve Gilmartin 6 Reflections on Post-Meltdown Trusted Computing: Amber Ankerholz A Case for Open Security Processors PRODUCTION Jan Tobias Mühlberg and Jo Van Bulck Arnold Gatilao Jasmine Murcia SYSTEMS TYPESETTER 10 TxFS: Leveraging File-System Crash Consistency to Provide Star Type ACID Transactions [email protected] Yige Hu, Zhiting Zhu, Ian Neal, Youngjin Kwon, Tianyu Cheng, USENIX ASSOCIATION Vijay Chidambaram, and Emmett Witchel 2560 Ninth Street, Suite 215 Berkeley, California 94710 17 SOCK: Serverless-Optimized Containers Phone: (510) 528-8649 Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Caraza- FAX: (510) 548-5738 Harter, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau www.usenix.org SECURITY ;login: is the official magazine of the USENIX BeyondCorp: Building a Healthy Fleet Association. ;login: (ISSN 1044-6397) 24 is published quarterly by the USENIX Hunter King, Michael Janosko, Betsy Beyer, and Max Saltonstall Association, 2560 Ninth Street, Suite 215, 31 Building an Internet Security Feeds Service John Kristoff Berkeley, CA 94710. $90 of each member’s annual dues is for 35 USENIX Security and AI Networking Conference: ScAINet 2018 a subscription to ;login:. Subscriptions for Aleatha Parker-Wood non members are $90 per year. Periodicals postage paid at Berkeley, CA, and additional SRE/SYSADMIN mailing offices. 38 Capacity Engineering: An Interview with Rick Boone Rik Farrow POSTMASTER: Send address changes to ;login:, USENIX Association, 2560 Ninth Street, COLUMNS Suite 215, Berkeley, CA 94710. 40 Python: Shared Libraries and Python Packaging, an Experiment ©2018 USENIX Association Peter Norton USENIX is a registered trademark of the USENIX Association. Many of the designa- 44 Practical Perl Tools: GraphQL Is Pretty Good Anyway tions used by manufacturers and sellers David N. Blank-Edelman to distinguish their products are claimed as trademarks. USENIX acknowledges all 48 Yes, Virginia, There Is Still LDAP Chris “Mac” McEniry trademarks herein. Where those desig- Dave Josephsen nations appear in this publication and 51 iVoyeur: Flow USENIX is aware of a trademark claim, 54 For Good Measure: Numbers Are Where You Find Them Dan Geer the designations have been printed in caps or initial caps. 57 /dev/random: No Bots About It Robert G. Ferrell BOOKS 59 Book Reviews Mark Lamourine and Rik Farrow USENIX NOTES 62 The Big Picture Liz Markel 63 Meet the Board: Amy Rich Musings RIK FARROWEDITORIAL Rik is the editor of ;login:. have often mused about how the architecture of the CPUs we use influ- [email protected] ences the way our operating systems and applications are designed. A I book I reviewed in this issue on the history of computing managed to cement those ideas in my head. Basically, we’ve been reprising time-sharing systems since the mid-60s, whereas most systems serve very different pur- poses today. Along the way, I also encountered a couple of interesting data points, via pointers from friends who have been influencing me. One was Halvar Flake’s CYCON 2018 talk [1], and another was about a new OS project at Google. The opinion piece by Jan Mühlberg and Jo Van Bulck that appears in this issue influenced me as well, as it describes a CPU feature that, among other things, could block the use of gadgets in return-oriented programming (ROP). Flake explained that much of our current problems with security have to do with cheap com- plexity. Even though a device, like a microwave oven or intravenous drip-rate controller, only requires a PIC (Programmable Interrupt Controller), it may instead have a full-blown CPU running Windows or Linux inside it. CPUs are, by design, flexible enough to model any set of states, making them much more complex than what is needed inside a fairly simple device. Designers instead choose to use a full-blown CPU, usually with an OS not designed to be embedded, to model the states required. Vendors do this because many more people under- stand Windows or Linux programming than know how to program a PIC. This isn’t just a problem for ovens or routers. Let’s not even discuss home routers, although the arguments for using a real OS are at least stronger in the case of routers. Dan Farmer published research, funded by DARPA, in 2013 about IPMI and BMC [2], the controllers found on most server-class motherboards. These controllers provide an over-the-network method of managing servers—e.g., rebooting them or installing updates. But the controllers are full-blown Linux systems, burned into ROM, using very old versions of Linux and exploit- able software. The controllers can read or write any system memory, as well as use either a dedicated network interface or any network interface on the server, making them the obvious point for an undetectable attack using an embedded system that does no logging and cannot be patched. Ouch. One of Flake’s concluding slides had this bullet point, one I particularly liked: ◆◆ CPU-architecture and programming models are in flux for the first time since the 1980s. I’d argue that the date is wrong, as we didn’t get heavily into threaded programming until the noughts; other than that, the CPU architecture has remained very similar in rough outline to late ’60s mainframes. But ignore the date and ponder Flake’s implied suggestion: now is a good time for some serious changes in architecture and programming models. Another data point is currently much more obscure. Google has a project, an OS named Fuch- sia powered by the Zircon microkernel [3], based on another Google project, a microkernel named LK. Both appear to be focused for use in IoT and embedded systems. But Zircon has been designed to work on modern devices with more powerful CPUs and lots more memory than LK [4]. 2 FALL 2018 VOL. 43, NO. 3 www.usenix.org EDITORIAL Musings Zircon has a small kernel that manages processor time, memory, Oakes et al. write about a lightweight container for use with I/O, interrupts, and waiting/signaling. Everything else gets Lambdas. AWS introduced Lambdas for serverless computing, done in userspace, as processes. The enabling technologies that but the problem with using these is the startup cost for loading make this work well are IOMMUs and ARM SMMUs. Both the a container complete with the necessary libraries for the servlet IOMMU and SMMU were designed to support virtual machines, code. SOCK builds on previous work [6] and provides a much allowing a VM to have access to, for example, a network inter- lighter-weight container than Docker, for example, and this face queue. But these subsystems also mean that userspace pro- article explains how and why that is done. grams can gain access to device memory and be able to copy data You can expect more articles about security in the Winter between the devices and other memory, something that has been issue, as the security papers deadline came too late for me to a barrier to running system services in other microkernels.