Two Rings Good, Four Rings Bad

NTDEV
41

How about a video card with memory mapped memory? In ring 1, the kernel in
ring 0 can grant access to that memory to the ring 1 driver, but deny access
to it by ring 3 applications. The ring 3 to ring 1 transition and called
driver will have to validate the addresses passed in but if it was to crash,
the kernel could clean up and restart the video driver easier. The ring 1
driver also cannot crash the kernel because the ring 0 addresses are not
available to it.

wrote in message news:xxxxx@ntdev…
> Tim,
>
>> As I think about the design, all drivers would probably live at ring 1,
>> with core operating system services, and maybe the HAL, at ring 0.
>> However, I’ve only spent a few minutes thinking about it.
>
> Think about it a little bit more, and you will understand that there are
> just 2 types of code
>
> 1. Privileged code that is able to crash the OS
>
> 2. Unprivileged one that is unable to do the above, because it is unable
> to execute provileged instructions and because provileged code validates
> all parameters that it receives from unprivileged one.
>
> Even if you introduce sub-gradation of unprivileged code by using the
> additional protection rings,
> validation of calls that it makes still has to be exactly the same for
> all sub-levels (think about it carefully, and you will understand why it
> works this way). In other words, as far as system reliability is
> concerned, you need just 2 and not 4 protection levels
>
> In other words, although at the first glance it seems that 4 protection
> rings may be usefull, after a bit thinking it becones obvious that you
> don’t need more than just 2 of them, no matter how you look at it
>
> Anton Bassov
>
>
>

42

David,

The ring 3 to ring 1 transition and called driver will have to validate the addresses passed in but > if it was to crash, the kernel could clean up and restart the video driver easier…

… which simply defeats the purpose of separating it from all other Ring 3 code - on one hand, it still can be crashed by calls that are made by Ring 3 code if it does not validate them properly, but, on another hand, this crash is not fatal. In other words, it becomes, essentially, just Ring 3 code if you move it to Ring 1…

Anton Bassov

43

I disagree, slightly. You’re only looking at privileged vs non-privileged
*instructions*. There’s more to an OS than just instructions. There are
data structures, some of which are more sensitive than others. By putting
the most sensitive data structures at the innermost ring, you can grant a
device driver access to its registers/memory without granting it access to
the PFN database or scheduling structures or something outside its own
structures.

In addition to rings, there are compartments. Instead of thinking in terms
of rings, think in terms of layers (horizontal). In addition to layers,
there are vertical separations (compartments). The OS can compartmentalize
code in “semi-privileged” layers into different compartments, much like what
happens with user-mode processes.

Of course, all of this has to be designed into the OS from the beginning.
It cannot be shoe-horned in later. Just my $0.02 worth based upon
observation of and working with actual, highly stable, commercial OS
implementations.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, March 29, 2007 10:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Two Rings Good, Four Rings Bad

Tim,

As I think about the design, all drivers would probably live at ring 1,
with core operating system services, and maybe the HAL, at ring 0.
However, I’ve only spent a few minutes thinking about it.

Think about it a little bit more, and you will understand that there are
just 2 types of code

  1. Privileged code that is able to crash the OS

  2. Unprivileged one that is unable to do the above, because it is unable to
    execute provileged instructions and because provileged code validates all
    parameters that it receives from unprivileged one.

Even if you introduce sub-gradation of unprivileged code by using the
additional protection rings,
validation of calls that it makes still has to be *exactly* the same for all
sub-levels (think about it carefully, and you will understand why it works
this way). In other words, as far as system reliability is concerned, you
need just 2 and not 4 protection levels

In other words, although at the first glance it seems that 4 protection
rings may be usefull, after a bit thinking it becones obvious that you don’t
need more than just 2 of them, no matter how you look at it

Anton Bassov

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

44

xxxxx@hotmail.com wrote:

> As I think about the design, all drivers would probably live at ring 1,
> with core operating system services, and maybe the HAL, at ring 0.
> However, I’ve only spent a few minutes thinking about it.
>

Think about it a little bit more, and you will understand that there are just 2 types of code

  1. Privileged code that is able to crash the OS

  2. Unprivileged one that is unable to do the above, because it is unable to execute provileged instructions and because provileged code validates all parameters that it receives from unprivileged one.

Even if you introduce sub-gradation of unprivileged code by using the additional protection rings,
validation of calls that it makes still has to be *exactly* the same for all sub-levels (think about it carefully, and you will understand why it works this way). In other words, as far as system reliability is concerned, you need just 2 and not 4 protection levels

