Memory%20Management%20in%20Linux%20drivers

1
Memory Management inLinux drivers
Scott McPeak Open Source Quality Group October 3,
2000
2
Talk Outline

• Memory safety issues for driver code
• Allocation kmalloc, get_free_pages, vmalloc
• User/kernel pointers
• Bus/physical/virtual addresses
• Miscellanous
• An idea qualifiers owner'' and serf''
• Several potential benefits, with some
  restrictions...
• A parser I've been working on

3
kmalloc

• mm/slab.c
• The typical interface works like malloc
• Allocate up to 128k of physically contiguous
  memory
• Allocates in 2n increments (5 n 17)
• pre 2.2 kernels allocated slightly less than 2n
• Can waste a lot of space allocating 2n c bytes

4
kmalloc gotchas

• Can sleep (unless GFP_ATOMIC)
• Data structure invariants must hold before the
  call
• Other restrictions on sleeping (e.g. not in ISR!)
• Can fail
• Must check for NULL return
• More likely to fail with larger request sizes
• No automatic deallocation, even when driver is
  unloaded from kernel
• Does not zero the mem possible security issue

5
kfree

• Complement to kmalloc, of course
• Does not like to be passed bad pointersbad_ptr
  printk(KERN_ERR "kfree Bad obj p\n",
  objp)if 1/ FORCE A KERNEL DUMP WHEN THIS
  HAPPENS. SPEAK IN ALL CAPS. GET THE CALL CHAIN.
  /(int ) 0 0endif
• Also kfree_s, which will accept a size argument
• But only checks for being too big

6
__get_free_pages/free_pages

• mm/pagealloc.c
• kmalloc calls this internally
• Allocates in units of pages
• Up to 128k (256k on alpha) of physically
  contiguous pages
• Can fail
• Can sleep same GFP_ATOMIC considerations

7
vmalloc/vfree

• mm/vmalloc.c
• Can allocate gt 128k
• But returned memory is contiguous only in virtual
  space
• Calls kmalloc and __get_free_pages with
  GFP_KERNEL, so it can sleep too
• And it can fail

8
Other resources with alloc/free model

• Hardware IRQs, I/O ports, ISA DMA channels
• Device registration (e.g. register_chrdev)
• Device category fns (e.g. sound_alloc_audiodev)
• Others?

9
User vs. kernel pointers

• include/asm/uaccess.h
• Linux virtual memory layout
• All processes map kernel mem at 0xC0000000
• But only supervisor mode can read/write it
• Access checks
• copy_from_user ok, just check return value
• access_ok then __copy_from_user ok, but still
  have to check return, because access_ok returns 1
  for unmapped addresses (!)

10
Bus/physical/virtual addresses

• Virtual what the cpu core hands to the MMU
• Physical what goes on the processor/memory bus
• Bus what a device uses to name memory
• If the device bus (e.g. PCI) is connected to the
  processor/memory bus by a bridge, and the bridge
  translates memory addresses, then bus ! physical
  (true on Alpha)
• Translation functions virt_to_phys ( v.v.) and
  virt_to_bus ( v.v.) asm/io.h

11
When things go wrong

• Kernel derefs bad address oopsUnable to
  handle kernel NULL pointer dereference at virtual
  address 00000149current-gttss.cr3 004ef000,
  cr3 004ef000pde 00000000Oops 0000CPU
  0EIP 0010ltc010f44agtEFLAGS
  00000003eax 00000145 ebx c04f1ef4 ecx
  c0f9103c edx 00000145esi 00000286 edi
  c04f0000 ebp c04f1efc esp c04f1ef4ds 0018
  es 0018 ss 0018Process pilot-xfer (pid
  218, process nr 31, stackpagec04f1000)Stack
  c04f0000 c0f9103c c04f1f10 c1809452 c0f91000
  c180af44 c05f75c0 c04f1f28 c180987c
  c0f91000 00000000 00000010 00000004 00000000
  c012babf c05f75c0 00000000 c08e4ed4
  00000005 c08e4ed8 00000024 00000145 00000004
  c04f0000Call Trace ltc1809452gt ltc180af44gt
  ltc180987cgt ltc012babfgt ltc012bf96gt
  ltc010f0cfgt ltc0107a6fgtCode 8b 42 04 39 d8 75
  f7 89 4a 04 56 9d 8d 65 f0 5b 5e 89 ec 5d
• If syscall, kills process if BH or ISR, ???
• If kernel code detects a problem, it can call
  panic(), which halts machine

12
An idea owner and serf

• Tag every pointer declaration as one or the other
• An owner pointer must deallocate what it points
  to before it, itself, is deallocated or nullified
