Linux Protection Rings
HTML-код
- Опубликовано: 7 июн 2024
- In this episode of the CyberGizmo we explore where Protection Rings came from, what they do and how they work. Some discussion around Multics, Unix, Windows but mainly Linux.
Support me on Patreon: / djware
Follow me:
Twitter @djware55
Facebook: / don.ware.7758
Discord: / discord
Music Used in this video
"NonStop" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License 
Наука
When talking about Multics and how UNIX "borrowed" from what Bell Labs had learned from Multics I said "Rob Thorton" and it should have been Ken Thompson...Rob Thorton was the 3D genius behind Babylon 5. Yeah I've been re-watching the series...
Still my all time favourite sci-fi series
Love me some B-5. Watching last night... :-)
What I find interesting is that you even know all this stuff :). Keep pumping out them knowledge vids DJ and thanks for sharing as always.
Welcome Tax Action, just a head full of useless computer trivia )
Thank you DJ, keep these coming!
What a goldmine, will be binging your videos! Much appreciated, for a newby to get filtered knowledge from someone so experienced is a blessing!
Thank you, Sid!
Well worded technical explanation and history lesson in one video, amazing! Thank you.
Sorry to post twice, but I just realized that I do have a request for a future episode. I've never in my life requested one from a YT essayist, but since it was mentioned, and I see others do so:
I've written a couple of device drivers; exclusively just to get something to work I that I needed, and succeeded even if it was a hack. It would be wonderful if a _good_ kernel module using Linux 6+ (or even 5) APIs was documented, being developed in a video. Guides exist, I know, but it would be great to see your process, given your experience with multiple generations of Unix (including those without kernel modules, I guess.)
Scott thanks for the suggestion will look into it
@@CyberGizmo People would probably pay for that, too. There's loads of basic content out there, but few with hands steady enough to do what Scott suggested.
absolutely wunderbar presentation
I appreciate you so much! Thank you for your videos. I really believe that the passing down of history and "lore" really does a lot for a more holistic understanding. Not only the "what" things are and where they came from... how they evolved... but especially the why things are how they are. It's one of those "intangible" things that I really think makes a huge difference in the development of one's own understanding and skill set. Anyone can suss out the nuts and bolts of a thing. But the story that goes with it adds so much. This, I think, is an important - if often overlooked - aspect of mentoring. Mentors can educate and guide you, of course. Everyone knows that. But they also can deepen your understanding and get you involved in the story of things. And I think that matters.
I said exactly the same thing to a friend last night. Different societal structures had and haven't had "loremasters" as a role, and I think there's value in those that have them. In this time, I think our "loremasters" are invaluable.
Knowledge can be passed down, lost and rediscovered, in "archival" or written/artistic form, as was the case with the Greek classics and many other discoveries of archaeology, but we always lack context and have no way to verify that we're not missing something that would turn it all on its head (and we almost certainly are.) I'm grateful for these videos, as well.
Awesome. Thanks a lot for your videos.
Great video! Thanks1
Yes, please more. Let the "Linux Internals Series" start!
Will do, thanks Hex Earth
Interesting video, thank you very much.
Welcome Felix
Very Interesting. Thank You.
Welcome Dezmond
@@CyberGizmo My first and last semi-serious IT Experience was with UCSD Pascal run in a Dos shell, during the late 1980's in the Uk. I have a bisa this and bitsa trhat interest in thing IT ever since at a non-professional level. However, for various reasons , I have followed Linux since 2004 ish and now run OpenSuse Leap as my sole Operating System.
Your information in your uploads is interesting and I learn something each time. Thank You.
Thank you, very helpful..
You're welcome!
How about the idea of Immutable systems? can you talk about the subject and maybe show how to use such a system?
I remember that the Vax architecture also has four protection rings, and I think it predates Intel's protected mode. Dec's VMS operating system used these for the kernel, the filesystem, the shell and the user code.
Short answer; Yes more of this stuff.
Will do and thanks Markus
Thanks
Interesting stuff! Thanks for the video...
LLAP
Welcome Bruce
Your videos are gold!
Ah shoot, I hoped that would be something that I could buy my g/f to protect her from Windows 🤣
hmmmm lol
I'm really shocked about the "demon"/"daemon" thing. I started consciously pronouncing both as "demon" years ago, maybe for the wrong reasons if you are correct. You seem to be a primary source for this, yes? I couldn't find other sources, and ran to peers to ask about it, but we are babes in the woods. I'd love to know more (sorry to hyper-focus on something that might be trivial.)
the differentiation came from Steven Bourne during one of his classes on UNIX, I don't think Linux follows that convention as I do no see any mention of it in their docs or source code.
Yes, more of these "it all came from Multics"-videos (joke)! These long lines back in history without drowning in details is really a nice format. A twinkle of trivia here and there only boosts it (is that English?).
You are a Linux fan and probably most of your audience - but why call'em **Linux rings**, when they are **Multics rings**?
I also just discovered that Multics didn't lay down until 2000 and something. Might have been Multics.org
EDIT: That domain was "stolen" by Super Dimensional Fortress (a public access Unix system, run by NetBSD on DECs).
The site is Multicians.org!
Thank you Nitro, and yep will do more like this one. And I understood you clearly, thanks again
I need a mirror to see my ring
I have never seem "demon" being used to reference a device driver, and could not find any reference to it other than this video ...
You probably won't unless you happen to stumble over the AT&T System V source code, its in there.
Took some digging, but this is from Research Unix 10: Its a piece of the comment block for udemon one of the device drivers that handled the file system
/*
* fdemon tiu txt msiz [trace]
* file store demon to handle commands from (tiu).
* the txt arg is not used.
* The maximum message size sent to the user is (msiz).
* If (trace) is present the demon will trace on the specified file.
* the current output is used if '-' is specified.
*/
I did not know that a daemon was not the same as a demon.
Linguistically, they are alternative spellings of the same word, both pronounced "dee-mon." It means "messenger." The same way "paediatrics" and "pediatrics" are the same word with a single pronunciation. "Ae" comes from Latin in this case and is pronounced "ee." The pronunciation "daymon" seems to arise from people trying to emphasize a distinction in words when there really is none.
Thanks for another great video!
But I'd like to act as an advocate of Microsoft Windows for a little.
Microsoft Windows kernel architecture is described among others in the ‘Windows Internals’ book by Mark Russinovich et al. One can acquaint with its fragment about Windows kernel architecture for free thanks to Google Books service (books.google.com/books?id=y83LDgAAQBAJ&pg=PT28&source=gbs_selected_pages&cad=2#v=onepage&q&f=false).
In particular it contains paragraphs ‘Kernel mode vs. User mode’ (Chapter 1) and ‘Virtualization-based security architecture overview’ (Chapter 2) with overall description of actual Windows kernel operating principles.
Also there is a series of three videos about Isolated User Mode in Windows 10 at channel9 (filmed in 2015):
1. Isolated User Mode in Windows 10 with Dave Probert - channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert
2. Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel - channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel
3. More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert - channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert
And I also found there a standalone video ‘Windows 10 Virtual Secure Mode with David Hepkin’ - channel9.msdn.com/Blogs/Seth-Juarez/Windows-10-Virtual-Secure-Mode-with-David-Hepkin
Of course, we can’t name these videos ‘technical documentation’ but they, indeed, contain some information about Windows kernel.
A few piddly points of no real importance.
First, about the history of "rings", I think that a case can be made that they came long before Intel, Unix, or Multics although In The Beginning they had nothing to do with protection/"trust".
Instead, in The Good Days, there was no OS and so each program needed to include software to deal directly with the hardware.
Presumably, at some point in time, people got tired of writing their own versions of this hardware management software and so made it into its own blob that could be added to the other software they wrote.
You just added the deck of cards for your new software to a smaller deck of software that you kept laying around somewhere.
Similarly, someone presumably came up with the bright idea to separate the truly dependent hardware management software from that which effectively created a function/service abstraction which could be made into its own separate "library".
Tanenbaum describes this partitioning into layering of software in his book, "Operating Systems Design and Implementation, 3rd Edition", and specifically mentions Dijkstra's "THE" system which was officially released in 1965, which as I'm sure you are aware, was before Unix hit the fan.
Layer 0 contained code for processor allocation and multiprogramming, layer 1 contained code for memory and drum management, layer 2 contained code for operator-process communications, layer 3 contained code I/O management, layer 4 contained user programs, and layer 5 was for the operator.
Second, Multic was originally run on a GE 645 which didn't originally support "rings" or if you prefer, didn't support any more than two rings.
It had a mode/privilege bit that indicated whether you were in "master" mode or "slave" mode.
The bit about "rings" and what to do to make transitions between them had to be simulated by software until the hardware was changed.
IOW, to go from into the OS ("master" mode) which then routed you to where you wanted to be ("slave" mode) after doing the necessary magic to make it look like there were hardware "rings".
I don't know how the hardware was changed (I'm not a Multician), but presumably something was cooked up to implement a "gate" which is conceptually how you're supposed to go from one ring to another.
In a way, the same sort of non-sense was implemented for Minix-3 in that there's a relatively small amount of code that executes in gawd mode which is capable of doing anything and everything else which executes in user mode, but with a certain hierarchy of trust implemented by controlling what messages can be sent to whom via the gawd mode code.
Third, when the 386 came along, it had hardware recognized gate segment descriptors which could be used to transition from one ring to another *WITHOUT* making a system call (i.e. executing an instruction that causes an interrupt).
To change ring levels, you just did a jump or call referencing the gate and the hardware took care of changing the CPL (Current Privilege Level) when doing so was permissible.
This took significant effort on the part of the hardware, but that's what CISC is for.
But the effort was supposedly less that taking an interrupt to get some code in gawd mode to make a change.
I don't know what OS/2 did with rings, but I doubt that the used the gate descriptors provided by the hardware.
But that's just my guess.
If I'm right, the poor performance that you attribute to the use of rings actually comes from their not using the hardware that Intel provided and instead at best trying to fake rings just the same as the original GE 645 did.
Certainly, there's nothing about rings that requires taking an interrupt in order to have/use them.
I would remind you that Kidder's book "Soul of a New Machine" waved it's arms at how ring protection as implemented on the Eclipse where the upper bits of each address were treated as a ring number.
I don't know what they did to deal with ring transitions, but ISTM that one could get there from here through the use of a little extra hardware that only allowed entry into one ring from another only if one entered the ring at just one location, say, the start of a ring's code.
IOW, no interrupts, no gates, just a jump/call to a particular location.
Fourth, I take issue with your characterization of what Intel wanted to do with its x86 rings.
They created hardware that would let you (the operating system writer) do whatever you wanted, and threw in the kitchen sink so that you could.
But they did not say that ring 0 was for kernel, ring 1 was for device drivers, ... , etc.
You cannot find anything in the Intel 386 programmer reference manual that says anything of this sort.
Moreover, since we're talking about rings in terms of "protection", what we're really talking about is "trust".
Is a particular piece of code trusted enough to use certain resources of the CPU?
This means that only certain ring levels are permitted to use certain instructions.
In the case of I/O instructions, for example, the 386 let you execute them provided that the CPL indicated greater trust/privilege than the IOPL (I/O Privilege Level), not just when the CPL is for gawd mode.
Finally, the reason why I bothered to look at your video after all this time was because I was interested whether it might mention what OSs (if any) might have bothered to use rings and the gate hardware that went with them.
So far as I can tell, Intel threw in rings into the x86 family and Unisys threw in rings and domains into the M-Series 2200s, but so far as I can tell, no OSs really bothered to use these features, presumably because the OSs that already ran on them didn't historically use anything like them.
Assuming that the hardware still works as described, I'd like to think that using gates to go between rings and using segments/banks to protect code is a much better way to implement an OS, but that's not going to happen so long as there's a sizeable existing code base that doesn't know what the are and/or how to deal with them.