Slashdot Mirror
Linux Study Argues Monolithic OS Design Leads To Critical Exploits (osnews.com)
Long-time Slashdot reader Mike Bouma shares a paper (via OS News) making the case for "a small microkernel as the core of the trusted computing base, with OS services separated into mutually-protected components (servers) -- in contrast to 'monolithic' designs such as Linux, Windows or MacOS."
While intuitive, the benefits of the small trusted computing base have not been quantified to date. We address this by a study of critical Linux CVEs [PDF] where we examine whether they would be prevented or mitigated by a microkernel-based design. We find that almost all exploits are at least mitigated to less than critical severity, and 40% completely eliminated by an OS design based on a verified microkernel, such as seL4....
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Maybe Tanenbaum was right. 26 years isn't that long for this debate to come back around again.
...si hoc legere nimium eruditionis habes...
Correction: They have nano penises.
Tanenbaum - Torvalds debate
The debate opened on January 29, 1992, when Tanenbaum first posted his criticism on the Linux kernel to comp.os.minix, noting how the monolithic design was detrimental to its abilities, in a post titled "LINUX is obsolete".[1] While he initially did not go into great technical detail to explain why he felt that the microkernel design was better, he did suggest that it was mostly related to portability, arguing that the Linux kernel was too closely tied to the x86 line of processors to be of any use in the future, as this architecture would be superseded by then. To put things into perspective, he mentioned how writing a monolithic kernel in 1991 is "a giant step back into the 1970s".
Since the criticism was posted in a public newsgroup, Torvalds was able to respond to it directly. He did so a day later, arguing that MINIX has inherent design flaws (naming the lack of multithreading as a specific example), while acknowledging that he finds the microkernel kernel design to be superior "from a theoretical and aesthetical" point of view.
On social media, in our public education system, on television and the print media. They're everywhere.
Hurry, someone finish Hurd.
Consider QNX and its vulnerabilities (the entire software stack) and here's what we have for the Linux kernel (again, kernel alone) whose source is ostensibly verified by millions of eyes.
And here's another almost shameful development: Linux and Open Source are all the rage amongst Open Source fans, yet for some reasons it's been hinted that Google is transitioning from the monolithic Linux kernel (lacking internal stable API/ABI) to its own microkernel, Fuchsia (with stable API/ABI).
The NT microkernel design came from Digital (DEC) VMS operating system which was running VAX minicomputers. VAX/VMS was arguably the most secure OS at the time, and incredibly annoying to use due to that fact (everything required privileges, all the files were versioned, horrible shell syntax etc).
After 28 years, you think someone would have finished the GNU Hurd kernel. By now, it is so old it is probably full of potential exploits, too.
... all it takes is time and effort. The idea that computers can be "secure" when they need to be fundamentally honest if one is to maintain performance of being demanded its a bit of bullshit. You can have slow and secure or you can have blazing fast and honest. Many "Security issues" are really just artifacts of hardware or software architecture.
The reality is security has to be designed from the get go from both a hardware and software standpoint, you can't just do it when fundamentally for most of x86's history it's been an open platform. Security can't be had on open platforms, in fact most issues would never have arisen pre-internet.
The reality is the speed at which computers operate and the demands for security are at odds, no one is willing to pay the true costs because it's just not worth the time and resources unless you are a big organization and have lots of money to throw around.
I'm planning a new language stronger than C for kernel developers.
Once developed, it has a new problem: the migration from a language to another language will require many months of men's efforts to translate it.
There is not magical compiler for this translation.
These days, the largest security threat is probably web browsers: They usually have direct access to the most critical information a user has (passwords, all personal files under their user account, data from all the external services the user accesses, etc.) Under the very same OS user account, web browsers also download and run thousands of untrusted programs from random locations on the internet every day (we'll ignore the handful of hardcore geeks who run Noscript).
The boundary separating these two realms is enormous and incredibly convoluted, involves many layers of abstraction (some of which can be breached by a single misplaced bracket or quote character), and is enforced entirely by the web browser itself. It presents a massive attack surface that dwarfs even the most monolithic OS API.
Sounds like their's is many orders of magnitude bigger than yours.
It's not quite accurate to say the "design came from Digital..." Dave Cutler, who worked on VMS V4 went to work for MS and built the W/NT (Windows/New Technology, and also WNT=VMS+1) based on the knowledge he'd acquired at Digital. Digital sued, and won.
The VAX/VMS system, later OpenVMS (because "Open" was a popular word, not because it was any more open than any other proprietary O/S, although you could get sources, originally on microfiche and later on CD) not only WAS but still IS one of the most secure systems. Banks, hospitals, medical facilities, and the government continue to use it today because of that.
You don't like the "horrible shell syntax"? No worries, Dave Kashtan from SRI/TGV/Cisco wrote Eunice, a Unix-style shell and tools so you could have your favorite CLI environment without having to learn Digital Comand Language (DCL). Dave and Ken Adelman (the guy who beat Barbra Streisand and created her eponymous "effect") used their knowledge of the VMS kernel and Eunice to write a TCP/IP networking stack that worked with the kernel at kernel speeds... beating out the inferior stacks by halfass developers like Process Software, Wollongong, and even Digital itself. (Of note is that Carnegie Mellon University built an open-source stack called CMU-TEK that (once Tektronix released their claims on it) was free, you could build it yourself, and was a great learning experience).
The point of all this is that the VMS kernel was secure, is secure, but wasn't a microkernel at all. While it made system calls to the File Management System (FMS) and the On Disk System (ODS-2) and the Record Management System (RMS, what would be like a file based record management system) were part of the library of system calls, the implementation operated within the kernel.
The VAX processor in 1978 had five operating modes, and putting aside PDP-11 compatibility mode, those were in the onion-layer model User, Executive, Supervisor, and Kernel. This was the first hardware processor to put into play the concepts we use today *EXCEPT* that it was totally enforced by hardware.
That includes an execute bit for page mapped memory. DECADES ahead of anyone else doing anything like that. /history
E
For example: - MacOS has a micro kernel - OpenBSD is a monolithic design and is probably the most secure OS
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
Microkernels are the most secure ones because nobody uses them (out of labs).
MacOS is based on Mach microkernel yet somehow its Darwin kernel is mostly monolithic. What gives? Perhaps microkernels made too many difficulties for practical use?
Don't let your ignorance get in the way of your mouth, either.
Having spent several thousand hours of my life dredging through Darwin's kernel interfaces, I can tell you the beating heart of Mach, the actual microkernel inside of MacOS, is literally dwarfed by the monstrous amounts of monolithic BSD and Mac bolt-ons.
In the end, I found the Mach aspect of Darwin served little purpose beyond making it more annoying to work in that Kernel. It sure didn't slow me down in my task of modifying the Kernel's page tables from user-space on an iPhone.
I love it when people who have no idea what they're talking about make such confident assertions.
NTOSKRNL runs its filesystems, object manager, executive, etc. in kernel space. In what way was this ever a microkernel design by any commonly accepted definition of the term?
While monolithic kernel design results in more code being given access that do not need, it also mandates a homogeny of code for provided services. This help ensure oversight of critical sections of code that could otherwise be poorly implemented, left unreviewed or have high implementation fragmentation.
Microkernels are technically safer designs but the culture of code review is equally important.
Anons need not reply. Questions end with a question mark.
Security isn't just confidentiality. It's Confidentiality, Integrity, and Availably (CIA). If the machine isn't running, it isn't provide secure services to the users.
The micro-kernel architecture ala Tanenbaum fails the security requirement of Availability; micro-kernel systems don't provide what people need. People use Linux because the design works well for building what people need.
While machines were a lot slower then, it still doesn't seem that users (or system vendors) are willing to sacrifice performance for safety.
The problem with microkernels is the same as it always was, performance. Largely caused by the overheads intrinsic NOT having access to necessary data to perform some function and having to call out for it. Security auditing is a biggy there.
And if you think a microkernel is so wonderful, instead of doing pseudo-studies to prove they are so great, write one instead and prove it.
See subject: Especially for Linux/BSD vs. Win32/64 model which was good/accurate! I improved it in speed for *NIX + features https://it.slashdot.org/commen...
* HOWEVER: My program can't "do it all vs. EVERY threat" (nothing can)! E.G. BGP exploit (can't stop it).
STILL - It DOES do MORE for far less resources & more SPEED/SECURITY/RELIABILITY & anonymity vs. ANY single other "so-called 'solution'" (LOADED w/ security issues (DNS redirect & 99% of ISP dns are not proofed vs. it, OpenDNS is + it filters threats also aiding layered security here OR Antivirus (Tavis Ormandy anyone?)).
Due to complexity & C/C++ buffer overflows via null-terminated strings (corrected to an extent in C++11 std.but NOT all C++ compilers are fully compliant of that std. - Object Pascal HAS NO SUCH ISSUE))!
APK
P.S.=> My use of Object Pascal (Delphi for Win32/64 & FreePascal for Linux/BSD 64-bit) avoids it & Pascal beat C++ in stringwork by 4-5x in a test (& math by double))... apk
MacOS (formerly OS X, not the weird crap that preceeded it) was never a microkernel design. Nor its Mach-based NEXT/OPENSTEP predecessors. Same goes for Tru64.
Let's get this clear: Any operating system that has filesystems or network stacks in kernel space is strictly monolithic. All this talk of 'microkernels' and 'hybrids' is tech press wank.
IIRC, the debate was really over whether or not an OS should span different system processors to provide users with a similar experience/capabilities rather than just concentrate on the latest processors with a specific operating model. I don't see how it applies to the security debate of today.
I would consider the '86-'286-'386 to be different processors because of the 16 bit unprotected page ('86) versus 16 bit protected ('286) and 32 bit protected and flat ('386). The Minix micro-kernel was custom to each processor family and provided the ability to run apps on different systems. Linux was designed for the '386 (and follow on processors), ignoring the previous versions of hardware and making the assumption that anything less than the '386 was going the way of the dinosaur.
Regardless of the approach, don't forget that 25+ years ago, networking was quite primitive - most home users were using telephone line modems and businesses had closed networks (if they had them at all). Lynx was the web browser of choice (Mosaic was still a year or two away). Network/computer security was in its infancy (Sandra Bullock's "The Net" was a few years away). Email barely existed (I was working at IBM at the time and was able to get "myke@ibm.com" without anybody questioning it or there even being standards applied to email accounts).
So, I don't think you can say that if Tanenbaum won Linus over to the microkernel (as well as Microsoft and other vendors) there wouldn't be the security concerns of today. I can't see how potential security flaws (which would be obvious by people looking at it from a contemporary eye) would have been avoided as the software stack of 1992 evolved into the stack of today if the microkernel approach was taken then.
Mimetics Inc. Twitter
This is academic until we have solid open-source operating systems based on a microkernel fit for general use - and we're almost there.
Genode (https://www.genode.org) is a really interesting project, a microkernel OS wherein the subsystems and policies are set up for resiliency and security. It actually can run on Linux, but it also works in conjunction with a variety of the L4 microkernels which go a long way towards solving the overhead problem characteristic of microkernels. It does seem to blur the line between hypervisor and host OS, but it seems awfully promising as a pragmatic response to the microkernel vs. monolithic debate.
In fact, I don't know why we even mention HURD when Genode is so far along.
OSF-1 was monolithic. All the stuff that did Unix lived in the same address space as Mach 2.5.
More people have heard of HURD than Genode. Don't underestimate the importance of mind-share. That's why the mainstream OSes are mainstream, and not niche. Also to borrow a Ballmerism. Drivers! Drivers! Drivers!
Who the fuck is this? What is this shyte?
It is awesome
When the monolithic kernel is going bigger and bigger, it will EXPLODE your brain!!!
https://en.wikipedia.org/wiki/...
http://michaelsmith.id.au
Web browsers rival operating systems in size and complexity, and are also hopelessly insecure. The main problem, shared with microkernels, is that the protection mechanisms available in common hardware don't allow efficient or convenient communication between protection domains, which are tied to address spaces. In order to cross the boundary, the address mappings must be flushed and reloaded, or at least manipulated, which are both very expensive operations. This makes any IPC very expensive, so the preferred means of communicating is by sharing memory, and for convenience and performance, nearly everything ends up in the same address space. Thus, the inevitable compromise of any part of these monolithic kernels and applications, is a compromise of the whole.
Without better hardware mechanisms for protection, that allow for efficient protection within the kernel and applications themselves, effective security will remain illusory. The furious and endless effort will continue in a futile attempt to hold the line against the flood of exploits. It is an intractable problem, unless we can shrink the protection domains to contain the effects of inevitable breaches. Capability-based addressing as with CHERI offers one approach, and the Mill architecture offers another. (see the Memory, Security, and IPC talks specifically.) Each represent a different set of trade-offs, which will limit applications. In any case, it is an area that needs work, so if there really are any nerds left on Slashdot, get to it, or at least help fund such efforts.
Apple's first attempt to get an OS running on Mach was, of all things, a Linux port. I don't think the code has been updated since the 2.x kernel series, but if it were to be resurrected, then perhaps there's less of a need to "move on" than the article's author believes.
Maybe you were thinking of VMS?
http://michaelsmith.id.au
Can you show us those cameras have no security hole punched in?
Could you please show us the code?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
> Looks like even Microsoft did something right with their micro kernel design.
Except their userland is crap. So that negates all of the benefits of the microkernel.
A Pirate and a Puritan look the same on a balance sheet.
Looks like even Microsoft did something right with their micro kernel design.
Uhm...
...a monolithic system, such as Linux, Windows or MacOS...
Hell, they even moved graphics subsystem and a web server into kernel space.
Ezekiel 23:20
APK Hosts File Engine 2.0++ 64-bit for Linux & BSD h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p
Yields more security/speed/reliability/anonymity vs. any 1 solution (99% of threats use hostnames vs. IP address most firewalls use) more efficiently/FASTER + NATIVELY 4 less!
Vs. "Bolt on 'MoAr' illogic-logic" slowing you hosts speed u up 2 ways: Adblocks + Hardcode fav. sites u spend most time @ vs. competition loaded w/ security bugs (DNS/AntiVir) + overheads slowing u (messagepass 'souled-out' to advertiser addons + filtering drivers) & their complexity leads to exploitation!
* ONLY 1 of its kind in GUI 4 Linux/BSD!
(Better vs. Windows model in speed/efficiency/merge)
APK
P.S.=> Protects vs. script trackers/ads/DNS request tracking + redirect poisoned or downed DNS/botnets/malware downloads/malcript/email malicious payloads... apk
Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017
Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid - by JazzLad April 20, 2016
his hosts program is actually pretty good by xenotransplant August 10 2015
his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015
I like your host file system by Karmashock September 09 2015
that APK guy, I use his host file by rogoshen1 Tuesday March 03, 2015
I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017
* Linux model = faster/more efficient
APK
P.S.=> APK Hosts File Engine 9.0++ SR-1 32/64-bit for Windows https://www.google.com/search?...
Mikrokernel-based OSes are not widespread as monolithic kernel-based OSes, so are not as exposed to threats and research. Also, in mikrokernel-based designs, the OS components REQUIRE privileged access to each other's interfaces, and these interfaces are also exposed to user processes (QNX anyone?).
Doesn't exist? Micro kernels have to existed since 1969. They were a fad, a buzz word, in the early 1980s, like block chain in now. Then again in the 1990s, a resurgence of micro-kernel articles in the trade mags, and academic research. Some of the largest companies tried micro-kernel. They found out it doesn't work. The services that run in kernel mode, within the kernel address space, on all successful kernels are there for a reason. Multiple separate kernel THREADS work, and even a monolithic kernel like Linux has separate kernel threads.
What eventaully happened to achieve many of the goals of micro-kernel advocates, using some of the same ideas, is supervisors. Hypervisor's can be pretty small (or very large), and run a kernel as a process (not many processes) on top.
> from people who know even less than you do.
One of us is a kernel developer, the other thinks micro-kernels (many of them, btw) don't exist.
I enjoy talking to someone who has a different point of view than I, but next time you come to insult me please bring a clue. I see you don't have one today.
Because that is where all the people are.
Will a microkernel mitigate application-level exploits? No. And really, the application level is the important level because the OS itself is a pretty useless source of user data.
Will a microkernel prevent a certain class of exploits? Probably. But if the platform is unsuitable for applications, then the question is moot.
Maybe they want to commercialize Mach 3? Mach 3 was supposed to be BoBW, but apparently nobody actually believed that.
It's fundamentally a hardware problem, and this is the inevitable result. When security is too expensive or cumbersome, it doesn't get used. All of the "microkernels" in wide use are actually hybrids for this reason. The core problem remains undressed, and apparently few even recognize what it is. Instead, people prefer to rehash the micro-vs-monolithic kernel debate ad nauseam, and accept deficient hardware as a given.
NT's core's described as a "hybrid kernel" by Dr. Mark Russinovich in Windows NT magazine (iirc article was titled "Is NT UNIX?") & it's a good description... I *THINK* that was the article he illustrated it as thus in fact (check to be sure). See https://duckduckgo.com/?q=%22R...
* NT graphics in 3.5/3.51 were in USERMODE (slower & hence why DirectX API came along to make it FASTER there & safer than going pure kernelmode for speed, 4.0 onward (directX 3 is as far as it goes there & NOT FULLY, iirc)).
APK
P.S.=> I thought YOU were "long gone w/ the DAWN" Jeremiah Cornelius - guess your TROLLING EVIL never dies, eh? LOL... apk
Be fair, the grandparent said "MacOS has a micro kernel", and technically that is correct. Like many other Apple "features", the functionality itself is irrelevant and often broken; only appearances matter. This is not meant as an insult to Apple engineers, just a sad reflection of Apple's priorities.
QNX is fit for cars, phones, desktops, servers, clusters, industrial controllers, mission critical things, and so on, and so forth.
linux is used for all those things too, but frankly a lot less fit. In fact, windows is used for all those things, but even less fit.
Plenty of point, I say.
Utterly irrelevant to bring up a little embedded OS fit for cars and blackberries and compare it to Linux. You have no point,
You are misinformed. Google Fuchsia is being designed for embedded applications, mobile devices and computers.
It may very well replace also those closed modified Linux boxes used internally.
Sorry, that's not correct.
XNU's Mach component is based on Mach 3.0, although it's not used as a microkernel.
That is the last thing I would think of. I would first printout that Linux is emphatically not a microkernel and Linus would never, ever concede that he was wrong in the micro vs macro kernel argument so that will not change. No, the first organisations I would think of would be GNU (HURD), FreeBSD, Apple (OS/X) and others.
Congratulations on finding one oddball application for which someone decided to use a micro-kernel. Specifically where it's not a general-purpose computer, performance doesn't matter, and there's no need to run more than one application at a time.
The next time I'm trying to build a slow as hell access KVM on specially designed hardware, I'll consider a micro-kernel. Only, of course, if I can't use a GPL kernel because I'm trying to keep everything secret.
Start with the GEMSOS microkernel and build everything else on that. Then you will have secure computers.
Users don't, by and large, choose an OS for it's security. They choose an OS for it's functionality and ability to run applications they want.
I also think that to simply assert that a "secure microkernel design", by itself, automatically brings these benefits, is more than a little suspect. I mean, how does one achieve certainty that the system is "secure"? Best practices insists that security is a continuum, not a simple binary state. But let us put that objection away.
Microkernel design is asserted to be a the thing here too, right? OK, but MacOS is already a microkernel OS (Mach), and so is Windows. I'm not sure about Linux, but already the article is wrong about 2 out of the 3 quoted examples.
Next up is the implementation issues. Seems to me that following some quality process, like SDLC, is going to be pretty important. Probably more important than this notional "secure microkernel" idea. Well guess what, Microsoft (at least) has been following SDLC since about 2003.
Finally, what's this about playing up seL4 as support for this idea? That's Secure Linux if I'm not mistaken, but the authors trashed Linux, so are they saying that seLinux automagically transformed Linux into their nirvana of a "secure microkernel"? Well, that's just wrong. seLinux does not architecturally transform Linux in that way, that's complete nonsense.
But again, let's put that objection away. Just how popular has seLinux been? And the answer has been, not very. Which brings us back to my first point, which is that people don't normally select an OS for it's security attributes. No matter how much some OS or security wonk wants them to.
The beOS had Micro kernel, blazing fast for the time.
It lives in a very, very complex sandbox, with a huge attack surface. But it is just as much an installed app as anything else.
What is needed is Secure HTML. It would not support everything that flashes and spins. No JavaScript. Not much CSS. Very limited interactions with non-origin sites. Such a thing could be made reasonably secure, and still support the all-important Material Design.
But nobody cares.
As to an "App" having access to all a users files, you are thinking too much of *nix. The world changed when Apple introduced basic sand boxing in IoS. It is long over due that I should be able to easily run installed Linux apps without giving them control over everything that I own.
As to micro kernels, it would seem that they are maybe 10% slower. And nobody wants an operating system that is 10% slower just because it is more secure.
The final piece is the C/++ programming language. And ungly mess that actively encourages buffer overflows and other joys. Most of the code in an O/S can be written using something decent. All the non-micro kernel bits anyway.
Windows NT was Cutler's next time around. MacOS X (technically Mach) was Tevanian's first time.
Pretty interesting how things worked out.
If you want to know about a really secure operatig system you should look into "ICL VME". Quick quote from the Architecture part of the Wiki page:
"VME is structured as a set of layers, each layer having access to resources at different levels of abstraction. Virtual resources provided by one layer are constructed from the virtual resources offered by the layer below. Access to the resources of each layer is controlled through a set of Access Levels: in order for a process to use a resource at a particular access level, it must have an access key offering access to that level. The concept is similar to the "rings of protection" in Multics. The architecture allows 16 access levels, of which the outer 6 are reserved for user-level code "
It might not have a fancy GUI but VME is rock solid when it comes to security. I'm an old git now and Ive worked at low level on Windows, Linux, Unix, OSX, and VME. VME makes the rest of the operating systems look like kids toys when it comes to security, process separation, allocation of resources etc. etc.
Originally the VME instruction set and the processor that ran them were designed together and it's just an absolute work of art. Each process runs at an "access control level" and your process cannot change this without using a hardware instruction that cannot be run from a higher (less privileged) level. Similarly you cannot walk back down your stack beyond your VMs base address , or attempt to access memory that you don't have permission to, as the operating system will detect this and immediately end your VM (with an associated beautifully laid out dump in a journal)
The designers of the system were light years ahead of everyone else. It's just a shame Fujitsu were allowed to buy VME as they now seem intent on pricing it our of existence.
So they found that a number of exploits against the Linux kernel would fail against a micro-kernel. Their conclusion: micro-kernel is safer.
Wait a moment: how do they rule out that new exploits would come up expressly targetting the micro-kernel and failing against the monolithic kernel?
Strong logic.
So STFU - Linux is the worst - get over it.
... resulting from monolithic design problems:
https://linux.slashdot.org/com...
https://www.mail-archive.com/f...
https://slashdot.org/comments....
"Some companies have long considered Smalltalk their "secret weapon" because they could upgrade their systems at least at the application level while the applications continued to run. I guess I've been in computing so long and seen much better innovations like QNX and Smalltalk get passed by in favor stuff like Linux and Java that I guess I don't expect good innovations to be adopted except perhaps decades later. Anyway, I still have a lot of respect for Linus and his accomplishments in bringing a community of people together to do FOSS software. A free Linux is better than an unfree QNX in that sense. Nobody is perfect. And obviously a lot of people here are defending Linus' choice of strong language. Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance?"
Anyway, nice to see this discussion come up again years later related to a more detailed analysis.
The reason I did not want to use Linux in the first place in the 1990s was because Unix was obviously an out-dated design compared to microkernel-based QNX etc.. But in the end the large community adopted it and so I did too. But I did not have to like the unfortunate core technical choices that traded off things like security, upgradability, understandability, and consistency for a claim to be a bit speedier on certain hardware.
Sort of like Intel's hardware design choices to emphasize speed over security are also now coming home to roost.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
I Hurd that.
Kernels' loading modules takes too much time and is prone to attacks. .dlls .asp and .net .... Lets not repeat the mistake that Microsoft made in the 90's. Keep the programming languages for Desktop, Workstations away from the Internet programming languages.
Example: Windows OS loads drivers and
One BIG Kernel is faster than a microkernel.
I used to compile the linux kernel on slackware adding modules into the linux kernel which made it very fast and responsive using one BIG Kernel Tarball that didn't have to look for modules.
My opinion is that one big linux kernel tarball is more secure than microkernels loading modules.
Also, mixing programming languages for desktop programs and Internet programs can cause the Internet server to take over the desktop.
Example: In the 90's Microsoft was trying to integrate Desktop with Internet Servers using
windows runs (part of) the web server in the kernel too
Minix?
https://en.m.wikipedia.org/wik...
Minix?
https://en.m.wikipedia.org/wik...
There's no real need to start insulting people. Anyone who works with large scale software knows full well that modular designs are inherently more secure, it's just a basic fact on the premise that by limiting the interfaces between components, you control the access points and limit the attack vectors - it doesn't matter if you're talking about a large scale distribute web application, or a micro-kernel. Monoliths simply just do not sufficiently restrict the flow of data between constituent components to only that which is necessary for the simple fact that the lack of hard boundaries between components is inherent in the very definition of a monolith.
Your argument isn't inherently wrong, it's absolutely true that time-to-market has a significant impact on the success of software, and that monolithic software can be built more quickly - but you have to also accept that a lot of shit has ended up the defacto standard simply because it got there first, and that doesn't make it good, or more secure.
We're past the point now where the OS wars really matter, market shares seem pretty settled, and impossible to budge despite decades of people attempting to so, but despite that cross-compatibility is becoming common, from Steam pushing greater Windows-Mac-Linux compatibility for games, through to Microsoft slowly making more and more of it's flagship stuff multi-platform through initiatives such as .NET core. As such, I think there is now a reasonable argument that OS vendors have breathing space to go back and re-evaluate whether they should take the time to consider investigating different approaches to next-gen operating systems without the pressure of time-to-market corrupting those decisions, they now have the luxury of opting for best, rather than fastest to market for the next generation, as there's no race anymore.
This already happened somewhat with web browsers. We saw a period where Microsoft and Netscape fought it out to the point Microsoft was dominant with no meaningful new release for about 5 years. Then Firefox, something new and much better hit the market, and it took the lead for some time. Eventually Google released Chrome, a browser that did things differently, a browser that was no longer monolithic like Firefox, and IE before it, one that ensured proper process separation, and as a result Chrome rapidly took the crown because it was faster and more secure. Microsoft took the same approach with Edge, and we're now in a weird situation where Microsoft and Google have the most secure offerings, whilst Firefox is a buggy, vulnerable PoS in comparison - why? Precisely because Google, and subsequently Microsoft took the time to re-evaluate the fundamental architectures of their browsers, to ditch the monolithic designs, and to build something new, and guess what? It was better.
"It's always been that way" is not a valid argument that something should always be that way, I'm sorry but it's just not. We have ample evidence that taking the time to break down monoliths into more modern modular designs offers much better software, there's no reason to think that operating systems should be any different other than people still fighting a fight from two industry giants nearly 3 decades ago - get over it, it's time to move on. Linus was right in getting something to market, and getting it here effectively, Tanenbaum was right from a theoretical standpoint - we now have the space and knowledge to put theory into practice effectively, we didn't back then because there was too much of a race on between Linux, Unixes, Mac, Windows, OS/2 still and time to market trumped all, it just doesn't anymore - that fight is over.
If Firefox runs under a different user, it cannot access your main profile.
C:\Windows\System32\runas.exe /user:firefox /savecred "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"
Thanks for your thoughtful post.
The thing is, it's not about time to market. It's about time to execute an operation. Fifty years is enough time to bring something to market.
Memory access takes half a tick, Double Data Rate RAM (DDR) transfers data on the rising and falling edge.
Context switching is an order of magnitude slower, theoretically, and two orders of magnitude in real life. As Meltdown and Spectre remind us, when switching context you have to flush all the caches, meaning everything is going to cache miss after a switch.
Microsoft and Apple didn't give up on the micro-kernel idea because they wanted to get something out the door, they gave up on that idea because it does not work. Operations take around 50 times longer to complete, especially on larger multi-tasking systems. Anywhere performance matters at all, message passing fails miserably.
It's not a matter of "It's always been that way". In fact the opposite - the point is they DID try micro-kernel, many people tried it, and every time they found out (again) that it does not work.
It reminds me of the policy debates that come up and people want the federal government to try policy X. Someone points out that because policy X sounds like an interesting idea to try, it WAS tried in California, New York, Chicago, the UK, and elsewhere. Everywhere it was tried, the effect it had was exactly the opposite of what was intended. Yet some people can't give up on evangelizing enforcing policy X on the federal level, because it sounded good. Yeah maybe it did sound interesting, that's why numerous people tried it, and it turns it it did not work. Time to try things that can work well.
Sounds great. So where can I download this magical OS, that can do everything I need to get done and is compatible with my hardware?
No one should ever take that retard APK's advise on security. Why?
Apart from being a well known prolific spammer, harasser, and liar his work has many failing.
Most notably is the false premise that hosts provides good security. The truth is that black lists are the worst way to try and do security. They can never list all possible hosts or even all hosts in a sub domain. They are easily circumvented and are always out of date. This still ignores the amount of effort it takes to maintain them. Everything that APK is trying to accomplish is better done by other available solutions.
When one successfully refutes what APK says he is unable to respond in his own defense and will attempt to change the subject to deflect from his own failure. Like when he says hosts does port filtering, that the Chinese copied him, that security experts agree with him. Each and every time APK failed to refute anything said about his statements even when what he said was shown to be false and every time tried to change the subject because he lost.
APK is a failure and a retard, never take his advise.
Sorry retard APK, you are proven to be a lying retard who can't backup your claims. Your retarded ass got destroyed because your work is shit. No one should take your security advise as you even provide evidence from security experts saying that your methods don't work. I'm sure you will throw a fit again because I am exposing to everyone that you are a loser but when your failure is this great everyone needs to know to steer clear of your work if they want actual security.
Context switching with core pinning on a 12 core, hyperthreaded processor takes several microseconds in total. 1600ns for the actual switch, then a multiple of that for for LLC, etc. Contrast in-context memory access of 1ns with cache hit, up to 12ns for cache miss. Micro-kernel with many cores is 100-1,000 times slower.
So then maybe you start making changes to the micro-kernel model in order to have it work well on physical processors. Maybe you ask "how CAN we use SMP to separate concerns, putting aside any old assumptions from ukernel religion and instead trying to accomplish the goals by using many cores effectively?" Starting with the goals of micro-kernel evangelists and then going where the facts take you, you end up writing a hypervisor.
Have you seen the Combos snack food? It's a little tube of cracker or pretzel filled with cheese flavored filling, or pizza flavored filling. They are sold at gas stations next to the chips and crackers. That idea started out as a croissant stuffed with crab meat. Through product development, it became something rather different - ans successful.
It's not that what the ukernel advocates we're trying to accomplish was wrong, or even that their implementation was completely bananas. It's just that as you revise and extend the micro-kernel ideas to have them work well, it develops into virtualization, with what was the kernel becoming the hypervisor. That works well. What doesn't work is a religious attachment to the initial ideas of how a micro-kernel could be implemented and how it might work. Those were just ideas, like the croissant with crab meat idea. Developing it into something that works requires letting go of the emotional attachment to crab.
What "so-called 'solution'" does MORE for less resource use & complexity leading to its exploitation? DNS or AntiVirus or addons?? All security issue riddled resource hogs!
Wildcards lead to FALSE POSITIVES GALORE (hosts specifics do not & are easy to edit by anyone) - whitelists are maintenance nightmares even moreso!
Hosts SPEED YOU UP 2 ways:Hardcoded favorite sites avoiding slower security issue riddled DNS & blocking ads alone offsets any parse & THE ONLY PARSE THAT HAS TO BE FAST is your FAVORITE SITES you spend MOST TIME @ online @ TOP of hosts cached in RAM operating in kernelmode!
NoScript has to PARSE ads script src tags etc.: Hosts don't & OPERATE LONG BEFORE NoScript does on 3rd party scripts (the most dangerous ones) in kernelmode speed making NoScript REDUNDANT SLOWER USELESS!
APK
P.S.=> You are just (& yes, I've gotta say it) "too, Too, TOO EASY - just '2ez'" to BLOW AWAY as always, lol... apk
What solution does MORE for less resource use & complexity leading to its exploitation? DNS/AntiVirus/Addons?? All security issue riddled resource hogs!
Wildcards lead to FALSE POSITIVES GALORE (hosts specifics do not & are easy to edit by anyone) - whitelists are maintenance nightmares even moreso!
Hosts SPEED YOU UP 2 ways:Hardcoded favorite sites avoiding slower security issue riddled DNS & blocking ads alone offsets any parse & THE ONLY PARSE THAT HAS TO BE FAST is your FAVORITE SITES you spend MOST TIME @ online @ TOP of hosts cached in RAM operating in kernelmode (blocked ones, the majority of my hosts file, you NEVER intend to get to anyhow stupid)!
NoScript has to PARSE ads script src tags etc.: Hosts don't & OPERATE LONG BEFORE NoScript does on 3rd party scripts (the most dangerous ones) in kernelmode speed making NoScript REDUNDANT SLOWER USELESS!
APK
P.S.=> You are just (& yes, I've gotta say it) "too, Too, TOO EASY - just '2ez'" to BLOW AWAY... apk
Hmm... cherry pick much? Lots of critics justifying calling MacOS monolithic despite the Mach kernel, but not a peep about OpenBSD, which IS monolithic and which IS the most secure OS
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
I see you again failed to refute any criticism of your work and thus conceded. Instead you try to deflect away from your failure thus further proving my point that you know you lost and are a retard but even then I have already responded to those comments elsewhere. Just because your reputation is built upon a lie you told long ago doesn't mean you need to keep telling that lie if only to keep it alive in your mind. The truth is hosts is an ineffective security solution. Unless you can provide real proof that black lists are effective, you can't, you need to stop with your lie. We are done here as you have nothing of value to add other than continuing to make an ass of yourself.
DNS/Antivirus/Addons = security flaws+slowup vs. hosts & they use more resources by FAR! Some 'solution' for security when they have security issues (or don't work by default like Adblock) & SLOWUP - hosts speed you up 2 ways by comparison.
Wildcards PRODUCE false positives like MAD - hosts specifics don't & any end user can EASILY edit hosts too!
I make maintaining hosts EASY via my program.
Hosts files get CACHED by any OS' caching subsystem - fast in kernelmode (vs. slower/less cpu prioritized usermode "solutions" you speak of messagepassing overheads GALORE & resource use like mad - for what? DOING LESS THAN HOSTS DOES by itself (does more for less vs. ANY other 'competitor' by far)). The IP stack & hosts do the resolutions of fav sites + blocked ones (& should BE the ONLY THING that does).
APK
P.S.=> It's been a PLEASURE totalling you, again, as always - easily... apk
APK is a lying sack of shit.
He lied here, and he lies everywhere:
I don't threaten vs. a NOBODY
Shut your fucking pie hole you lying sack of shit.
You threaten people all the time and when called on it you hide in the fucking corner and piss yourself.
So come on pussycake post your fucking address
> Describing it as more of a hypervisor is along the lines of what I was thinking; although having a full independent kernel on each core is a bit much I think. Perhaps a very limited kernel, without drivers but with limited memory management capabilities is in order.
"Without drivers" is exactly how I use virtualization, and how I believe it's most often done at scale. The guests use virtio, not hardware drivers. The kernel is effectively divided into one thing that ONLY handles hardware, and completely separate thing that is ignorant of the hardware but responsible for scheduling user processes and that sort of thing. The "hardware kernel" is the hypervisor. The other thing that provides kernel-like userland is the guest kernel. The CPU runs the guest in ring 1 (guest mode) rather than ring 0 (supervisor or kernel mode). We CALL it a "guest kernel", but the CPU doesn't run it in the same mode as an actual kernel. The hypervisor is the real kernel, as far as how the CPU treats it.
What we find is that the kernel (or kernel-like thing) performs operations over and over that don't require direct access to CPU registers, but do require one part of the kernel to talk to another part. For efficiency, those needs to run in the same process space, using memory accesses. In other words, that chunk needs to be monolithic. But because it doesn't need direct access to CPU registers, it doesn't have to be THE kernel. It can be a monolithic guest kernel that is oblivious to the hardware, so it doesn't need drivers, just virtio.
Linux is still a microkernel.
The Availability term used in CIA was availability of the computer system, as in uptime. An excellent example of this being Windows 10's forced updates. Tanenbaum's microkernel design would never 'go down' completely except for actual upgrades of the microkernel core, and even then it might be possible to do an in place upgrade if microkernel A and microkernel B handle state information either unchanged or with code in place to update the state information as the new microkernel initializes.
Tanenbaum's plan was essentially for 0 downtime systems that could handle any software fault and most hardware faults by restarting subsystems, with existing non-realtime applications unaware anything happened, and non-critical realtime applications given the information needed to recover after the fault. Hard realtime applications require systems designed from the ground up to be fault tolerant, usually by throwing redundant and self-correcting hardware at the problem to keep downtime to the length of time to validate information between redundant cores, which would be factored into the hard realtime system's actions.
DirectX began in the Windows 9x series. It was a way to bypass the Windows imaging and windowing models, and blit direct to hardware. Programmers at the time laughed and said, "Oh yeah, DOS!"
"Flyin' in just a sweet place,
Never been known to fail..."