LCA2012 – Thursday last session

Challenges for the Linux plumbing community – Jonathan Corbet

  • Good news is boring, so how about some “high quality problems”
  • Security
  • Stuxnet , kernel.org , RSA hack , DigiNotar
  • Scary ones are there must be others we haven’t heard about
  • The bad guys are: motivated, capable, well funded. Not just script kiddies
  • Not just about money anymore, with governments hacking lives are at stake
  • We are on the front line. Not just security software, all code security critical
  • Is your code secure? Who reviews it? What sort of testing? Plans for dealing with vulnerabilities?
  • Is your infrastructure secure? – Who has access, who can change files? Are security updates applied? What are your plans in case of a breach?
  • Are your processes secure? Who can commit? What can sign releases? Can you detect tampering? What do they know about the codes provenance?
  • Tools
  • Lockdep, valgrind, fault injection, sparse, smatch
  • GCC python plugin, MELT, LLVM static analyzer
  •  and need to actually use the tools that exist
  • Hardware
  • hardware complexity leads to software complexity
  • Complex interfaces: example V4L3 media controller interface.
  • Control over our hardware
  • Life is okay (could be better, could be worse)
  • What is our influence over manufacturer?
  • Example: Chasing tablet manufactures , no influence on design, have to port after device launched
  • Example: By the time “Rock Box” runs on a device device is obsolete and not in shops
  • How can we be more involved in conception and design of hardware in the first place?
  • Linux Only
  • Once upon a time we depended heavily on portability
  • The DRM tree deemphasized BSD support, This hurt BSD but… would we rather do without kernel mode settings
  • Might be inevitable but try not to be too arrogant
  • The platform problem
  • Code you control vs Black box
  • The kernel’s ARM subtree (re-implements stuff from elsewhere in kernel)
  • XFree86 (tried to keep everything in user space)
  • Opportunistic suspend (Andriod decided “too hard” to fix rest of kernel)
  • Async I/O (implemented multiple times, no comprehensive implementation)
  • Example: wireless devices had own 80211 implementation. replaced with max80211
  • Example: PowerTop used to find wide range a random things causing high power usage in laptops
  • Ongoing examples: Bufferbloat, marvell-cam drivers, User-Space TCP, Control groups, Andriod

 

 

What is in a tiny Linux installation? by Malcolm Tredinnick

  • Skipping bootloader portion
  • Kernel is big – 9.6M lines of C, 250k lines of assembler
  • Booting the kernel
  • “make allnoconfig” , smallish, 222 “y” ‘s. 842KB bzimage, build time under 15s, no file systems, no fancy hardware, ISA, no PCI
  • “make allyesconfig” , 5177 y options. 39MB bzimage, over 1h to build, includes drivers/staging
  • booting allnoconfig via qemu-kvm . Gets to “unable to mount root file system”
  • Kernel components – hardware arch, drivers, subsystems, others
  • need roto filesystem in memory, initrd / initramfs . init process just in cpio archive, can just be hello world
  • need initrd, initramfs , RAM disk block device, ELF binary support. 889KB bzimage (up 50kb)
  • Now boots, use “rdinit=/hello” option in qemu , just prints out hello world
  • Transition to userspace
  • initrd loads some modules etc, runs pivot_root , run startup scripts
  • Userspace
  • Why are you doing this? Single purpose system, usb stick (rescue, puppy linix, Damn Small Linux) , tiny memory, tiny storage usage, fast power on. Trade-off of options
  • We have to run something, need some binaries, shared libraries, large binaries with multiple purposes (busybox)
  • Busybox – one binary – acts differently depending on calling name, installed as symlinks
  • Busybox: fairly small, default utilities, 2MB without networking, easy to test
  • C libraries – glibc (probably not a good idea), eglibc (easier to build, binary compatible with glibc, can take things out), uClibc (alternative, very small, some overlap with busybox, source code compatible with glibc)
  • Device and Proc mngt will need: procfs, sysfs, tmpfs, udev, cgroups
  • Build environments: you are cross compiling (build root), binutils, C libraries & cross compiling, Test, x86 instead x86 is harder
  • See links in slides for some help
  • mdebian is something to look at
Share