In other words, although at the first glance it seems that 4 protection rings may be usefull, after a bit thinking it becones obvious that you don’t need more than just 2 of them, no matter how you look at it

You only say this because this has been the model in all of the
operating systems you’ve experienced. Don’t allow the currently popular
architecture to close your mind to other possibilities. The Multics
research in the 1960s amply demonstrated the theoretical value of
multiple rings. It wasn’t commercially successful, but that doesn’t
mean the concepts are not valid.

Can you really not see the benefit of having multiple layers of
protection? Consider an application using a database. Involved in the
process, you have the application itself, you have a database manager,
you have a file system, and you have a disk driver. (Yes, in Windows,
the database manager lives in a separate process, but that’s simply an
architectural choice. It might as well be in a single address space, as
long as it is protected.). In a secure system, each of those layers
should be able to communicate only with the layers immediately above and
below it. By using multiple rings, the application can’t damage the
database file by going to the file system outside of the database
manager, nor can it go directly to the disk driver. Everyone has to
follow the chain of command.

Again, remember that I’m not arguing that we should patch Windows to
implement this. I’m merely saying that the concept has merit.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

45

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@hotmail.com wrote:
>>
>
> You only say this because this has been the model in all of the
> operating systems you’ve experienced. Don’t allow the currently popular
> architecture to close your mind to other possibilities. The Multics
> research in the 1960s amply demonstrated the theoretical value of
> multiple rings. It wasn’t commercially successful, but that doesn’t
> mean the concepts are not valid.
>
Actually the research did not. Ironically, there were classes by MIT folks
from the project being given at DEC and Data General at the time of those
companies were designing 32-bit computers with rings. The MIT/Multic’s
folk were absolutely against rings, but the architects of those systems
ignored the info given, and the software teams got to experience all the
problems themselves first hand.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

46

But it all boils down to one simple concept - you have a privileged core which has access to data & instructions which the unpriviledged code can’t be trusted with, and you have unpriviledged code which doesn’t.

Within that unpriviledged code you probably have a great deal of differentiation - different processes, layered components that talk to each other over LPC/RPC, security groups, etc.

The sticking point seems to be whether this needs to be done with “Rings”. I propose it doesn’t. As long as you can make a strong line between priviledged and non-priviledged code/data, and as long as you can compartmentalize non-priviledged code/data it doesn’t really matter if the processor supports 2 levels of execution or 2 + N (the 2 is pretty important though :slight_smile: )

X86 Rings are difficult to use well - at least as far as I’ve thought it through. Unless you can really hurt portability and use segments (and 48 bit pointers screw portability no matter how clever you are with them) the fact that the MMU only supports two levels of protection makes it very hard to do calls through the intermediate rings because you have no way to protect the code & stack of the inner rings without having per-thread page tables. So regardless of whether “rings” are good or not, Windows doesn’t run on a processor today (and hasn’t really in the past) where they aren’t more trouble than they’re worth.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Friday, March 30, 2007 7:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Two Rings Good, Four Rings Bad

I disagree, slightly. You’re only looking at privileged vs non-privileged
*instructions*. There’s more to an OS than just instructions. There are
data structures, some of which are more sensitive than others. By putting
the most sensitive data structures at the innermost ring, you can grant a
device driver access to its registers/memory without granting it access to
the PFN database or scheduling structures or something outside its own
structures.

In addition to rings, there are compartments. Instead of thinking in terms
of rings, think in terms of layers (horizontal). In addition to layers,
there are vertical separations (compartments). The OS can compartmentalize
code in “semi-privileged” layers into different compartments, much like what
happens with user-mode processes.

Of course, all of this has to be designed into the OS from the beginning.
It cannot be shoe-horned in later. Just my $0.02 worth based upon
observation of and working with actual, highly stable, commercial OS
implementations.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, March 29, 2007 10:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Two Rings Good, Four Rings Bad

Tim,

As I think about the design, all drivers would probably live at ring 1,
with core operating system services, and maybe the HAL, at ring 0.
However, I’ve only spent a few minutes thinking about it.

Think about it a little bit more, and you will understand that there are
just 2 types of code

  1. Privileged code that is able to crash the OS

  2. Unprivileged one that is unable to do the above, because it is unable to
    execute provileged instructions and because provileged code validates all
    parameters that it receives from unprivileged one.

Even if you introduce sub-gradation of unprivileged code by using the
additional protection rings,
validation of calls that it makes still has to be *exactly* the same for all
sub-levels (think about it carefully, and you will understand why it works
this way). In other words, as far as system reliability is concerned, you
need just 2 and not 4 protection levels

