Date: Sat, 13 Jan 2001 17:24:50 -0600 From: "Jason Smethers" <jsmethers@pdq.net> To: "Kris Kennaway" <kris@FreeBSD.ORG> Cc: <current@FreeBSD.ORG> Subject: Re: module privlages Message-ID: <008001c07db8$0775f7c0$edcf1f40@pdq.net> References: <000f01c07cbb$379df040$edcf1f40@pdq.net> <20010112175221.E23818@citusc.usc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Kris Kennaway" <kris@FreeBSD.ORG> >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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008001c07db8$0775f7c0$edcf1f40>