Messages in this thread | | | Date | Mon, 5 Jul 2004 01:32:50 +0200 | From | andrea@cpushare ... | Subject | Re: secure computing for 2.6.7 |
| |
On Sun, Jul 04, 2004 at 02:35:26PM -0700, Andrew Morton wrote: > Of course, yes, the patch is sufficiently safe and simple for it to be
Ok, great.
> mergeable in 2.6, if this is the way we want to do secure computing. I'd
In the last weekends I evaluated many different ways to solve the issue (most of them in userspace because they would have the huge advantage of working in other OS too, the python way that parsed the bytecode looked quite intriguing, but it's an order of magnitude slower compared to x86 bytecode and it was a lot more complex to make it work with the math module and similar other safe operations, plus it was non portable to non-x86 arch [though portable to other x86 OS] and I believe it was less secure since the virtual machine was still involved).
At the end this linux centric kernel-space solution I'm proposing is the only simple enough way that I would be confortable enough to trust myself without feeling to risk anything, plus it will run the stuff at full speed and with zero memory resource waste for another virtual machine. This approach basically can only break if the cpu has bugs (like 0xf00f or an mmx capable processor on a non-mmx aware OS, mmx is not backwards compatible cpu feature w.r.t. security) but linux is getting everything right in terms of cpu bugs.
BTW, of course this will also require a "safe" userspace loader, that will take care of closing all file descriptors and to set the stack rlimit before enabling the kernel feature, but that's very easy to implement safely (even easier than the kernel side).
One interesting thing is that the vsyscalls will make gettimeofday available too, but I don't think the output of gettimeofday can be considered sensitive data. Though I need to keep an eye open on the vsyscall page to be sure nothing sensitive goes in there.
> wonder whether the API should be syscall-based rather than /proc-based, and
I find the /proc-based simpler, but I certainly wouldn't be against making it a syscall. So just let me know if you prefer to change it to a syscall. The syscall would be a bit faster to run but it's not a fast path.
> whether there should be a config option for it.
I don't think it worth to have a config option for this (you could return to use testb instead of testw but it doesn't seem to be significant enough to require a config option),
> But the wider questions are stuff like "where is all this coming from", > "where will it all end up" and "what are the alternatives".
I'm not ready to talk about my usage, but it has absolutely nothing to do with the kernel (except for needing this kind of feature from either the kernel, or from an higher level virtual machine). So this probably wouldn't be the appropriate forum.
Thanks a lot for the quick and positive comments. - 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/
| |