• A serf pointer does not have the obligation nor
  ability to dealloc what it points to
• A serf'' is a feudal peasant who works the land
  but does not own it. )
• Invariant every allocated block has exactly one
  owner pointer pointing at it

13
Rules for owners

• Focus of owner rules no leaks
• To Preserve at-least-one owner per block
• Must be NULL before being assigned-to
• Setting to NULL implicitly deallocates
• Must be NULL before the owner itself is
  destroyed
• To preserve at-most-one owner per block
• Assigning from an owner sets the other one to
  NULL
• Passing an owner sets it to NULL

14
Rules for serfs

• Focus of serf rules avoid dangling references
• Key is to bound serf lifetime within lifetime of
  an owner that always points higher'' in owner
  tree
• Serfs in global data or heap are tricky
• Must statically associate with global/heap owner
• Serfs on the stack
• Must keep serfs below'' correspondng owner
• Passing serfs is ok, but returning them is hard
• Returning owners is ok, but passing them is hard

15
Limitations

• Can't handle shared ownership, where either of
  two potential owners might go away first
• Can't handle pointers which are sometimes owners
  and sometimes serfs, e.g. in a circular list
• This is likely to be the biggest practical
  problem
• It often is difficult assign qualifiers by hand
  it may be difficult to infer them as well, even
  for code that follows the rules''

16
Additional annotation

• To check deallocation of arrays containing owner
  pointers, need to know the array size
• Let the size be part of the type, as an
  expression that can be evaluated can get count
  expression directly from the kmalloc call
• Q what values are possible inputs, besides
  globals?
• Q at what program points must expr be evaluable?
• E.g. struct MyDevnr_devs owner devs
• This adequately distinguishes pointer-to-one from
  pointer-to-many (since the latter has count gt 1).
• Makes array bounds checks convenient

17
What do real drivers do?

• Looked at three drivers (so far)
• SoundBlaster sound card
• PS/2 Mouse
• Analog joystick

18
SoundBlaster

• drivers/sound/sb
• Several ownership transfers, stack -gt global,
  global -gt stack
• And a few leaks on error paths...
• Serfs in the heap pointing to global (static)
  data
• Global serfs pointing to heap data
• Otherwise well-behaved

19
PS/2 Mouse

• Not written as a module'', so there is no
  global dealloc
• Simply allocates a single block during init,
  stores address in global owner
• But argument to kmalloc is 2048c, so almost 2k
  is wasted

20
Analog joystick

• Rat's Nest of Pointers (tm)
• Heap serfs to their own block
• Several parallel arrays of serf pointers to
  related block's interior
• Array of owner pointers accessed via serf
• Doubly-linked list with prev' as owner
• Global serfs to the heap
• Owner structure exists albeit obfuscated serfs
  ...

21
Discussion

• (before moving on to parser stuff)

22
Yet another parser

• Built from scratch
• Uses Generalized LR (GLR) parsing algorithm
• Nice grammar syntax
• Syntactic disambiguation via attributes
• Convenient semantic functions top-down!
• Intent is to parse C

23
Generalized LR (GLR)

• Builds ordinary LR (say, SLR(1)) tables
• When LR parser reaches shift/reduce or
  reduce/reduce conflict, GLR splits the parse
  stack to pursue each possibility
• If input unambiguous all but one parser will die
• If not parsers will merge after ambiguous
  section
• Handles entire class of context-free grammars, so
  no grammar hacking
• This is a big win

24
Syntax and disambiguation

• Free form, nested scope, extensiblenonterm Expr
  attr prec -gt NAME INTLIT action
  prec 100 -gt leftExpr opBinop rightExpr
  action prec op.prec condition
  this.prec lt left.prec condition this.prec
  lt right.prec condition op.leftAssoc 1
  ? this.prec lt right.prec
  this.prec lt left.prec

25
Semantic functions

• Compiled evaluation is top-down, after parsing
  is finishednonterm Input -gt defsVarDefList ""
  eExpr // return value of total expression
  fundecl int eval() const fun eval //
  gather the bindings from the definitions
  Bindings bindings defs.gatherBindings(binding
  s) // use them to evaluate return
  e.eval(bindings)

26
Current Status

• C grammar done, works
• One ambiguity every 5 - 20 lines
• Also parses C
• Lexer tokenizes, but doesn't do preprocessor
• Preprocessing on the todo list but for some
  apps, it's good enough to parse unpreprocessed
  source
• Need to add semantic analysis
• At least a symbol table, to eliminate ambiguities
• Performance not great, not horrible