In other words, although at the first glance it seems that 4 protection
rings may be usefull, after a bit thinking it becones obvious that you don’t
need more than just 2 of them, no matter how you look at it

Anton Bassov

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

47

What about Virtual Machines? VMM run the OS in ring 1. And hypervisor is just really a ring -1. So everything about emulation and virtualization could really use the additional rings.

–

Edouard A.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-282260-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: vendredi 30 mars 2007 18:35
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Two Rings Good, Four Rings Bad

xxxxx@hotmail.com wrote:
>
>> As I think about the design, all drivers would probably live at ring
1,
>> with core operating system services, and maybe the HAL, at ring 0.
>> However, I’ve only spent a few minutes thinking about it.
>>
>
> Think about it a little bit more, and you will understand that there
are just 2 types of code
>
> 1. Privileged code that is able to crash the OS
>
> 2. Unprivileged one that is unable to do the above, because it is
unable to execute provileged instructions and because provileged code
validates all parameters that it receives from unprivileged one.
>
> Even if you introduce sub-gradation of unprivileged code by using the
additional protection rings,
> validation of calls that it makes still has to be *exactly* the same
for all sub-levels (think about it carefully, and you will understand
why it works this way). In other words, as far as system reliability is
concerned, you need just 2 and not 4 protection levels
>
> In other words, although at the first glance it seems that 4
protection rings may be usefull, after a bit thinking it becones
obvious that you don’t need more than just 2 of them, no matter how you
look at it
>

You only say this because this has been the model in all of the
operating systems you’ve experienced. Don’t allow the currently
popular
architecture to close your mind to other possibilities. The Multics
research in the 1960s amply demonstrated the theoretical value of
multiple rings. It wasn’t commercially successful, but that doesn’t
mean the concepts are not valid.

Can you really not see the benefit of having multiple layers of
protection? Consider an application using a database. Involved in the
process, you have the application itself, you have a database manager,
you have a file system, and you have a disk driver. (Yes, in Windows,
the database manager lives in a separate process, but that’s simply an
architectural choice. It might as well be in a single address space,
as
long as it is protected.). In a secure system, each of those layers
should be able to communicate only with the layers immediately above
and
below it. By using multiple rings, the application can’t damage the
database file by going to the file system outside of the database
manager, nor can it go directly to the disk driver. Everyone has to
follow the chain of command.

Again, remember that I’m not arguing that we should patch Windows to
implement this. I’m merely saying that the concept has merit.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

48

I think you finally nailed it when you said:

*But it all boils down to one simple concept - you have a privileged core
*which has access to data & instructions which the unpriviledged code can’t
*be trusted with, and you have unpriviledged code which doesn’t.

That is simply a false assertion. The world is more than just Windows,
Intel and its variants.

I also see the thread that you still have the narrow view of protection as
totally powerless vs omnipotent. There are far finer granularities than
that. MMUs are *NOT* limited to those two modes. Processors also have
instructions that can only run in a certain ring or more powerful ring.
Maybe Intel has only been able to implement those gross levels of
protections, but not all processor/MMUs are so limited. The MMU of a
processor designed with an OS designed to use multiple rings is far more
robust. I return to VAX and Alphas as example. The MMU had access flags in
its to indicate the access level (Write/Read/NoAccess) for each ring. For
the VMS 4-ring architecture, that meant there were 8 bits for each page
indicating the access level. By doing this, you assigned privilege levels
and assigned where (which ring) each piece of code could run. (Yes, it’s a
somewhat simplified description, but that was basically the method. If I
have to, I will dig out my VMS Internals and Data Structures book.) It
worked extremely well and supported an extremely robust, secure and stable
OS.

The key is that VMS was very thoroughly architected with all of this in
mind. It would be nearly impossible to implement this architecture in
Windows without a complete rewrite, therefore I am not pushing that idea in
any way.

*
*X86 Rings are difficult to use well - at least as far as I’ve thought it
*through.
*

*
*the fact that the MMU only supports two levels of protection makes it very
*hard to do calls through the intermediate rings because you have no way to
*protect the code & stack of the inner rings without having per-thread page
*tables. So regardless of whether “rings” are good or not, Windows doesn’t
*run on a processor today (and hasn’t really in the past) where they aren’t
more trouble than they’re worth.


Again, all the world is not WinTel. Just because Intel made only the very
gross granularity of “powerless” vs “omnipotent” doesn’t mean every
processor in the world made the same mistakes. Memory and instructions can
(and are) much more finely protected than that.

Greg

49

The problem with rings is providing the data access that is needed. Over
and over when designing a “ringed” OS architect’s will discover ring 1
needs to access a ring 0 data structure, you then have the unpalatalbe
choices of:

a. Provide access routines with the overhead of the ring crossing
b. Move the data structure to ring 1, when it almost entirely needs
to be in ring 0
c. Split the data structure and manage two structures which for
dynamic data structures can be a pain
d. Have a copy of the data in two rings with the problems of
synchronizing them

This is not a problem with VMM because the OS does not know that there is a
lower layer. The challenges come when you need rings to work together, but
want to avoid ring crossings as much as possible. At least that is what I
found years ago.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Edouard A.” wrote in message news:xxxxx@ntdev…
What about Virtual Machines? VMM run the OS in ring 1. And hypervisor is
just really a ring -1. So everything about emulation and virtualization
could really use the additional rings.

–

Edouard A.

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-282260-
> xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: vendredi 30 mars 2007 18:35
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Two Rings Good, Four Rings Bad
>
> xxxxx@hotmail.com wrote:
> >
> >> As I think about the design, all drivers would probably live at ring
> 1,
> >> with core operating system services, and maybe the HAL, at ring 0.
> >> However, I’ve only spent a few minutes thinking about it.
> >>
> >
> > Think about it a little bit more, and you will understand that there
> are just 2 types of code
> >
> > 1. Privileged code that is able to crash the OS
> >
> > 2. Unprivileged one that is unable to do the above, because it is
> unable to execute provileged instructions and because provileged code
> validates all parameters that it receives from unprivileged one.
> >
> > Even if you introduce sub-gradation of unprivileged code by using the
> additional protection rings,
> > validation of calls that it makes still has to be exactly the same
> for all sub-levels (think about it carefully, and you will understand
> why it works this way). In other words, as far as system reliability is
> concerned, you need just 2 and not 4 protection levels
> >
> > In other words, although at the first glance it seems that 4
> protection rings may be usefull, after a bit thinking it becones
> obvious that you don’t need more than just 2 of them, no matter how you
> look at it
> >
>
> You only say this because this has been the model in all of the
> operating systems you’ve experienced. Don’t allow the currently
> popular
> architecture to close your mind to other possibilities. The Multics
> research in the 1960s amply demonstrated the theoretical value of
> multiple rings. It wasn’t commercially successful, but that doesn’t
> mean the concepts are not valid.
>
> Can you really not see the benefit of having multiple layers of
> protection? Consider an application using a database. Involved in the
> process, you have the application itself, you have a database manager,
> you have a file system, and you have a disk driver. (Yes, in Windows,
> the database manager lives in a separate process, but that’s simply an
> architectural choice. It might as well be in a single address space,
> as
> long as it is protected.). In a secure system, each of those layers
> should be able to communicate only with the layers immediately above
> and
> below it. By using multiple rings, the application can’t damage the
> database file by going to the file system outside of the database
> manager, nor can it go directly to the disk driver. Everyone has to
> follow the chain of command.
>
> Again, remember that I’m not arguing that we should patch Windows to
> implement this. I’m merely saying that the concept has merit.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

50

> you have a file system, and you have a disk driver. (Yes, in Windows,

the database manager lives in a separate process, but that’s simply an
architectural choice. It might as well be in a single address space, as
long as it is protected.).

Jet is exactly this kind of database manager, and not protected. Just a DLL.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

51
  1. you argue semantics now. In the end there’s one layer which has absolute control and the others derive their abilities from that one. My point is that those other layers can be implemented with our without rings. Rings are hardware assisted sugar coating and can be done in software as well as hardware.

I have no doubt that they can be used. There are many processor features which can be used to build stable, robust, secure, colorful, tasty, nice smelling software. What I question is whether they’re some sort of magical thing without which such software cannot be built. Perhaps it’s not your intention, but your constant assertions that VMS’s greatness comes from the ring support implies that you believe they’re somehow critical.

  1. Early in this thread the assertion was made that Windows could have chosen to use the x86 ring hardware with the implication that this would have made the OS better on x86 processors. I believe that doing so would have resulted in a much less portable OS, much more complex code for drivers (since they’d have two code bases effectively) and would have hurt Windows more than it would have helped it.

As to the “wintel” comment … I don’t remember ever claiming that the world was limited to Windows and Intel. But I like how you take my specific comment about using rings on the x86 processor as use it to imply that I lack your grander world view and so my comments are dismissible. As you’ve chosen to dismiss them I won’t bother entering into your “discussion” again.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Friday, March 30, 2007 10:31 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Two Rings Good, Four Rings Bad

I think you finally nailed it when you said:

*But it all boils down to one simple concept - you have a privileged core
*which has access to data & instructions which the unpriviledged code can’t
*be trusted with, and you have unpriviledged code which doesn’t.

That is simply a false assertion. The world is more than just Windows,
Intel and its variants.

I also see the thread that you still have the narrow view of protection as
totally powerless vs omnipotent. There are far finer granularities than
that. MMUs are *NOT* limited to those two modes. Processors also have
instructions that can only run in a certain ring or more powerful ring.
Maybe Intel has only been able to implement those gross levels of
protections, but not all processor/MMUs are so limited. The MMU of a
processor designed with an OS designed to use multiple rings is far more
robust. I return to VAX and Alphas as example. The MMU had access flags in
its to indicate the access level (Write/Read/NoAccess) for each ring. For
the VMS 4-ring architecture, that meant there were 8 bits for each page
indicating the access level. By doing this, you assigned privilege levels
and assigned where (which ring) each piece of code could run. (Yes, it’s a
somewhat simplified description, but that was basically the method. If I
have to, I will dig out my VMS Internals and Data Structures book.) It
worked extremely well and supported an extremely robust, secure and stable
OS.

The key is that VMS was very thoroughly architected with all of this in
mind. It would be nearly impossible to implement this architecture in
Windows without a complete rewrite, therefore I am not pushing that idea in
any way.

*
*X86 Rings are difficult to use well - at least as far as I’ve thought it
*through.
*

*
*the fact that the MMU only supports two levels of protection makes it very
*hard to do calls through the intermediate rings because you have no way to
*protect the code & stack of the inner rings without having per-thread page
*tables. So regardless of whether “rings” are good or not, Windows doesn’t
*run on a processor today (and hasn’t really in the past) where they aren’t
more trouble than they’re worth.


Again, all the world is not WinTel. Just because Intel made only the very
gross granularity of “powerless” vs “omnipotent” doesn’t mean every
processor in the world made the same mistakes. Memory and instructions can
(and are) much more finely protected than that.

Greg

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

52

Could the rings be used as firewalls? The performance would be terrible but
you would need a bug in the ring 1 code and ring 0 code to make kernel
buffer overflows.

–

Edouard A.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-282270-
xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: vendredi 30 mars 2007 19:40
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Two Rings Good, Four Rings Bad

The problem with rings is providing the data access that is needed.
Over
and over when designing a “ringed” OS architect’s will discover ring 1
needs to access a ring 0 data structure, you then have the unpalatalbe
choices of:

a. Provide access routines with the overhead of the ring crossing
b. Move the data structure to ring 1, when it almost entirely
needs
to be in ring 0
c. Split the data structure and manage two structures which for
dynamic data structures can be a pain
d. Have a copy of the data in two rings with the problems of
synchronizing them

This is not a problem with VMM because the OS does not know that there
is a
lower layer. The challenges come when you need rings to work together,
but
want to avoid ring crossings as much as possible. At least that is
what I
found years ago.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Edouard A.” wrote in message news:xxxxx@ntdev…
> What about Virtual Machines? VMM run the OS in ring 1. And hypervisor
> is
> just really a ring -1. So everything about emulation and virtualization
> could really use the additional rings.
>
> –
>
> Edouard A.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-282260-
> > xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> > Sent: vendredi 30 mars 2007 18:35
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Two Rings Good, Four Rings Bad
> >
> > xxxxx@hotmail.com wrote:
> > >
> > >> As I think about the design, all drivers would probably live at
> ring
> > 1,
> > >> with core operating system services, and maybe the HAL, at ring 0.
> > >> However, I’ve only spent a few minutes thinking about it.
> > >>
> > >
> > > Think about it a little bit more, and you will understand that
> there
> > are just 2 types of code
> > >
> > > 1. Privileged code that is able to crash the OS
> > >
> > > 2. Unprivileged one that is unable to do the above, because it is
> > unable to execute provileged instructions and because provileged code
> > validates all parameters that it receives from unprivileged one.
> > >
> > > Even if you introduce sub-gradation of unprivileged code by using
> the
> > additional protection rings,
> > > validation of calls that it makes still has to be exactly the
> same
> > for all sub-levels (think about it carefully, and you will understand
> > why it works this way). In other words, as far as system reliability
> is
> > concerned, you need just 2 and not 4 protection levels
> > >
> > > In other words, although at the first glance it seems that 4
> > protection rings may be usefull, after a bit thinking it becones
> > obvious that you don’t need more than just 2 of them, no matter how
> you
> > look at it
> > >
> >
> > You only say this because this has been the model in all of the
> > operating systems you’ve experienced. Don’t allow the currently
> > popular
> > architecture to close your mind to other possibilities. The Multics
> > research in the 1960s amply demonstrated the theoretical value of
> > multiple rings. It wasn’t commercially successful, but that doesn’t
> > mean the concepts are not valid.
> >
> > Can you really not see the benefit of having multiple layers of
> > protection? Consider an application using a database. Involved in
> the
> > process, you have the application itself, you have a database
> manager,
> > you have a file system, and you have a disk driver. (Yes, in
> Windows,
> > the database manager lives in a separate process, but that’s simply
> an
> > architectural choice. It might as well be in a single address space,
> > as
> > long as it is protected.). In a secure system, each of those layers
> > should be able to communicate only with the layers immediately above
> > and
> > below it. By using multiple rings, the application can’t damage the
> > database file by going to the file system outside of the database
> > manager, nor can it go directly to the disk driver. Everyone has to
> > follow the chain of command.
> >
> > Again, remember that I’m not arguing that we should patch Windows to
> > implement this. I’m merely saying that the concept has merit.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

