Messages in this thread | | | Date | Mon, 6 Dec 2004 12:57:13 -0500 (EST) | From | linux-os <> | Subject | Re: [RFC] dynamic syscalls revisited |
| |
On Mon, 6 Dec 2004, Zwane Mwaikambo wrote:
> On Mon, 6 Dec 2004, Steven Rostedt wrote: > >> I added the following to my sys_dsyscall routine. The routine that is >> the only system call for a user process to access dynamic system calls >> (at anytime), even if dynamic system calls are loaded. >> >> static int is_tainted = 0; >> >> if (tainted & TAINT_PROPRIETARY_MODULE) { >> if (!is_tainted) { >> printk(KERN_INFO "Sorry, can't use dynamic system calls with proprietary modules\n"); >> is_tainted = 1; >> } >> return -EINVAL; >> } >> >> Once a proprietary module is loaded then all dynamic system calls will >> become useless. >> >> This way, only systems that never loaded a proprietary module may be >> able to use dynamic system calls. This may suck for those that have >> NVidia cards, but this may be a start to overcome the problem of >> allowing binary hooks into default kernels. It also is a way to motivate >> end users to not use proprietary modules. > > I didn't know we were on a crusade to end all binary modules at all costs. > Why not just make _all_ symbols in the kernel EXPORT_SYMBOL_GPL then? I > really believe this is taking things to new levels of silliness, we should > also possibly consider adding code in glibc to stop proprietary > libraries/applications from running. What do you think? > > Zwane
Let 'em play their games. We all know how to fork a kernel that works with our requirements. Currently, 'tainted' can be zeroed-out with the /proc interface. Code like the demo above puts one person's policy into the kernel. Policy is not supposed to be inside the kernel.
Cheers, Dick Johnson Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by John Ashcroft. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |