Martin Gregorie  writes:
> I'm really disapointed that there hasn't been more work done on both
> hardware as OS design to make cross-process interference impossible and
> to properly implement hardware protection rings to stop application-level
> code clobbering the OS and the OS from clobbering to low-level drivers.
>
> This stuff isn't new: systems have been built that way since the early to
> mid 70s. Two examples I know of are the ICL 2900 series and the IBM
> Future Series.
>
> The ICL 2900 architecture supported all the features I mentioned above.
>
> The IBM implementation didn't have hardware rings of oritection but did
> run each process in its own address space. It was initially killed before
> being revived as the System/38, which morphed into the AS/400 before
> being renamed as the iSeries.

> The IBM approach still exists as Power series chips, but the 2900
> architecture is now almost irretrievably lost. Pity, because both systems
> were almost bulletproof in terms of limiting the damage a piece of bad
> code could do.
>
> Linux on X86 chips should be able to provide some protection via the
> three protection rings they (used to?) provide, but does Linux use them
> to prevent one process clobbering another? I'd hope so, but have never
> seen any information about that.

Privilege levels/modes/ringsetc don’t make sense as a process-to-process
isolation technique; they only isolate the kernel from user
processes. Instead process-to-process isolation in Linux (and anything
else vaguely modern) uses the virtual memory system - i.e. running each
process in its address space. The situation in Windows is the same.

The microarchitectural attacks discussed in this thread are unintended
consequences that undermine these and other isolation techniques.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05