Capactiy Predci tion BeyondCorp: Fleet Mangement ... Lambdas. AWS introduced Lambdas for serverless

  • View
    1

  • Download
    0

Embed Size (px)

Text of Capactiy Predci tion BeyondCorp: Fleet Mangement ... Lambdas. AWS introduced Lambdas for serverless

  • ;login: F A L L 2 0 1 8 V O L . 4 3 , N O . 3

    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

    & 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

  • UPCOMING EVENTS SREcon18 Europe/Middle East/Africa

    August 29–31, 2018, Dusseldorf, Germany www.usenix.org/srecon18europe

    OSDI ’18: 13th USENIX Symposium on Operating Systems Design and Implementation

    October 8–10, 2018, Carlsbad, CA, USA Sponsored by USENIX in cooperation with ACM SIGOPS www.usenix.org/osdi18

    LISA18 October 29–31, 2018, Nashville, TN, USA www.usenix.org/lisa18

    Enigma 2019 January 28–30, 2019, Burlingame, CA, USA www.usenix.org/enigma2019

    FAST ’19: 17th USENIX Conference on File and Storage Technologies

    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

    SREcon19 Americas March 25–27, 2019, Brooklyn, NY, USA

    2019 USENIX Annual Technical Conference July 10–12, 2019, Renton, WA, USA

    Co-located with USENIX ATC ’19 HotStorage ’19: 11th USENIX Workshop on Hot Topics in Storage and File Systems July 8–9, 2019

    HotCloud ’19: 11th USENIX Workshop on Hot Topics in Cloud Computing July 8, 2019

    HotEdge ’19: 2nd USENIX Workshop on Hot Topics in Edge Computing July 9, 2019

    28th USENIX Security Symposium August 14–16, 2019, Santa Clara, CA, USA

    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

    twitter.com/usenix

    www.usenix.org/youtube

    www.usenix.org/linkedin

    www.usenix.org/gplus

  • E D I T O R Rik Farrow rik@usenix.org

    M A N A G I N G E D I T O R Michele Nelson michele@usenix.org

    C O P Y E D I T O R S Steve Gilmartin Amber Ankerholz

    P R O D U C T I O N Arnold Gatilao Jasmine Murcia

    T Y P E S E T T E R Star Type startype@comcast.net

    U S E N I X A S S O C I AT I O N 2560 Ninth Street, Suite 215 Berkeley, California 94710 Phone: (510) 528-8649 FAX: (510) 548-5738

    www.usenix.org

    ;login: is the official magazine of the USENIX Association. ;login: (ISSN 1044-6397) is published quarterly by the USENIX Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710.

    $90 of each member’s annual dues is for a subscription to ;login:. Subscriptions for non members are $90 per year. Periodicals postage paid at Berkeley, CA, and additional mailing offices.

    POSTMASTER: Send address changes to ;login:, USENIX Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710.

    ©2018 USENIX Association USENIX is a registered trademark of the USENIX Association. Many of the designa- tions used by manufacturers and sellers to distinguish their products are claimed as trademarks. USENIX acknowledges all trademarks herein. Where those desig- nations appear in this publication and USENIX is aware of a trademark claim, the designations have been printed in caps or initial caps.

    FA L L 2 0 1 8 V O L . 4 3 , N O . 3

    E D I T O R I A L 2 Musings Rik Farrow

    O P I N I O N 6 Reflections on Post-Meltdown Trusted Computing:

    A Case for Open Security Processors Jan Tobias Mühlberg and Jo Van Bulck

    S Y S T E M S 10 TxFS: Leveraging File-System Crash Consistency to Provide

    ACID Transactions Yige Hu, Zhiting Zhu, Ian Neal, Youngjin Kwon, Tianyu Cheng, Vijay Chidambaram, and Emmett Witchel

    17 SOCK: Serverless-Optimized Containers Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Caraza- Harter, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau

    S E C U R I T Y 24 BeyondCorp: Building a Healthy Fleet

    Hunter King, Michael Janosko, Betsy Beyer, and Max Saltonstall

    31 Building an Internet Security Feeds Service John Kristoff

    35 USENIX Security and AI Networking Conference: ScAINet 2018 Aleatha Parker-Wood

    S R E / S Y S A D M I N 38 Capacity Engineering: An Interview with Rick Boone Rik Farrow

    C O L U M N S 40 Python: Shared Libraries and Python Packaging, an Experiment

    Peter Norton

    44 Practical Perl Tools: GraphQL Is Pretty Good Anyway David N. Blank-Edelman

    48 Yes, Virginia, There Is Still LDAP Chris “Mac” McEniry

    51 iVoyeur: Flow Dave Josephsen

    54 For Good Measure: Numbers Are Where You Find Them Dan Geer

    57 /dev/random: No Bots About It Robert G. Ferrell

    B O O K S 59 Book Reviews Mark Lamourine and Rik Farrow

    U S E N I X N O T E S 62 The Big Picture Liz Markel

    63 Meet the Board: Amy Rich

  • 2  FA L L 20 1 8 VO L . 4 3 , N O. 3 www.usenix.org

    EDITORIALMusingsR I K F A R R O W Rik is the editor of ;login:. rik@usenix.org I have often mused about how the architecture of the CPUs we use influ-ences the way our operating systems and applications are designed. A 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].

  • www.usenix.org FA L L 20 1 8 VO L . 4 3 , N O. 3 3

    EDITORIAL Musings

    Zircon has a small kernel that manages processor time, memory, I/O, interrupts, and waiting/signaling. Everything else gets done in userspace, as processes. The enabling technologies that make this work well are IOMMUs and ARM SMMUs. Both the IOMMU and SMMU wer