Thou shalt have no other gods before the ANSI C standard 1609

I want to modify that buttertion a little before accepting it.

CORE operating system components are difficult to make memory-safe, but a modern OS contains oodles of code that benefit a lot from compartmentalization, protection etc just like user code does. This is what Multics put in Ring1 and QNX put in different OS processes.

This Ring1 code can be designed just as a normal user process in terms of OS choice etc.; except it must accept to serve user requests.

Amen. To summarize :

Almost all of it can be done in a safe language with great benefits. This really begs to be put in "ring1".

I concede this.

The lower "ring0" part needs OS access, but the actual logic code is a contender for "ring" style.

Ditto.

I concede this is difficult to keep memory-safe.

Such drivers nowadays have "upper-lower" parts, where the lower half is integrated to the interrupt system (ring0) and the upper half with the bulk of the code benefits from a safe environment.

These are functions that show the need for more than user-kernel layers.

Surprisingly large parts of a debugger is a very normal application. There is just an "interface part" to the debuggee that may need to bypbutt some protections.

The problem with them is that they need tight integration with VM code. But this can all be done effectively Ring1-style; you just get a large VM-and-swappable-file-systems component. At least it gets broken out of the ring0 section.

Don't put too much emphasis on performance problems when the product itself is to enhance security. Previously in this thread we seemed near a consensus that memory-safe languages carry an overhead of 5-15% in terms of end time.

Now is someone will help me explain this to mr Thorvalds.

-- mrr