OSDev.org

Why do you want to run applications in kernel-mode? You are yet to give any good answers for this. Remember that user-space is awesome and has been specially design to for safe process containment.

I think the OP is talking about a microkernel/servers situation, where the servers need access to resources that a userland program wouldn't. But it would still be sensible to protect the servers from each other. Although not providing complete protection, paging enables protection against accidental access to another server's resources.

If you don't know the provenance of, or simply just don't trust, 3rd party code, then the separation of a system into kernel and user mode can be useful. All of us who've written C have had pointer troubles at some time.

On the other hand, if you know what's what, or if you are clever enough to be using a language which doesn't permit different subsystems to interfere with each other, then this disaggregation seems to be a non-essential feature of modern microprocessors.

I think the OP is talking about a microkernel/servers situation, where the servers need access to resources that a userland program wouldn't.

And both MMIO and port IO can be done perfectly fine from ring 3 - even on a per-device granularity.

dozniak wrote:

d2alphame wrote:some level of protection for the OS by placing it's code and data in a page that is executable + read but cannot be written to (write-protected). I think this at least puts a small sort of caution in place for unintentional interference with the OS by apps running at CPL 0.

You do realise that this protection attribute can be changed at any time by any other code also running in ring0?

It could protect from unintended modification, but that's only small part of the whole protection.

It can still be used to give a memory protection to regular programs , even if it would not protect from malicious code.

Sometime it can be also a good policy to favor the making of non malicious programs, rather than doing everything to avoid malicious code. Specially for something at low level, like gdt, it's unlikely a programmer with good intention would change the gdt by accident, even if it would be very easy for malicious code.

After it's a question of at which level in the system design you allow to execute non trusted code, some 'secure' application context could be made latter with a model using different privilege level, but having a 'trusted' application context in ring0/cpl0 can be useful, it can ease the design of applications, and avoid some overhead. And just having an 'indicative' memory protection can be useful for debugging or still prevent some problems.

h0bby1 wrote:Sometime it can be also a good policy to favor the making of non malicious programs, rather than doing everything to avoid malicious code.

It may be feasible only if you do not intend to ever run any 3rd party code.

Yup! That's what I'll do . I'll place the OS in a write-protected page. Thanks y'all

Hi,

d2alphame wrote:

dozniak wrote:It could protect from unintended modification, but that's only small part of the whole protection.

Yes I realize that. But what can I do?

There are only really 2 cases:

• You know you can trust the code, and therefore don't need any protection and can run it at CPL=0 (e.g. the kernel itself)
• You don't know if you can trust the code or not, and therefore it must be run at CPL=3 (e.g. normal applications)

For your OS, things like device drivers, networking stack, file systems, etc may be trusted (where it's silly to bother caring about protection) or they may not be trusted (where it's silly to run them at CPL=0 in the first place). Regardless of how you look at it, caring about protecting the OS from code running at CPL=0 is silly.

d2alphame wrote:Yup! That's what I'll do . I'll place the OS in a write-protected page. Thanks y'all

That fixes nothing; and just means that the kernel can't write to it's own data without pointless and expensive overhead (e.g. making the page/s writable and flushing TLB beforehand and then making the page/s write-protected and flushing TLB again afterwards).


Cheers,

Brendan

Brendan wrote: For your OS, things like device drivers, networking stack, file systems, etc may be trusted (where it's silly to bother caring about protection) or they may not be trusted (where it's silly to run them at CPL=0 in the first place). Regardless of how you look at it, caring about protecting the OS from code running at CPL=0 is silly.

It can be useful for debugging purpose.