[cgl_discussion] Some Initial Comments on DDH-Spec-0.5h.pdf

[Andy Pfiffer]

On Mon, 2002-09-23 at 18:25, Gustafson, Geoffrey R wrote:
> You bring up a very good point about the possibility of killing N birds with
> one stone with hardening in the kernel itself. I don't know enough to
> address that, and can only suppose that maybe device-independent validation
> is very limited?

I made a quick pass over a 2.4.4 eepro100 module (I usually don't use
modules...) and here is a short list of mostly-relevant routines called
by the eepro100 driver.  If you wanted to consider putting your
professional paranoia at the edges between drivers and the kernel, you
might want to make a larger list like this for a reasonable sample of
drivers.

         U __const_udelay
         U __ioremap
         U __kfree_skb
         U __release_region
         U __request_region
         U __this_module
         U add_timer
         U alloc_skb
         U del_timer_sync
         U eth_type_trans
         U free_irq
         U init_etherdev
         U iomem_resource
         U ioport_resource
         U iounmap
         U irq_stat
         U jiffies
         U kfree
         U kmalloc
         U netif_rx
         U pci_alloc_consistent
         U pci_enable_device
         U pci_find_capability
         U pci_free_consistent
         U pci_read_config_word
         U pci_register_driver
         U pci_set_master
         U pci_unregister_driver
         U printk
         U request_irq
         U skb_over_panic
         U softnet_data
         U synchronize_irq
         U unregister_netdev

Then, for everything that shows up on the list, take a look
at the interface for each function and see if there is insufficient
"defensive programming" going on...

Andy