Linux.conf.au 2014 – Day 3 – Session 2

HTTP/2.0 And You by Mark Nottingham

  • Why?
    • Web heavier and more interactive than it used to be
    • Average size and elements on each page have doubled over last 2 years
    • People have found bad performance affects attention from users
    • Latency is bad on mobile and mobile is growing
  • Current Techniques
    • Spriting images
    • Inlining – encode images directly in CSS
    • Sharding – multiple hostnames
    • Concatenation – jam all js or css into one file/download
    • HACKS!
  • “Eliminate Requests”
  • Why are HTTP request so expensive
    • HTTP/1 uses TCP poorly
    • Head of Line blocking – requests/responses have to be ordered within each TCP connection. Slow one blocks others
    • HTTP request short and bursty, TCP was built for long lived flows
    • TCP slow start
  • Therefore HTTP uses multiple connections
    • Increases congestion events
    • resource intensive on server
    • all of this is really tricky for clients (which request to which connection in which order)
  • Http headers are verbose
    • Same data sent multiple times from request to request
    • Large request headers split across multiple packets
    • 7-8 round trips just to get page loaded
  • SPDY was the starting point
    • Previous efforts ( Opera Turbo, HTTP-NG, Waka )
  • GOAL: One TCP connection for a page load
    • longer lived
    • less resource intensive
    • more fair
  • Protocol
    • Frames – settings, header, data
      • Multiple stream IDs so data and headers from different request can be mixed on same connection
    • Prioritisation and flow control
      • Priority field
      • session level and stream level control
      • WINDOW_UPDATE frame
    • Header compression
      • 1st proposal gzip
        • One compression context for all headers in each direction (don’t redo dictionaries)
        • Very efficient, easy to impliment
        • Some memory overhead
        • But CRIME attack allowed attacker to inject data
      • HPACK instead
        • Coarse-grained delta-coding
    • Server Push
      • Push URLs straight to client in anticipation it will be needed (eg CSS, js after page requested)
  • About a dozen implimentations
  • How will it affect me?
    • 25% page size saved
    • Multiplexing allows a lot better use of network
    • HTTP semantics won’t change, but leaked abstractions will
    • Less “Best Practises” for Perf
    • Rethink connection handling – load balances
    • Now a binary format
    • TLS compulsory (effectively since major browsers will make it) 🙁
    • Getting most out of protocol will take effort
    • RESTful HTTP APIs , lower request overhead, BATCH operations no needed
  • TLS still being looked at for small/medium operators
  • http://github.com/http2/

 

Reverse engineering vendor firmware drivers for little fun and no profit by Matthew Garrett

  • Deploying Servers is tedious. Fireware config often needs keyboard/screen needs to be connected
  • Automated server deployment is awesome
  • Different mechanism
    • Serial console (can be automated, but very hard)
    • Web services console
    • Vendor-specific method
  • The vendor tool
    • Spits out XML file
    • You Modify file in your editor etc
    • Reads modified file
    • 250KB binary
    • 32-bit only
  • Matthew’s company didn’t have 32-bit libraries
  • strace to the rescue
    • Assumed it was going to use /dev/ipmi – but it didn’t
    • No /sys/bus/pci access
  • MMIOtrace to the rescue
    • No access to PCI BARS either
  • This tool does not use any kernel-provided hardware access
  • strace logs show oipl()
    • this should only be for very simple stuff. app should not access hardware bypassing the kernel
  • gdb
    • find inb/outb functions
    • set breakpoints
  • Was accessing the 0xcf8 / oxcfc PCI configuration register
  • Not just PCI config space, was also doing CMOS access
  • But wait there is more!
    • Some options didn’t trigged the breakpoints above
    • Step though gdb
    • Wait, hang on that is not my address space
    • /dev/mem being opened and mmap()ed
    • Executing BIOS code in process context
  • LD_PRELOAD
    • Trap iopl()
    • Install segfault handler
    • Wait for trap
    • decode instructions around instruction pointer
    • raise privs, execcute, drop priv
    • increment ip
    • continue
  • What is it doing
    • Accessing io ports on the IPMI controller
    • Mirror of the PCI config space registers
  • So where does the XML come from
    • Staring at the output of “strings”
    • Undocumented debug flag
    • When you set the program printed out everything it did.
  • DMI
    • DMI table contains pointer to memory
    • map that memory
    • find another table
    • parse that table
  • Summary
    • Tool access PCI config space in racy manner
    • Tool access CMOS space in a racy manner
    • Tools executes BIOS code from userspace
  • A shockingly happy ending
    • Communication with vendor
    • Work on improving this in future
    • Victory!

 

 

Share