One of his dumber takes. Virtualization replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel" (KVM and the userland hypervisor). It's a drastic attack surface reduction, and the empirical data bears that out: kernel LPEs aren't even newsworthy (there's whole repos full of unnamed, unremarked-upon LPEs), and KVM escapes are very rare.
Virtualization is responsible for effectively none of those security benefits.
It is the reduction to a smaller “kernel” that is responsible. If you applied the same design and operational model to running regular old processes instead of virtual machines you would also get a system with less security holes than the grossly insecure rat’s nest that is Linux, Windows, or whatever other commercial IT OS you have in mind.
Virtualization is almost entirely orthogonal, if not harmful, to security of the platform and operations. It is not magic pixie dust that makes your operational model more robust. You need a robust operational model, then you can have a robust operational model with virtual machines.
There is a reason why the most secure systems in the world are separation kernel architectures instead of hypervisors even though most of those systems do support virtualization as a feature, just not as the basis of their security propertys.
While this is true, the unspoken factor here is compatibility. Fixing the design and operational model of Linux (or any Unix derivative) to a sensible default-nothing architecture requires completely changing the semantics of the OS, which would break so much existing software to the point that one might as well write a new kernel+userspace from scratch. It's a lot easier for a sysadmin to just plop their existing rat's nest in a hardware-accelerated parallel universe and say "job done".
Sure, this is why virtualization is a valuable feature, it is just not the basis of security/isolation.
One of the points I am making is that when deploying on a modern multi-tenant VM-based platform, VM orchestration is analogous to process orchestration. However, you orchestrate the units, VMs, in a very different way to how you would orchestrate processes on say Linux. If your platform orchestrates, configures, and operates processes the same way a VM-based platform orchestrates, configures, and operates VMs and your implementation is solid then you would see similar security benefits. Virtualization is not the key. It just kind of looks that way because virtualization is usually paired with a fundamental re-architecture.
In greenfield application development or cases where you would do single-application VMs, you would target processes/platform directly. Only in situations where you are literally lifting code from a different OS environment that you can not or will not port to the native model would you need to go through a VM. If you orchestrate them the same way and your operational models for them are similar, then you will usually see similar outcomes. This is how it works in high security microkernels/separation kernels which simultaneously allow native processes alongside VMs. Virtualization is a feature to allow non-porting, it is not security/isolation; that is already provided underneath.
Great, then falsify it. Point at a system with the same operational model as KVM-based multi-tenant systems with large numbers of platform vulnerabilitys.
Let us review a standard operational model:
Virtual machines are usually pre-allocated their total RAM. Virtual machines are usually pre-allocated a number of cores and pinned to them. Virtual machines are usually only allocated a small number of devices such as a virtual block storage device and virtual network device upon which they implement a in-VM filesystem and network stack. Virtual machines usually have no access to shared services provided by the hypervisor.
So we have a operational model where you have to pre-allocate RAM to a process. You have to pre-allocate a whole core and pin the process to it. The process has no access to a global filesystem, network stack, or devices. The process has access to exactly one file, which is logically similar to a virtual block storage device, and a single raw network socket, which is logically similar to a virtual network device. The process has no ability to form a socket to another process, form a new file, or even have any way of interacting with other processes at all. The process has no access to shared services of any kind.
The chasm between that operational model and any commercial IT operating system is immense, being basically the polar opposite in every dimension in the direction of security. Default-deny instead of default-allow. Shared-nothing instead of shared-everything. What you have there is a system even more static and simple than what runs on most microkernels. That is the comparable class of platforms with a similar operational model.
To demonstrate that virtualization is the key factor, you need to demonstrate that actually comparable systems with similar operational models like microkernels have more platform vulnerabilitys than comparable KVM-based, or even just hypervisor-based, systems. Which, again, flies against the face of evidence as the systems that are actually used in high security applications designed to protect against state actors are separation kernels instead of hypervisors.
Cool, show me a LPE in a seL4 deployment. Do you believe that is easier or harder than finding a KVM escape?
Since you are varying the security basis, implementation, and operational model simultaneously when you are comparing KVM to Linux to argue that the security basis is the important factor, I get to as well. Except mine is actually more fair because the design of a seL4-based system is actually much more similar to the design of a multi-tenant KVM-based system than the design of the KVM-based system is to the design of a Linux user environment.
Amusingly, this is the 2nd time you've tried to argue with me about this Theo post. Last time, you yourself brought it up as a model of a good security argument.
Rather than replicating my response then, I'll just incorporate that link into my point.
I ported L4 to my ARM NUC a couple weeks ago. L4 is great. Of course, L4 is also principally a platform for virtualization, so it's a pretty odd bit of evidence to try to bring up. Where have you personally been using L4?
Yes, you do enjoy evading the argument. You continuously point at implementation and operational model differences as proof that virtualization is the key factor. Theo's argument is literally that virtualization versus non-virtualization is irrelevant compared to implementation and operational model deficiencys. If you make garbage implementations and operational models, then you get garbage virtualization. If you have a good implementation and operational model then you do not need virtualization for "security".
As independent evidence for this point, virtualization is not the basis of security/isolation in seL4. You have isolation without any virtual machines. Virtual machines are just a feature on top that can leverage the existing isolation functionality to also provide isolated virtual machines. Of course, a secure deployment then requires you to leverage this foundation with a good operational model and system design since you can always make a insecure system even atop a good foundation. This demonstrates that virtualization is not necessary for a secure base, nor sufficient to achieve highly secure systems.
Just to hammer in the point that you are heavily misinterpreting Theo's response, this is the full sentence at the start of the post that Theo was responding to:
"Virtualization seems to have a lot of security benefits. Rootkits can lie to DomU but not Dom0, and of course snapshotting, migration etc is really nice."
Wow, amazing, rootkits can never be in Dom0 because Xen has "virtualization" magic pixie dust. Theo is pointing out how this is nonsense and virtualization will only provide security if you can create implementations without glaring security holes. Furthermore, you should not just listen to the people who brought you insecure system 1 when they tell you that this time for sure they are going to give you secure system 2; maybe have just a little bit of cynicism and ask for some evidence first.
Doesn't that message date back to a time that either predates or is almost concurrent with the introduction of x86 hardware-assisted virtualization? I wasn't around playing with VMs back then, but I'm not sure that the track record of x86 virtualization 20 years ago was that great.
It does, but that's an argument about implementations, and his comment is an argument about design. Just read it again and see if you think it's reasonable. Pay attention to the tone and (especially) the conclusory certainty he deploys.
I’ll take someone who’s dumb over someone who is smart but rudely and confidently incorrect any day. Modesty, thoughtfulness, and kindness are too-undervalued virtues in our business.
The email in question actually addresses one of the first, if not the first, x86 hypervisor product, Xen, relying on both my memory of the time (I did some work with Xen in the mid aughts) and Wikipedia: <https://en.wikipedia.org/wiki/Timeline_of_virtualization_tec...>.
The Xen hypervisor itself was pretty minimal, as I understand mostly serving to time-slice CPU cycles among guest domains and partition memory access. As a contrast to VMWare, device access and drivers were handled by the guests themselves.
As such, the attack surface of the Xen hypervisor itself is fairly minimal. Most security issues seem to be denial of service vulnerabilities, though there are some privilege escalation, access, information leak, and overflow issues listed:
AMD released (ie commercially available) Pacifica on May 23, 2006 while Intel did released their Vanderpool a half of year earlier November 14, 2005. [0]
Windows Server 2008 was RTM'ed on February 2008 which provided Hyper-V as a first class component. [1]
Virtual Server 2005 R2 SP1 added support for both Intel VT (IVT) and AMD Virtualization (AMD-V) and was released 11 June 2007. [2]
> replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel"
Is a Proxmox kernel that much smaller than a typical Linux kernel?
I mean, I agree there. We all have dumb takes! I hear roughly once a month about my old "I don't think Dual EC is a backdoor, it's too dumb and obvious for anyone to actually use it" take.
Probably people are responding less to the dumbness of the take and more the arrogance of the tone combined with the dumbness of the take. Everyone has dumb takes, not everyone is an asshole while giving their dumb takes.
Regardless i do agree with you though, not sure what the point of digging up ancient skeletons is.
I'm anti virtualization, but mostly due to the internal complexities of the guest applications being swept under the rug, it's undeniable that the host is protected and thus neighbouring guests (of course it is with almost 20 years of hindsight I can say this.)
That the hypervisor is effectively an operating system/kernel I have always held, and that it is a smaller and thus less vulnerable kernel is an appropriate explication I think. It's very hard to secure an all purpose kernel like Linux without actually building it yourself (and even then..)
Thanks for sharing the forbes link. From the link:
"De Raadt says BSD could have become the world's most popular open source operating system, except that a lawsuit over BSD scared away developers, who went off to work on Linux and stayed there even after BSD was deemed legal."
There is some truth to that. And who knows where BSDs might have been if the lawsuit never happened.
However, I think Linux has always has and till today has better leadership, and management compared to OpenBSD.
I also think GPLv2 was another good that happened to Linux. It just creates an irresistible force to contribute back. With *BSD, a company might contribute back or it may not.
Ha! That’s some rose-colored-glasses view of BSD history.
The lawsuit didn’t help. But the BSD developers shot themselves in the foot when they refused to support x86, referring to it as a “toy”.
It wasn't until Linux came along and started eating up all of BSD's user base that they freaked out and decided x86 support might be a good idea. But by then it was too late.
I don't recall them refusing to support x86, but BSD development was mostly done by academics rewriting and improving AT&T UNIX, which was mostly on big iron systems of the time. They were focused on academic computer science work. The lawsuits stopped a lot of BSD work as the universities were sorting it all out. William and Lynne Jolitz start porting 4.3BSD to the Intel 80386 at Berkeley in 1989 (but the code wasn't released for years due to said lawsuit) before Linux existed. That is the first BSD-on-x86 work; by December 1990 they had contributed a working port to UCB. Most of the code didn't see the light of day until ~1992.
Also, usable and production ready BSDs were running large websites on x86 long before linux became mainstream and well-supported enough to be used. The BSD TCP/IP stack was the reference implementation for ages and BSD was heavily used in the internet's early days as a lot of early companies spun out of Californian universities. Hotmail ran on FreeBSD. Early SunOS variants were based off of BSD, as were some other commercial unixes.
The bigger killer, I think, is that BSD was (and still has) a bit of closed mindset to newcomers and were and are more conservative to new technology, despite some foundations of techbeing started with them. Docker's origins can be directly traced to FreeBSD jails. Sometimes the conservatism is warranted and a benefit (eg OpenSSH).
GhostBSD DragonflyBSD pf/opn sense even funky hybrid stuff like Chimera Linux, out of curiosity I had a quick search and the list goes on https://github.com/DiscoverBSD/awesome-bsd
Linux has a lot of corporate sponsorship and its own legal hurdles of the past (SCO le sigh.)
386BSD came out about the right time, but as noted, development was slow, and the original author abandoned it pretty quickly while at the same time Linux was actively gaining traction and growing rapidly.
Quotes below:
"No one else saw the 386 as interesting. Berkeley had a myopic attitude toward PCs. They were just toys. No one would support Intel." — Jordan Hubbard [1]
---
Jolitz's project, of course, found many people on the Net who didn't think it was just a toy. Once he put the source code on the Net, a bloom of enthusiasm spread through the universities and waystations of the world. People wanted to experiment with a high-grade OS and most could only afford relatively cheap hardware like the 386. Sure, places like Berkeley could get the government grant money and the big corporate donations, but 2,000-plus other schools were stuck waiting. Jolitz's version of 386BSD struck a chord.
While news traveled quickly to some corners, it didn't reach Finland. Network Release 2 came in June 1991, right around the same time that Linus Torvalds was poking around looking for a high-grade OS to use in experiments. Jolitz's 386BSD came out about six months later as Torvalds began to dig into creating the OS he would later call Linux. Soon afterward, Jolitz lost interest in the project and let it lie, but others came along. In fact, two groups called NetBSD and FreeBSD sprang up to carry the torch.
--- [2]
I never believe people when they say, we would have been famous if not for one piece of bad luck 35 years ago.
Yeah, i'm sure the lawsuit was crappy and set things back. But if you can't recover after 35 years, then its something deeper than what happened 35 years ago.
It's hard to blame OpenBSD's management when there are three other BSDs. You didn't have to work with Theo de Raadt to work on BSD. But while the lawsuit may have been the catalyst, the game was really over when GNOME took off. BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans. At that point pretty much everyone making interesting desktop stuff went to Linux and never looked back. Which is not solely a license issue; you can definitely release GPL software for FreeBSD, but the "license war" culture (to the extent it really existed) may have been an issue.
And I guess I do think that FreeBSD had a saner organization pattern than the sort of haphazard ecosystem of projects that grew up around GNU and Linux. Maybe the chaos was necessary for growth, but it still seems to be a hurdle for new Linux users in the current day.
i think what the chaos did was enable more individual contributors. you didn't have to join the BSD team to get a core OS tool accepted into the system. anyone could just mix and match the tools and apps they liked. it's not that BSD prevented that but that they just didn't invite it. you can create your own spin of a distribution and if it gets enough users and contributors it gets accepted as an official version. there is even a debian variant using a BSD kernel. try making a official BSD spin using GNU coreutils.
> The development of Debian GNU/kFreeBSD has officially terminated as of July 2023 due to the lack of interest and volunteers. You may find the official announcement here[1]
> BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans.
oh boy its' much worse than that: KDE/GNOME were already largely precarious before that.
The whole Xorg thing was really dependant on gpu drivers and the story between linux gpu drivers and *bsd gpu drivers was so much different. Having the BSDs be fairly different didn't really help (eg: only FreeBSD had official nvidia drivers, albeit proprietary).
Gnome did take a lot of backlash and Gnome essentially became a meme at some point ("what's the use case for that?")
Gnome did take a strong dependency on systemd (both gnome and systemd are developed by Red Hat, btw).
And Gnome also did push a lot for wayland (that wasn't implemented on the various BSDs for a long time).
I haven't checked in a while, but I think Gnome is wayland-only nowadays ?
Ultimately, the real issue with KDE/GNOME and the BSDs is that the BSDs are largely irrelevant and essentially only relevant for some specific use-cases where desktop usage is not involved.
I mean, Torvalds has called basically every person on earth an asshole at some point, hasn’t he? He’s the opposite of being sparing with critisicism, and frankly has historically often used his bully pulpit to do it.
There are many extremely competent engineers who can’t deal with the idea of exposing themselves to public humiliation. That’s especially true in today’s environment where these kind of bully rants have become a spectacle for outsiders. Just google the name of the person who was the subject to one of Linus’ rants about a year ago. Despite being a very accomplished figure in the RISC-V world, top results for his name are links to Linus calling him an idiot. That’s a mark he will have for life. I would die of embarrassment.
It’s perfectly possible to critique without being a bully.
What Theo and Linus are doing wrong is scaring away a large pool of potential contributors who don’t want to take that risk.
> It’s perfectly possible to critique without being a bully.
Yep. And it's perfectly possible to accept being called stupid, if you truly did do something boneheaded. It's not a permanent scar that ruins the rest of your life, as you seem to believe.
> What Theo and Linus are doing wrong is scaring away a large pool of potential contributors who don’t want to take that risk.
> I don't classify thin skinned snowflakes who do stupid things that get them screamed at by Linus, and then are butthurt about it for years, as being "extremely competent."
There is no reason to believe that there is a causation between being a “thin skinned snowflake” and being incompetent. That said, it doesn’t surprise me at all that some kind of people would make that assumption.
> A
simple tool was presented, iofuzz, that exposes exploitable
security flaws in most, if not all, virtual machines available
today. To the knowledge of the author, no similar research has
been conducted before. The results produced by crashme, a
tool well known for over a decade, locating trivial flaws dem-
onstrates this.
No virtual machine tested was robust enough to withstand
the testing procedure used, and multiple exploitable flaws
were presented that could allow an attacker restricted to a vir-
tualised environment to reliably escape onto the host system.
The results obtained demonstrate the need for further
research into virtualisation security and prove that virtualisa-
tion is no security panacea.
He’s not wrong based on the research at the time. The mistake is presenting this as if it’s something that will be true for all time. Is virtualization a panacea? No. CPU manufacturers can’t even protect against side channel attacks. But it’s completely missing what this provides which is that the difficulty and cost of creating an exploit is higher today than 20 years ago. And it’s amusing to hear someone blasting away at the security of others when BSD has its own share of problems and architectural weaknesses are discovered through popularity of your system being an attack target, not because you’re smarter than everyone else and made better choices (sometimes it can be true in places, but harder to maintain for a big piece of software like an OS)
I don't understand the constant (almost always unsubstantiated) criticism of the *BSDs from many Linux advocates.
Personally I evaluate each OS by it's merit, and I've concluded that OpenBSD, FreeBSD and some Linux distributions(I use arch btw) are solid operating systems.
On the server I prefer FreeBSD because of it's amazing flexibility, and stable yet evolutionary base system and in my opinion, superior init system. Simple RC scripts FTW.
I use Arch Linux for superior software and hardware support, related to client usage.
If you like Arch and init systems with simple RC scripts, check out Artix Linux (https://artixlinux.org/), which is an Arch-based Linux distribution that supports multiple options for init systems.
Some people keep classic flames alive to deploy in times of need. Theo's good, but he can't hold a candle to the late Marc Cripsin railing about emacs line-mode-visual. Grr.
>What mindless cretin thought that it should be a good idea to make
line-move-visual be the default in emacs 23?
I just found out about this charming "improvement" in the worst possible
way. Investigation determined that a "routine" software update had just
installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software.
This is an example why. Emacs' line behavior has well over 30 years of
history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults
alone.
>If you want to have your own playpen where you twiddle defaults to your
hearts content, have at it. But don't pretend that you produce software
for a production environment, and stop telling the Linux distributions
that they should "upgrade" to your "improved" versions. People doing real
work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users
don't get the release notes and don't even know that a new release
happened. It is also unreasonable to expect users to subscribe to every
obscure newsgroup, forum, and wiki to hear about changes that will turn
their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all
the .emacs files on all the dozens of other machines I use, even though
they still have emacs 22, because otherwise this unpleasant surprise will
repeat itself over and over again.
>Grr.
>From: Mark Crispin, To: comp.lang.emacs
>They made the wrong decision. Changes to default behavior are a bad idea.
Changes to default behavior of the most basic functionality are an
extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from
skunk to lemon. But I damn well do care about the most basic operations:
all CTRL single letter and ESC single letter. After 33+ years of using
emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file,
or my terminal emulator window, or my system. The fact that the problem
went away on a different system added further confusion. It was only when
I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines,
but only on one system, that I realized that emacs changed. And that's
when I did ESC X describe-key CTRL/N and read about line-mode-visual,
although it did not mention that this was now the default.
ESR's free to make ridiculous laws about eyeballs that aren't true and nobody follows while never actually reviewing any code himself (except for the climate scientists' code which he totally misunderstood and dishonestly misrepresented), but blaming it on Linus was a dick mode.
>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
porridgeraisin: Speaking of ICCCM (aka I39L) and X11 selections, have you seen David Rosenthal's glorious rant about the Sun Desktop that somebody leaked to the unix-haters mailing list (who, moi?), which comes straight from the author of the ICCCM and co-developer of Andrew, X10, X11, and NeWS. The Roy Lichtenstein line is classic. What he's touching on by "Why can't they just shut up and do their job efficiently and inconspicuously?" is Mark Weiser's "Ubiquitous/Calm Computing". He's married to Mark's widow Victoria Reich, and they both work on LOCKSS ("Lots of Copies Keep Stuff Safe").
PS - I notice that someone filed a bug today pointing out
that even your example of dropping a mail message on CM
doesn't work if CM is closed. That's a symptom of the kind
of arrogance that all the deskset tools seem to show -
they're so whizzy and important that they deserve acres of
screen real estate. Why can't they just shut up and do
their job efficiently and inconspicuously? Why do they have
to shove their bells and whistles in my face all the time?
They're like 50's American cars - huge and covered with
fins. What I want is more like a BMW, small, efficient,
elegant and understated. Your focus on the whizzy demos may
look great at trade shows, but who wants to have their tools
screaming at them for attention all the time? It's like
having a Roy Lichtenstein painting on your bedroom wall.
Check out his blog, recently he's been writing about his introduction to computer graphics, hacking late at night in the basement of the lab on the PDP-7 connected to the Titan at Cambridge University, and how Coprophagia Is Bad For You! He was employee #4 at NVIDIA.
If OpenBSD pretended Qubes OS was a feature prototype/reference OS build and made a fork of OpenBSD to feature-match Qubes OS (calling it QuBSD or something), that would be great!
I wished more people would take issue with developers' bad attitudes.
I know this is an extremely unpopular take, but I refuse to use software where the main dev(s) are openly abusive to others. Sadly this includes the majority of open source operating systems and many other very popular applications... but it's my decision and you're welcome to disagree with me. I am not trying to prevent others from using said software, and I don't look down on them for it.
I think if everyone was always forced to separate the art from the artist, then boycotting wouldn't even be a thing, so there should probably be some kind of middle ground.
There was no abuse and bad attitude. He was telling the truth about Linux hypervisors. And it got worse since then. Then they talked Xen, which at least has a security boundary. Now everybody switched to kvm with none. Only speed matters, security not at all.
Disagree, but regardless, both Theo and Linus have long, storied histories of prolonged habitual abuse without much remorse. Even after Linus "stepped back", it never really stopped after he came back.
We'll probably also disagree on what is abuse or not, but that's ok.
"My favorite part of the "many eyes" argument is how few bugs
were found by the two eyes of Eric (the originator of the
statement). All the many eyes are apparently attached to a
lot of hands that type lots of words about many eyes, and
never actually audit code." -Theo de Raadt
I don't know who this guy is but this is just a shitty way to interact with people. Presumably he's successful or we wouldn't be talking about him without any introduction, but I wouldn't hire this person to sweep the floors at my office.
Don't take this personally, but I am sorry to have to inform you that it was, in fact, almost 20 years ago. Just months after Rihanna released Umbrella, and a year after Mika released
Relax.
I think de Raadt and OpenBSD are hugely overrated and some takes are as dumb as the one in the post.
OpenBSD is only secure because because it does pretty much nothing and does it very slowly (its firewall just recently broke the 4gbps firewalling capabilty, for example) but somehow a cult has formed around it ¯\_(ツ)_/¯
In all seriousness, the OpenBSD guys are very conservative with technology. The OpenBSD pf stack (as well as much of the kernel) isn't heavily threaded due to the risk of race conditions. They also (correctly) predicted a lot of the speculative CPU attacks by not supporting it by default.
They've done a lot of security research and pioneered a lot of open source work around OS-level stack smashing technologies, like memory executable-space protection (W^X), early process privilege separation, memory space randomization, etc. Some of these features are not great for performance, but do help and have been adopted by other systems.
You're basically arguing that an armoured car sucks because a Ferrari can smoke it on a race track. There are times you want a Ferrari and there are times you want a Brinks truck.
Even very smart, very accomplished people can be very wrong. Xen is seeing a resurgence from Xen Orchestra and I've used it in my homelab. It's quite pleasant. I also, of course, use de Raadt's software as well.
I think that everyone has the power to be wrong, but to be very wrong with convincing arguments, you must be smart.
A smart person can come up with post-hoc rationalizations that hold up under some scrutiny, to the point it is very hard to convince them otherwise. Add to that people who became famous or successful on the back of "being right" on some subject matter, getting used to "being right even in the face of overwhelming push back", and you have a recipe for very smart people being very wrong in very visible/loud ways.
One of his dumber takes. Virtualization replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel" (KVM and the userland hypervisor). It's a drastic attack surface reduction, and the empirical data bears that out: kernel LPEs aren't even newsworthy (there's whole repos full of unnamed, unremarked-upon LPEs), and KVM escapes are very rare.
Virtualization is responsible for effectively none of those security benefits.
It is the reduction to a smaller “kernel” that is responsible. If you applied the same design and operational model to running regular old processes instead of virtual machines you would also get a system with less security holes than the grossly insecure rat’s nest that is Linux, Windows, or whatever other commercial IT OS you have in mind.
Virtualization is almost entirely orthogonal, if not harmful, to security of the platform and operations. It is not magic pixie dust that makes your operational model more robust. You need a robust operational model, then you can have a robust operational model with virtual machines.
There is a reason why the most secure systems in the world are separation kernel architectures instead of hypervisors even though most of those systems do support virtualization as a feature, just not as the basis of their security propertys.
While this is true, the unspoken factor here is compatibility. Fixing the design and operational model of Linux (or any Unix derivative) to a sensible default-nothing architecture requires completely changing the semantics of the OS, which would break so much existing software to the point that one might as well write a new kernel+userspace from scratch. It's a lot easier for a sysadmin to just plop their existing rat's nest in a hardware-accelerated parallel universe and say "job done".
Sure, this is why virtualization is a valuable feature, it is just not the basis of security/isolation.
One of the points I am making is that when deploying on a modern multi-tenant VM-based platform, VM orchestration is analogous to process orchestration. However, you orchestrate the units, VMs, in a very different way to how you would orchestrate processes on say Linux. If your platform orchestrates, configures, and operates processes the same way a VM-based platform orchestrates, configures, and operates VMs and your implementation is solid then you would see similar security benefits. Virtualization is not the key. It just kind of looks that way because virtualization is usually paired with a fundamental re-architecture.
In greenfield application development or cases where you would do single-application VMs, you would target processes/platform directly. Only in situations where you are literally lifting code from a different OS environment that you can not or will not port to the native model would you need to go through a VM. If you orchestrate them the same way and your operational models for them are similar, then you will usually see similar outcomes. This is how it works in high security microkernels/separation kernels which simultaneously allow native processes alongside VMs. Virtualization is a feature to allow non-porting, it is not security/isolation; that is already provided underneath.
You can falsify these claims simply by looking at the records of platform vulnerabilities. I don't think this is a live argument.
Great, then falsify it. Point at a system with the same operational model as KVM-based multi-tenant systems with large numbers of platform vulnerabilitys.
Let us review a standard operational model:
Virtual machines are usually pre-allocated their total RAM. Virtual machines are usually pre-allocated a number of cores and pinned to them. Virtual machines are usually only allocated a small number of devices such as a virtual block storage device and virtual network device upon which they implement a in-VM filesystem and network stack. Virtual machines usually have no access to shared services provided by the hypervisor.
So we have a operational model where you have to pre-allocate RAM to a process. You have to pre-allocate a whole core and pin the process to it. The process has no access to a global filesystem, network stack, or devices. The process has access to exactly one file, which is logically similar to a virtual block storage device, and a single raw network socket, which is logically similar to a virtual network device. The process has no ability to form a socket to another process, form a new file, or even have any way of interacting with other processes at all. The process has no access to shared services of any kind.
The chasm between that operational model and any commercial IT operating system is immense, being basically the polar opposite in every dimension in the direction of security. Default-deny instead of default-allow. Shared-nothing instead of shared-everything. What you have there is a system even more static and simple than what runs on most microkernels. That is the comparable class of platforms with a similar operational model.
To demonstrate that virtualization is the key factor, you need to demonstrate that actually comparable systems with similar operational models like microkernels have more platform vulnerabilitys than comparable KVM-based, or even just hypervisor-based, systems. Which, again, flies against the face of evidence as the systems that are actually used in high security applications designed to protect against state actors are separation kernels instead of hypervisors.
These are a lot of words that I think are trying to work around the fact that LPEs are commonplace and KVM escapes are very rare.
Cool, show me a LPE in a seL4 deployment. Do you believe that is easier or harder than finding a KVM escape?
Since you are varying the security basis, implementation, and operational model simultaneously when you are comparing KVM to Linux to argue that the security basis is the important factor, I get to as well. Except mine is actually more fair because the design of a seL4-based system is actually much more similar to the design of a multi-tenant KVM-based system than the design of the KVM-based system is to the design of a Linux user environment.
Amusingly, this is the 2nd time you've tried to argue with me about this Theo post. Last time, you yourself brought it up as a model of a good security argument.
https://news.ycombinator.com/item?id=41071954
Rather than replicating my response then, I'll just incorporate that link into my point.
I ported L4 to my ARM NUC a couple weeks ago. L4 is great. Of course, L4 is also principally a platform for virtualization, so it's a pretty odd bit of evidence to try to bring up. Where have you personally been using L4?
Yes, you do enjoy evading the argument. You continuously point at implementation and operational model differences as proof that virtualization is the key factor. Theo's argument is literally that virtualization versus non-virtualization is irrelevant compared to implementation and operational model deficiencys. If you make garbage implementations and operational models, then you get garbage virtualization. If you have a good implementation and operational model then you do not need virtualization for "security".
As independent evidence for this point, virtualization is not the basis of security/isolation in seL4. You have isolation without any virtual machines. Virtual machines are just a feature on top that can leverage the existing isolation functionality to also provide isolated virtual machines. Of course, a secure deployment then requires you to leverage this foundation with a good operational model and system design since you can always make a insecure system even atop a good foundation. This demonstrates that virtualization is not necessary for a secure base, nor sufficient to achieve highly secure systems.
Just to hammer in the point that you are heavily misinterpreting Theo's response, this is the full sentence at the start of the post that Theo was responding to:
"Virtualization seems to have a lot of security benefits. Rootkits can lie to DomU but not Dom0, and of course snapshotting, migration etc is really nice."
Wow, amazing, rootkits can never be in Dom0 because Xen has "virtualization" magic pixie dust. Theo is pointing out how this is nonsense and virtualization will only provide security if you can create implementations without glaring security holes. Furthermore, you should not just listen to the people who brought you insecure system 1 when they tell you that this time for sure they are going to give you secure system 2; maybe have just a little bit of cynicism and ask for some evidence first.
You keep mentioning seL4. I'm curious what work you've done with it. (I've done a bunch of L4 work.)
Doesn't that message date back to a time that either predates or is almost concurrent with the introduction of x86 hardware-assisted virtualization? I wasn't around playing with VMs back then, but I'm not sure that the track record of x86 virtualization 20 years ago was that great.
It does, but that's an argument about implementations, and his comment is an argument about design. Just read it again and see if you think it's reasonable. Pay attention to the tone and (especially) the conclusory certainty he deploys.
And since then, OpenBSD has developed its own VM subsystem vmm(4), vmd(8), vmctl(8).
Sure, I mean, he was wrong, and I assume he knows he's wrong, and wouldn't say the same thing today. He's not dumb. Just this take is.
I’ll take someone who’s dumb over someone who is smart but rudely and confidently incorrect any day. Modesty, thoughtfulness, and kindness are too-undervalued virtues in our business.
I agree with everybody else who's wondered why this got posted today.
I too wonder why as it’s not news.
That said, I don’t know whether Theo has since “eaten crow” or has otherwise personally evolved.
The email in question actually addresses one of the first, if not the first, x86 hypervisor product, Xen, relying on both my memory of the time (I did some work with Xen in the mid aughts) and Wikipedia: <https://en.wikipedia.org/wiki/Timeline_of_virtualization_tec...>.
The Xen hypervisor itself was pretty minimal, as I understand mostly serving to time-slice CPU cycles among guest domains and partition memory access. As a contrast to VMWare, device access and drivers were handled by the guests themselves.
As such, the attack surface of the Xen hypervisor itself is fairly minimal. Most security issues seem to be denial of service vulnerabilities, though there are some privilege escalation, access, information leak, and overflow issues listed:
<https://xenbits.xen.org/xsa/>
I generally respect de Raadt's expertise and instincts, though he may have been over his skis here.
The letter is dated 2007-10.
AMD released (ie commercially available) Pacifica on May 23, 2006 while Intel did released their Vanderpool a half of year earlier November 14, 2005. [0]
Windows Server 2008 was RTM'ed on February 2008 which provided Hyper-V as a first class component. [1]
Virtual Server 2005 R2 SP1 added support for both Intel VT (IVT) and AMD Virtualization (AMD-V) and was released 11 June 2007. [2]
https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtual...
https://en.wikipedia.org/wiki/Windows_Server_2008
https://en.wikipedia.org/wiki/Microsoft_Virtual_Server#Versi...
> replaces an ultra-functional general-purpose kernel evolved over decades to support every conceivable application with a drastically smaller "kernel"
Is a Proxmox kernel that much smaller than a typical Linux kernel?
Isn't Proxmox a management layover over Debian and KVM? I doubt the kernel is even smaller.
I don't know. I don't use Proxmox.
If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well.
I'm not sure what the purpose of revisiting this is beyond provoking a flamewar on a slow Sunday.
I mean, I agree there. We all have dumb takes! I hear roughly once a month about my old "I don't think Dual EC is a backdoor, it's too dumb and obvious for anyone to actually use it" take.
Probably people are responding less to the dumbness of the take and more the arrogance of the tone combined with the dumbness of the take. Everyone has dumb takes, not everyone is an asshole while giving their dumb takes.
Regardless i do agree with you though, not sure what the point of digging up ancient skeletons is.
> If someone purposely dug up emails you wrote 19 years ago, I'm sure they'd find some of your "dumber takes" as well.
"Give me six lines written by the hand of the most honest man, I will find something in them which will hang him."
* https://en.wikipedia.org/wiki/Give_me_the_man_and_I_will_giv...
How big is the OpenBSD kernel and userland actually compared to a virtualization layer?
I'm anti virtualization, but mostly due to the internal complexities of the guest applications being swept under the rug, it's undeniable that the host is protected and thus neighbouring guests (of course it is with almost 20 years of hindsight I can say this.)
That the hypervisor is effectively an operating system/kernel I have always held, and that it is a smaller and thus less vulnerable kernel is an appropriate explication I think. It's very hard to secure an all purpose kernel like Linux without actually building it yourself (and even then..)
"Torvalds, via e-mail, says De Raadt is “difficult” and declined to comment further."
https://www.forbes.com/2005/06/16/linux-bsd-unix-cz_dl_0616t...
Imagine being so hard you're labelled as "difficult" by no other but Linus Torvalds
Thanks for sharing the forbes link. From the link:
"De Raadt says BSD could have become the world's most popular open source operating system, except that a lawsuit over BSD scared away developers, who went off to work on Linux and stayed there even after BSD was deemed legal."
There is some truth to that. And who knows where BSDs might have been if the lawsuit never happened.
However, I think Linux has always has and till today has better leadership, and management compared to OpenBSD.
I also think GPLv2 was another good that happened to Linux. It just creates an irresistible force to contribute back. With *BSD, a company might contribute back or it may not.
Ha! That’s some rose-colored-glasses view of BSD history.
The lawsuit didn’t help. But the BSD developers shot themselves in the foot when they refused to support x86, referring to it as a “toy”.
It wasn't until Linux came along and started eating up all of BSD's user base that they freaked out and decided x86 support might be a good idea. But by then it was too late.
I don't recall them refusing to support x86, but BSD development was mostly done by academics rewriting and improving AT&T UNIX, which was mostly on big iron systems of the time. They were focused on academic computer science work. The lawsuits stopped a lot of BSD work as the universities were sorting it all out. William and Lynne Jolitz start porting 4.3BSD to the Intel 80386 at Berkeley in 1989 (but the code wasn't released for years due to said lawsuit) before Linux existed. That is the first BSD-on-x86 work; by December 1990 they had contributed a working port to UCB. Most of the code didn't see the light of day until ~1992.
Also, usable and production ready BSDs were running large websites on x86 long before linux became mainstream and well-supported enough to be used. The BSD TCP/IP stack was the reference implementation for ages and BSD was heavily used in the internet's early days as a lot of early companies spun out of Californian universities. Hotmail ran on FreeBSD. Early SunOS variants were based off of BSD, as were some other commercial unixes.
The bigger killer, I think, is that BSD was (and still has) a bit of closed mindset to newcomers and were and are more conservative to new technology, despite some foundations of techbeing started with them. Docker's origins can be directly traced to FreeBSD jails. Sometimes the conservatism is warranted and a benefit (eg OpenSSH).
I go back to take a look at the BSDs every now and then and frankly it really looks like that mindset has stayed, somehow.
Generally speaking the BSDs seems really fork-a-phobic and it kinda shows given how little dynamism is there in the development those systems.
Even the Solaris derivatives have a faster tempo.
GhostBSD DragonflyBSD pf/opn sense even funky hybrid stuff like Chimera Linux, out of curiosity I had a quick search and the list goes on https://github.com/DiscoverBSD/awesome-bsd
Linux has a lot of corporate sponsorship and its own legal hurdles of the past (SCO le sigh.)
> But the BSD developers shot themselves in the foot when they refused to support x86, referring to it as a “toy”.
When was that? Presumably wwaaaaaaaay before 386BSD was a thing right?
386BSD came out about the right time, but as noted, development was slow, and the original author abandoned it pretty quickly while at the same time Linux was actively gaining traction and growing rapidly.
Quotes below:
[1] https://www.doc-reform.org/spine/en/html/free_for_all.peter_...[2] https://www.sisudoc.org/spine/en/html/free_for_all.peter_way...
I never believe people when they say, we would have been famous if not for one piece of bad luck 35 years ago.
Yeah, i'm sure the lawsuit was crappy and set things back. But if you can't recover after 35 years, then its something deeper than what happened 35 years ago.
It's hard to blame OpenBSD's management when there are three other BSDs. You didn't have to work with Theo de Raadt to work on BSD. But while the lawsuit may have been the catalyst, the game was really over when GNOME took off. BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans. At that point pretty much everyone making interesting desktop stuff went to Linux and never looked back. Which is not solely a license issue; you can definitely release GPL software for FreeBSD, but the "license war" culture (to the extent it really existed) may have been an issue.
And I guess I do think that FreeBSD had a saner organization pattern than the sort of haphazard ecosystem of projects that grew up around GNU and Linux. Maybe the chaos was necessary for growth, but it still seems to be a hurdle for new Linux users in the current day.
i think what the chaos did was enable more individual contributors. you didn't have to join the BSD team to get a core OS tool accepted into the system. anyone could just mix and match the tools and apps they liked. it's not that BSD prevented that but that they just didn't invite it. you can create your own spin of a distribution and if it gets enough users and contributors it gets accepted as an official version. there is even a debian variant using a BSD kernel. try making a official BSD spin using GNU coreutils.
> there is even a debian variant using a BSD kernel.
it's dead as of july 2023: https://www.debian.org/ports/kfreebsd-gnu/ :
> The development of Debian GNU/kFreeBSD has officially terminated as of July 2023 due to the lack of interest and volunteers. You may find the official announcement here[1]
here[1]: https://lists.debian.org/debian-devel/2023/07/msg00176.html
GNOME prioritises Linux now but it shipped with Solaris from 2003 onwards and Sun contributed accessibility features around that time.
> BSD was sort of an equal target under KDE, but GNOME prioritized Linux pretty hard and had a lot of fans.
oh boy its' much worse than that: KDE/GNOME were already largely precarious before that.
The whole Xorg thing was really dependant on gpu drivers and the story between linux gpu drivers and *bsd gpu drivers was so much different. Having the BSDs be fairly different didn't really help (eg: only FreeBSD had official nvidia drivers, albeit proprietary).
Gnome did take a lot of backlash and Gnome essentially became a meme at some point ("what's the use case for that?")
Gnome did take a strong dependency on systemd (both gnome and systemd are developed by Red Hat, btw).
And Gnome also did push a lot for wayland (that wasn't implemented on the various BSDs for a long time).
I haven't checked in a while, but I think Gnome is wayland-only nowadays ?
Ultimately, the real issue with KDE/GNOME and the BSDs is that the BSDs are largely irrelevant and essentially only relevant for some specific use-cases where desktop usage is not involved.
I mean, Torvalds has called basically every person on earth an asshole at some point, hasn’t he? He’s the opposite of being sparing with critisicism, and frankly has historically often used his bully pulpit to do it.
My read on Torvalds is that, coming from him, "asshole" is a much lesser criticism than "difficult".
[flagged]
There are many extremely competent engineers who can’t deal with the idea of exposing themselves to public humiliation. That’s especially true in today’s environment where these kind of bully rants have become a spectacle for outsiders. Just google the name of the person who was the subject to one of Linus’ rants about a year ago. Despite being a very accomplished figure in the RISC-V world, top results for his name are links to Linus calling him an idiot. That’s a mark he will have for life. I would die of embarrassment.
It’s perfectly possible to critique without being a bully.
What Theo and Linus are doing wrong is scaring away a large pool of potential contributors who don’t want to take that risk.
[dead]
> It’s perfectly possible to critique without being a bully.
Yep. And it's perfectly possible to accept being called stupid, if you truly did do something boneheaded. It's not a permanent scar that ruins the rest of your life, as you seem to believe.
> What Theo and Linus are doing wrong is scaring away a large pool of potential contributors who don’t want to take that risk.
Good riddance.
Personally I believe being an asshole to people is doing something wrong.
[flagged]
> I don't classify thin skinned snowflakes who do stupid things that get them screamed at by Linus, and then are butthurt about it for years, as being "extremely competent."
There is no reason to believe that there is a causation between being a “thin skinned snowflake” and being incompetent. That said, it doesn’t surprise me at all that some kind of people would make that assumption.
> A simple tool was presented, iofuzz, that exposes exploitable security flaws in most, if not all, virtual machines available today. To the knowledge of the author, no similar research has been conducted before. The results produced by crashme, a tool well known for over a decade, locating trivial flaws dem- onstrates this. No virtual machine tested was robust enough to withstand the testing procedure used, and multiple exploitable flaws were presented that could allow an attacker restricted to a vir- tualised environment to reliably escape onto the host system. The results obtained demonstrate the need for further research into virtualisation security and prove that virtualisa- tion is no security panacea.
https://taviso.decsystem.org/virtsec.pdf
He’s not wrong based on the research at the time. The mistake is presenting this as if it’s something that will be true for all time. Is virtualization a panacea? No. CPU manufacturers can’t even protect against side channel attacks. But it’s completely missing what this provides which is that the difficulty and cost of creating an exploit is higher today than 20 years ago. And it’s amusing to hear someone blasting away at the security of others when BSD has its own share of problems and architectural weaknesses are discovered through popularity of your system being an attack target, not because you’re smarter than everyone else and made better choices (sometimes it can be true in places, but harder to maintain for a big piece of software like an OS)
I don't understand the constant (almost always unsubstantiated) criticism of the *BSDs from many Linux advocates.
Personally I evaluate each OS by it's merit, and I've concluded that OpenBSD, FreeBSD and some Linux distributions(I use arch btw) are solid operating systems.
On the server I prefer FreeBSD because of it's amazing flexibility, and stable yet evolutionary base system and in my opinion, superior init system. Simple RC scripts FTW.
I use Arch Linux for superior software and hardware support, related to client usage.
I use OpenBSD for various network appliances.
If you like Arch and init systems with simple RC scripts, check out Artix Linux (https://artixlinux.org/), which is an Arch-based Linux distribution that supports multiple options for init systems.
I would love to know how OP came across this email nearly 20 years after the fact
It's one of Theo's more famous dismissals/takedowns.
Some people keep classic flames alive to deploy in times of need. Theo's good, but he can't hold a candle to the late Marc Cripsin railing about emacs line-mode-visual. Grr.
https://www.reddit.com/r/emacs/comments/1tf1iy/imap_inventor...
>From: Mark Crispin, To: comp.lang.emacs
>What mindless cretin thought that it should be a good idea to make line-move-visual be the default in emacs 23? I just found out about this charming "improvement" in the worst possible way. Investigation determined that a "routine" software update had just installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software. This is an example why. Emacs' line behavior has well over 30 years of history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults alone.
>If you want to have your own playpen where you twiddle defaults to your hearts content, have at it. But don't pretend that you produce software for a production environment, and stop telling the Linux distributions that they should "upgrade" to your "improved" versions. People doing real work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users don't get the release notes and don't even know that a new release happened. It is also unreasonable to expect users to subscribe to every obscure newsgroup, forum, and wiki to hear about changes that will turn their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all the .emacs files on all the dozens of other machines I use, even though they still have emacs 22, because otherwise this unpleasant surprise will repeat itself over and over again.
>Grr.
>From: Mark Crispin, To: comp.lang.emacs
>They made the wrong decision. Changes to default behavior are a bad idea. Changes to default behavior of the most basic functionality are an extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from skunk to lemon. But I damn well do care about the most basic operations: all CTRL single letter and ESC single letter. After 33+ years of using emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file, or my terminal emulator window, or my system. The fact that the problem went away on a different system added further confusion. It was only when I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines, but only on one system, that I realized that emacs changed. And that's when I did ESC X describe-key CTRL/N and read about line-mode-visual, although it did not mention that this was now the default.
>Surprise. Grr.
i don't know that crispin rant sounds pretty reasonable to me. it's not insulting and the argument is coherent. he has a point.
Theo's rant about what a hypocritical idiot ESR is also sounds pretty reasonable to me: he has a good point.
https://news.ycombinator.com/item?id=48883342
ESR's free to make ridiculous laws about eyeballs that aren't true and nobody follows while never actually reviewing any code himself (except for the climate scientists' code which he totally misunderstood and dishonestly misrepresented), but blaming it on Linus was a dick mode.
https://rationalwiki.org/wiki/Eric_S._Raymond#Climategate
>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
porridgeraisin: Speaking of ICCCM (aka I39L) and X11 selections, have you seen David Rosenthal's glorious rant about the Sun Desktop that somebody leaked to the unix-haters mailing list (who, moi?), which comes straight from the author of the ICCCM and co-developer of Andrew, X10, X11, and NeWS. The Roy Lichtenstein line is classic. What he's touching on by "Why can't they just shut up and do their job efficiently and inconspicuously?" is Mark Weiser's "Ubiquitous/Calm Computing". He's married to Mark's widow Victoria Reich, and they both work on LOCKSS ("Lots of Copies Keep Stuff Safe").
https://en.wikipedia.org/wiki/David_S._H._Rosenthal
https://en.wikipedia.org/wiki/LOCKSS
https://news.ycombinator.com/item?id=44045304
Check out his blog, recently he's been writing about his introduction to computer graphics, hacking late at night in the basement of the lab on the PDP-7 connected to the Titan at Cambridge University, and how Coprophagia Is Bad For You! He was employee #4 at NVIDIA.https://blog.dshr.org/
>We managed to get the game to be sort-of playable provided you let the machine win.
Another classic. About the X11 selection mechanism
https://github.com/porridgewithraisins/x11cp/blob/main/rant
If OpenBSD pretended Qubes OS was a feature prototype/reference OS build and made a fork of OpenBSD to feature-match Qubes OS (calling it QuBSD or something), that would be great!
I wished more people would take issue with developers' bad attitudes.
I know this is an extremely unpopular take, but I refuse to use software where the main dev(s) are openly abusive to others. Sadly this includes the majority of open source operating systems and many other very popular applications... but it's my decision and you're welcome to disagree with me. I am not trying to prevent others from using said software, and I don't look down on them for it.
I think if everyone was always forced to separate the art from the artist, then boycotting wouldn't even be a thing, so there should probably be some kind of middle ground.
There was no abuse and bad attitude. He was telling the truth about Linux hypervisors. And it got worse since then. Then they talked Xen, which at least has a security boundary. Now everybody switched to kvm with none. Only speed matters, security not at all.
Disagree, but regardless, both Theo and Linus have long, storied histories of prolonged habitual abuse without much remorse. Even after Linus "stepped back", it never really stopped after he came back.
We'll probably also disagree on what is abuse or not, but that's ok.
> You are absolutely deluded, if not stupid
.. is abusive.
My favorite Theologism:
https://en.wikipedia.org/wiki/Linus%27s_lawDude is 100% right
I don't know who this guy is but this is just a shitty way to interact with people. Presumably he's successful or we wouldn't be talking about him without any introduction, but I wouldn't hire this person to sweep the floors at my office.
That is old news, Theo was harsh, arrogant and rude. He was not always right, but always RIGHT!!
But ten years ago. What is the point now?
Don't take this personally, but I am sorry to have to inform you that it was, in fact, almost 20 years ago. Just months after Rihanna released Umbrella, and a year after Mika released Relax.
I hate to break it to you, but 2007 is rather closer to twenty years ago.
I think de Raadt and OpenBSD are hugely overrated and some takes are as dumb as the one in the post.
OpenBSD is only secure because because it does pretty much nothing and does it very slowly (its firewall just recently broke the 4gbps firewalling capabilty, for example) but somehow a cult has formed around it ¯\_(ツ)_/¯
Counter-take:
Linux is only secure because of OpenSSH.
In all seriousness, the OpenBSD guys are very conservative with technology. The OpenBSD pf stack (as well as much of the kernel) isn't heavily threaded due to the risk of race conditions. They also (correctly) predicted a lot of the speculative CPU attacks by not supporting it by default.
They've done a lot of security research and pioneered a lot of open source work around OS-level stack smashing technologies, like memory executable-space protection (W^X), early process privilege separation, memory space randomization, etc. Some of these features are not great for performance, but do help and have been adopted by other systems.
You're basically arguing that an armoured car sucks because a Ferrari can smoke it on a race track. There are times you want a Ferrari and there are times you want a Brinks truck.
In fairness, minimizing surface area (doing nothing unless you need to) is security 101, so i hardly think that is a criticism.
Yeah it’s one way to look at it for sure…
god bless usenet. The good ol' flame wars aren't what they are used to anymore with all this moderation and trolling feeding each other around here.
This is not usenet, it's the openbsd misc@ mailing list.
Even very smart, very accomplished people can be very wrong. Xen is seeing a resurgence from Xen Orchestra and I've used it in my homelab. It's quite pleasant. I also, of course, use de Raadt's software as well.
I think that everyone has the power to be wrong, but to be very wrong with convincing arguments, you must be smart.
A smart person can come up with post-hoc rationalizations that hold up under some scrutiny, to the point it is very hard to convince them otherwise. Add to that people who became famous or successful on the back of "being right" on some subject matter, getting used to "being right even in the face of overwhelming push back", and you have a recipe for very smart people being very wrong in very visible/loud ways.