2013-11-11 19:44 keltezéssel, Matthias Schniedermeyer írta: > On 11.11.2013 14:05, Shahbaz Youssefi wrote: >> On Sun, Nov 10, 2013 at 8:06 PM, Matthias Schniedermeyer <[email protected]> >> wrote: >>> I don't see a way around "borders" (Papers please), otherwise you can't >>> reject things you don't want, you have to check if that something that >>> is to be done is allowed. For e.g. you would get around every >>> permission-check, because the code you called is allowed to do >>> everything. >> >> You're right actually. Proper linking solves the issue for "good people", >> but I can't think of a not-dirty way for preventing bad calls from >> "bad people". I may get back here if I do find a solution.
Hi, What you describe in your blogpost already exists. It is called real-mode. Imagine yourself as a userspace developer. You make an application and want it to run as fast as possible and therefore you eliminate the mode-switches, which do cost a lot of time. Your only way to stop them is by leaving out .text section and only having the .privileged section. Also, think about the malicious software we had back in the DOS times. You caught one, your computer or atleast your harddrive died. Another problem is the bad developer, they want to test out their application, but they accidentally left out something. Just thinking about myself, I made lots of stupid mistakes when I began development, if the CPU worked per your description, I would have bricked bunch of computers. The whole point of separating kernelspace from userspace is not only the abstraction of hardware, but the security as well. We want to protect the user from having the fear of bricking his or her computer. By this, I don't mean to say that your idea is bad, but right now we can't just trust userspace with 'God' powers. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
