Re: module privlages
From: "Kris Kennaway" [EMAIL PROTECTED] I'm not sure what the point of this would really be..nor how you could enforce it. Perhaps you should submit a proof of concept ;-) Kris With more thought I suppose this would be a lot more effort than I had first thought, and a different out come for speed/correctness. One way to do this would be to have all kernel code pages be invalid so they always page fault. The page fault handler then could use reserved page table bits to mark read/write/exec the page to insure that no unaurthorized code reads a page containing kernel code. I'm sure that everyone would love to have every memory access to a page containing kernel code page fault... Otherwise, on IA32 this won't work as function calls without additional hardware support. The closet you could probably get is preventing everything except for the module reading through kernel memory looking for a signature of what it wants to call and jumping to it at a point past permission and safety checks. There would have to be a bit of safety checking added to interfacing code such as device types and ownerships in the bus subsystem, and memory range validity and ownerships in the VM subsystem. The correctest way of any acceptable speed would require a module/system call gate. At that point just add in a separate VM space and you're basically working on userland kernel support. If only hardware had separate Read/Write/Execute page bits... Never mind. =) - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: module privlages
I'm not sure what the point of this would really be..nor how you could enforce it. Perhaps you should submit a proof of concept ;-) Kris On Fri, Jan 12, 2001 at 11:15:09AM -0600, Jason Smethers wrote: Has anyone put any thought into putting restrictions on what a module can modify when loaded into the kernel? If there is, say, ever binary third party driver support and this is provided without source some restrictions on what kernel data this module can link to and modify when loaded might be a good idea. I was thinking something along the lines of a list of symbols that a kernel module may call, and a list of symbols that a kernel module may modify. Allowing the update of these lists may be a little tricky to prevent already load modules from detecting this and adding their own symbols. Doing this with module types might be simple. When a module is loaded it would contain flags to the module type(s) it is uses and this selects the list of symbols it may interact with. A module may be then be used to update these symbols but root is warned and must OK a load of a kernel module with the type which allows updating the symbol lists. With the module types it would also help prevent a module from messing around in an area that is not expected from such a module. e.g. a network driver messing around in the VFS. Any thoughts? - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message PGP signature
