Date: Mon, 25 Nov 1996 13:42:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kjk1@ukc.ac.uk (K.J.Koster) Cc: hackers@freebsd.org Subject: Re: A simple way to crash your system. Message-ID: <199611252042.NAA23206@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.95.961125131025.5534A-100000@kestrel.ukc.ac.uk> from "K.J.Koster" at Nov 25, 96 01:19:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> After rebuilding my kernel, and doing a `make install' on it, I wanted to > make a little change to my autoexec.bat, before rebooting so: > > LikeEver# make install > *chew chew, installed kernel* > LikeEver# mount /msdos > *silence*... Uh, Oh... > *twitch, grasp, cold reboot* > > This is obviously stupidity on my part, for not rebooting immediately > after installing the kernel, but still. > > Altough I am speculating here, I think this has to do with the fact that > I do not have msdosfs compiled in with the kernel. After installing a > different kernel, I asked the system to modload msdosfs, with the above > result. Modules are loaded by: o Create the module as a PIC a.out binary (Position Independent Code). o Link the module against the kernel symbol table, and placing the module at text address zero. o Look at the resulting object size. This is the amount of memory consumed by the post-link module. o Round up to a page boundry. o Call an ioctl on /dev/lkm to reserve that much contiguous space in kernel memory on a page boundry. This is the address at which you will load the module; it must be contiguous in the kernel virtual address space, but not necessarily in physical memory, unless your data area is a preallocated DMA target (if it is, you have a bad coding style, and should allocate the buffer at init time instead of as static data anyway). o Link the module against the kernel symbol table, this time placing the module at the text address of the start of the reserved memory area. o Push the module across the U/K boundry via additional ioctl's, to copy it into the allocated region. o Ioctl the entry point of the module down. The kernel will call entry into the module, and cause the module to self register. o The module will modifiy dynamic list contents in the kernel address space to wedge itself in. Any address which is writeable is fair game for wedging. For instance, you can overwrite function pointers to wedge in a ned console in the init() routine for a module, even though "console modules" are not a defined type. Your attempt to load the module failed because the kernel symbol table you were linking against was not the correct symbol table for the currently active kernel. Most likely, the self-registration mechanism, when invoked, caused the module to step on relative addresses in the data segment which were invalid. This could mean it tromped on active FS code, active registration data, or whatever. In general, it failed because the external module references weren't where the symbol table said they were. The correct soloution to this problem is to move FreeBSD to ELF, and generalize an ELF image loader so that the module loader and the execution class loader use the same code. Then move the kernel symbol table into kernel data address space (just like AIX). You could limit the exported symbols to "defined kernel interfaces". I would actually recommend against this... I think Linux has the wrong idea here; they only do it so they can pretend the kernel is a library (LGPL) and therefore kernel modules do not get subjected to the GPL. Stahlman doesn't think that the license allows this, FWIW. Finally, you would establish a symbol/image mapping, and inserts the module symbols into the exported symbol lost for the kernel. This resolves the dependency graph issues that are poorly resolved in the current LKM system ...my fault; I only considered LKM's as a developer tool; even if the dependency issue for loadable driver interdependence is resolved, loading and unloading will fragment the kernel virtual address space. Truly, each LKM needs its own VM so it can be loaded there. This also removes the PIC requirement for processor architectures which don't support it. This also neatly resolves the KVA short/medium/long persistence object issues. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611252042.NAA23206>