53

But it’s Microsoft who designed the OS in the way it allows to load junk into kernel address space!

Most of the time I spend in front of my machine I see character-mode text editor (I know I’m old) and
shell to execute “build” utility… So user-mode un-accelerated frame buffer driver running inside
separate virtual machine should work fine. Why do I need 5 megabyte kernel mode driver binary for this? Why
cannot we select 1) run slow but stable frame buffer for 90% of the things we do (modern CPUs can handle
video acceleration in software just great), stable and video card chip ice cold 2) run fast but less
stable kernel-mode drivers for 3D shooters where we really need performance?

Usually I have all sounds disabled. So why playing MP3 with kernel mode driver should low down system
stability? Does sound card driver really have to run inside the same VM and share all the things with
memory manager and OS kernel itself? Is playing “50 cent” THAT important driver crash should put whole
OS on the knees? Are you sure?

Having fancy 15K rpm hard disk drive and fast *MS provided* NTFS driver is great! But why third-party UDF driver
need to run as kernel mode module? Why it cannot run as user mode DLL? I don’t have any problem with 10
megabytes transfer rate from DVD instead of say 20 megabytes (it’s still enough to play the movie w/o
jerking on the screen) but I really have a problem with OS core dumped b/c of the bug in the UDF driver
resulting crash after playback of the DVD with Chinese file names in the root (happened a week ago).

I do understand 10 GbE backbone router has to have TCP/IP stack in kernel… But for my 2 megabit WAN connection
at home I’d really prefer to have it in user mode. So I could either save this Word document or just restart
“network support virtual machine” after it’s crash and not recover .DOC file from backup DVD (if I’d have it
of course…).

Etc etc etc

Biggest problem with NT - it was designed like VMS, OS from 70s. With core OS, drivers and hardware coming from
the same vendor (DEC) or very limited list of vendors. But it’s not 70s anymore… Old OS design does not
work for 2007 (it did not work even for 1995 I think). That’s why S/W virtual machines (VMware, XenSource, Virtual Iron,
Parallels, Virtual PC / Server … ) are getting more and more popular. People are using OS itself with limited
set of TESTED software to run S/W virtual machines doing most of the work. In the other words - end users are not
only testing drivers (something I’d expect OS vendor to do… BTW, Did anybody calculate how much companies
spend on this?), with the help of the software virtual machines they are changing OS main concept: whole combination
of the OS + virtual machine running the same OS inside it = patch to initially broken OS design… VMware with
50 employees saving life to software monster called MSFT. Just great…

I really hope next OS from MS would be re-written from the scratch. And not good old NT. Now with not only 3D UI,
but also with 3D sound for windows moving or whatever marketing gurus would advice.

Guys from MS - READ THIS!! I don’t want to end my days coding kernel stuff for Linux!!

Regards,
Anton A. Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Microsoft.com
Sent: Thursday, March 29, 2007 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Two Rings Good, Four Rings Bad

BTW, VMS was far more stable than NT ever has (or probably ever will be).
And how many 3rd party drivers did it load? Much easier to create a stable OS if you control every component and can test their interactions together. Not saying that all crashes are due to 3rd party drivers, but a good majority of crashes are due extensions loaded in the kernel. My point is that it is not so black and white ;).

d

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

54

Hello Airlie

Please accept my congratulations on your memorable introduction of a new
entrant in the “ntdev long thread” hall of fame :slight_smile:

Best Wishes
Lyndon

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
I believe x64 specifies that only rings 0 and 1 are supported. So clearly
AMD thought that were was so little market for OSes that require or can use
rings 2 and 3 that they cut the feature. (There is a non-zero cost for
hardware features, in design time, verification, fab time, chip area, power,
etc.)

All of this is interesting, from an OS design point of view, but is rather
pointless when applied to NTDEV. The NT model is what it is – two levels
of privelege. So are most of the major, commodity OSes, so it isn’t exactly
an uncommon model.

Also, people should consider the additional complexity that driver
developers would need to deal with. Driver developers already need to
understand IRQLs, paged-vs-non-paged, arbitrary thread context vs. known
thread context, etc. Adding another axis to this would cause a lot more
cognitive load for the developers, and would not in reality deliver much
value. (Whole forests have been cut down to print all of the research
papers on device driver isolation.)

Try to imagine the excruciating number of combinations of paged/non-paged,
4x rings, and multiple drivers all communicating with each other. If I
allocate data at ring 1, and I pass it to a driver or OS component that runs
at ring 0, what should happen? Boom? Now raise that number of combinations
to the power of the average PNP device stack depth, and it quickly becomes
obvious that more than 2 rings just causes insanity. At least if it is
shoe-horned into an existing OS design, and not part of it from the
beginning. (And I don’t know of any OS designed after 1980 where this was a
feature. I’m sure the peanut gallery will point one out, though, if there
is.)

Would I like to have better isolation between drivers? Of course. Which is
why I would suggest looking elsewhere, such as
http://research.microsoft.com/os/singularity/, rather than trying to
resurrect a processor architecture that is not used, and is basically being
abandoned.

________________________________________
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
On Behalf Of Tim Roberts [xxxxx@probo.com]
Sent: Wednesday, March 28, 2007 2:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Driver Programming Fundamentals/Philosophy, was: Re:
Calling NdisRequest() from ProtoclBi

Maxim S. Shatskih wrote:
>> I don’t understand your point, Maxim. Portability between what and what?
>>
>
> All these RISC machines, and now IA64.
>
> Having the OS unportable to any other CPU even theoretically is a bad
> idea.

Nonsense. The ring 1 thing would be implementation detail of the x86
kernels – an added benefit available on architectures that had multiple
levels of protection. It certainly wouldn’t require any source code
changes in drivers, so I am unclear on how it would affect portability.

There are certainly precedents for this. NT supports I/O ports, even
though those do not exist on non-x86 architectures. It supports memory
barriers, even though those only have meaning for certain architectures.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

55


Most of the time I spend in front of my machine I see character-mode text
editor (I know I’m old) and shell to execute “build” utility… So user-mode
un-accelerated frame buffer driver running inside separate virtual machine
should work fine. Why do I need 5 megabyte kernel mode driver binary for
this? Why cannot we select 1) run slow but stable frame buffer for 90% of
the things we do (modern CPUs can handle video acceleration in software just
great), stable and video card chip ice cold 2) run fast but less stable
kernel-mode drivers for 3D shooters where we really need performance?

If the vast majority of people who pay MSFT $ for the OS (and us as a
community almost as directly for drivers) were of the same mind, we would
all be washing Windows instead of building drivers for it.

Just trying to do my part to make this longer than the DDK vs. IDE build
thread.

-dave

56

Greg,

You’re only looking at privileged vs non-privileged *instructions*. There’s more to an OS
than just instructions.

Actually, what I do in my previous post is just trying to apply the same logic to both CPU and the OS - privileged code can crash the system, and unprivileged one should not be able to do so…
This is the basic principle behind separation of privileged and unprivileged code which applies
exactly the same way to both CPU and OS, although it has a different meaning for these two

From the CPU’s perspective, the only thing that has to be done is defining a set of privileged instructions, and making sure that unprivileged code cannot execute them. From the OS’s perspective, much more work has to get done, and it has to get done mainly in software, with some assistance of CPU’s build-in protection features - as you have already properly pointed out, the OS is more than just instructions. However, the logic behind the whole thing is the same for both CPU and OS…

Anton Bassov

57

Tim,

You only say this because this has been the model in all of the operating systems you’ve
experienced. Don’t allow the currently popular architecture to close your mind to
other possibilities.

I see what you mean, but do you see any reason why this or that model may become popular across various architectures, apart from being usefull in *PRACTICE*?

The Multics research in the 1960s amply demonstrated the theoretical value of
multiple rings. It wasn’t commercially successful, but that doesn’t mean the concepts
are not valid.

Although a concept may *THEORETICALLY* be just brilliant, it does not necessarily mean that this concept is usefull in practice. In general, as practice shows, any architecture that fully conforms to all academic requirements and standards is very unlikely to become popular among “commoners” . As you have said yourself, the research demonstrated *theoretical* value of multiple rings, but this concept never made a commercial success…

Concerning the example that you gave … please think about it carefully, and you will understand that, unless you want to make components deal with one another directly, rather than via the system-provided entry points (which is *EXTREMELY* insecure approach in itself), the whole thing needs, again, just 2 protection rings …

Anton Bassov

58

What about the C++ in the kernel thread? I think both it and the one
about a month ago that finally ended with Arlie’s suggestion that we
discuss whether he prefers Coke or Pepsi still have this one beat.

>> xxxxx@msn.com 2007-03-30 21:30 >>>


Most of the time I spend in front of my machine I see character-mode
text
editor (I know I’m old) and shell to execute “build” utility… So
user-mode
un-accelerated frame buffer driver running inside separate virtual
machine
should work fine. Why do I need 5 megabyte kernel mode driver binary
for
this? Why cannot we select 1) run slow but stable frame buffer for 90%
of
the things we do (modern CPUs can handle video acceleration in software
just
great), stable and video card chip ice cold 2) run fast but less
stable
kernel-mode drivers for 3D shooters where we really need performance?

If the vast majority of people who pay MSFT $ for the OS (and us as a
community almost as directly for drivers) were of the same mind, we
would
all be washing Windows instead of building drivers for it.

Just trying to do my part to make this longer than the DDK vs. IDE
build
thread.

-dave

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

59

“As an ntdev discussion grows longer, the probability of a comparison to C++
in the Kernel approaches one.”

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-282303-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Saturday, March 31, 2007 8:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Two Rings Good, Four Rings Bad

What about the C++ in the kernel thread? I think both it and the one
about a month ago that finally ended with Arlie’s suggestion that we
discuss whether he prefers Coke or Pepsi still have this one beat.

>>> xxxxx@msn.com 2007-03-30 21:30 >>>


> Most of the time I spend in front of my machine I see character-mode
> text
> editor (I know I’m old) and shell to execute “build” utility… So
> user-mode
> un-accelerated frame buffer driver running inside separate virtual
> machine
> should work fine. Why do I need 5 megabyte kernel mode driver binary
> for
> this? Why cannot we select 1) run slow but stable frame buffer for 90%
> of
> the things we do (modern CPUs can handle video acceleration in software
> just
> great), stable and video card chip ice cold 2) run fast but less
> stable
> kernel-mode drivers for 3D shooters where we really need performance?
>

If the vast majority of people who pay MSFT $ for the OS (and us as a
community almost as directly for drivers) were of the same mind, we
would
all be washing Windows instead of building drivers for it.

Just trying to do my part to make this longer than the DDK vs. IDE
build
thread.

-dave

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

60

It certainly does.

>> xxxxx@hollistech.com 2007-03-31 09:04 >>>
“As an ntdev discussion grows longer, the probability of a comparison
to C++
in the Kernel approaches one.”

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-282303-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Saturday, March 31, 2007 8:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Two Rings Good, Four Rings Bad

What about the C++ in the kernel thread? I think both it and the
one
about a month ago that finally ended with Arlie’s suggestion that we
discuss whether he prefers Coke or Pepsi still have this one beat.

>>> xxxxx@msn.com 2007-03-30 21:30 >>>


> Most of the time I spend in front of my machine I see character-mode
> text
> editor (I know I’m old) and shell to execute “build” utility… So
> user-mode
> un-accelerated frame buffer driver running inside separate virtual
> machine
> should work fine. Why do I need 5 megabyte kernel mode driver binary
> for
> this? Why cannot we select 1) run slow but stable frame buffer for
90%
> of
> the things we do (modern CPUs can handle video acceleration in
software
> just
> great), stable and video card chip ice cold 2) run fast but less
> stable
> kernel-mode drivers for 3D shooters where we really need
performance?
>

If the vast majority of people who pay MSFT $ for the OS (and us as
a
community almost as directly for drivers) were of the same mind, we
would
all be washing Windows instead of building drivers for it.

Just trying to do my part to make this longer than the DDK vs. IDE
build
thread.

-dave

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer