| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 10 Nov 2013 16:03:36 +0100 From: Shahbaz Youssefi <shabbyx@...il.com> To: linux-kernel@...r.kernel.org Subject: Partially Privileged Applications Dear all, First, please CC replies to myself. Second, this is an RFC. I've been tampering with an idea for some time now and I've done some research. Finally, I wrote it down here (a terrible place as it turned out): http://shahbaz-youssefi.blogspot.it/2013/11/partially-privileged-applications.html and would like to know what you think. This idea requires an improvement to the CPU architectures to allow unifying kernel and user spaces and perform privileged instructions based on the location of the instruction rather than a manually switched mode (or via traps). Please, do take a look at the link. I'm far from a kernel expert so the idea may not be as rainbows and unicorns as it seems to me right now. But it also may be. In that case, probably we need a push by well-known people (i.e., Linus) to get the manufacturers to implement the feature. At least from a developer's point of view, with this idea you could gdb or even valgrind check the drivers in the very least with much less chance of a kernel oops. How faster can you imagine debugging a kernel module? Thanks, An unfortunate soul who has to deal with buggy kernel modules -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists