That kernel-mode code can blue-screen Windows is true, but it doesn't follow that therefore, it is in the interest of the user to prevent the user from running kernel-mode code that does not cause Windows to blue-screen, which is what you are proposing. You constantly avoid justitfying the thing that you actually are proposing.
It's about risk. Code running in kernel mode can tramp over memory in use by other applications. This is a bad thing. User mode code cannot. This is a good thing. Microsoft is responsible for providing an OS that is secure and reliable, and preventing applications from running in kernel mode reduces the risk of inept or hostile code trampling over memory allocated to other applications. It also reduces the ability of an application to crash the OS itself - this, too, is a good thing.
If you don’t think this is a good thing, ask yourself why all the big OSs work in this way: the OS runs (largely) in kernel mode, the applications run in user mode. Windows, Linux, MacOS all work like this. I'm not as familiar with Linux as you are, but I don't think Linux apps routinely run in kernel mode.
What you are saying here is mostly correct.
But in so far as it is correct, it is completely besides the point.
Now, for one, no, "apps" on Linux don't "routinely run in kernel mode". But that's pretty much a vacuous statement, given that the definition of "application" is essentially "code running in userspace", so code running in kernel space would, by definition, not be an application.
However, I would agree than OS "vendors" are responsible for providing an OS that is secure and reliable.
In the case of Linux, the kernel developers do that in the form that they provide a ton of features that allow me, the owner and admin of the machine, and the software that I, the owner and admin install on it, to restrict the privileges of code running on the system, and to limit the impact of bugs in code running on the system, from virtual memory process isolation to user account isolation to seccomp and namespaces/containers, mandatory access control hooks, packet filters, what have you. Microsoft at least to some degree does the same on Windows. All of that is a good thing, no disagreement on that from me.
Now, you are further suggesting that the kernel developers should prevent me, the owner and admin, from changing the kernel code. What you have failed to provide so far is a justification for why that would be a good idea/why that would be in my interest.
The fact that running code in kernel space is risky is irrelevant for that. That's a justification for why I, the owner/admin should maybe generally avoid unnecessarily running code in kernel space, which is something that I do absolutely agree with. What needs justification is that the kernel developers (or Microsoft) should prevent me, the owner/admin, from running code in kernel space. And that justification needs to consider that (a) I, as the owner/admin already do have the option to not run code in kernel space unnecessarily in order to avoid that risk, so it doesn't need the kernel developers(/Microsoft) forcing me to not do that in order for me to be able to avoid that risk, (b) that there might be good reasons to run code in kernel space that are worth the risk and where I as a competent owner/admin am willing to take those risks for the advantage that it gives me, in which case it is obviously not in my interest that the kernel developers prevent me from doing the thing that would be to my advantage, and (c) that one reason in particular for why I might want to add kernel code could be that I want to add features that allow me to further restrict privileges of code running in userspace, in order to improve the security of the system, in the sense that I can prevent leaking or corruption of valuable data in ways that existing kernel features don't allow.
Also, just pointing out that in the case of Crowdstrike, the damage might have been prevented if Microsoft had prevented Crowdstrike users from installing the Crowdstrike kernel driver, is insufficient to justify such a restriction, because it neither addresses all the other effects of such a restriction (i.e. potential benefits that would be erased by such a restriction, see above) nor does it even establish that things would actually have been better for Crowdstrike users because you would also have to substantiate that the hypothetical kernel driver provided by Microsoft ("the API") instead of Crowdstrike's driver would not have suffered a similar or worse failure mode, which you haven't done. And all of this in particular, given that people who do use Windows already did have the option to not install Crowdstrike and thus also to not install the Crowdstrike kernel driver in order to avoid the damage that they suffered, so the restriction that you are suggesting is not actually necessary to that end.
Re. your last sentence, I think I have done nothing but justify why apps are best kept away from kernel mode.
Yes, you have. And that is the problem that I have been pointing out over and over, with you just ignoring it.
You are suggesting that Microsoft should prevent owners/admins from installing (certain) kernel mode drivers on their own systems.
But the justification you give is, at best, for why owners/admins should not (unnecessarily) install kernel mode drivers on their own systems.
That part I don't even necessarily disagree on.
The part that I disagree on is that Microsoft should prevent owners/admins from installing kernel mode drivers. And that is the part that you keep dodging. You keep explaining why people should avoid installing kernel mode drivers, but not why Microsoft should prevent people from installing kernel mode drivers.
The fact that it is risky is not sufficient reason why people should be prevented from taking the risk, if they think that that risk is worth it. But you are saying that it shouldn't matter what the owner/admin of a system thinks, and that Microsoft should decide for them that they are not allowed to take risks. That is the part that you need to justify.
All of this in particular given that the choices aren't actually what you present them to be. The option to "keep the app away from kernel mode" doesn't exist, except in so far as you can just not install "the app" (i.e. Crowdstrike or similar products) at all. Or rather, strictly speaking, there is no app in kernel mode at all, because the component of Crowdstrike that runs in kernel mode, by definition, is not part of the application, but part of the kernel. And there is no way to avoid that some portion of a system like Crowdstrike is implemented as a kernel driver, so it isn't actually an option to have "no kernel driver". The actual choice, besides not installing such software at all, is to either have a kernel driver from Crowdstrike, or a kernel driver from Microsoft. Therefore, no matter which option you choose, you do have code running in kernel mode, with the risks that are associated with running code in kernel mode. The only question is who that code is written by. And you are saying that Microsoft should be allowed to force its customers to only use a driver written by Microsoft. Again, that is the part that you haven't justified. The fact that you would prefer to use a driver from Microsoft is irrelevant. Other people being able to use drivers from other vendors does not in any way prevent you from using a driver from Microsoft, so it is not necessary to prevent other people from using drivers from other vendors in order to enable you to use a driver from Microsoft. If everyone wants to use a Microsoft driver, that is also possible without Microsoft preventing the use of other drivers. And iff there is anyone who wants to use a driver from a different vendor, then it is obviously not in their interest to force them to use a different driver than the one that they want to use.
So, only Microsoft should be allowed to provide application software for Windows?
Eh? I said only Microsoft should be allowed to provide OS services and APIs. The application software - running in user mode - is open to any provider.
Yeah, I know. But I asked you to justify this position. And the reasons that you gave as justification are not specific to "OS services and APIs", but rather would apply equally to application software.
I asked you to justify why the owner/admin of a machine should be prevented from running code of their choice in kernel mode, but should not be prevented from running code of their choice in userspace.
You said that the reason is because running code of their choice in kernel mode would be a risk to their data.
Now, I will ignore the logical non-sequitur in this, and will just assume that this is in fact a valid reason to prevent them from running code of their choice in kernel mode.
The problem is that running code of your choice in userspace also is a risk to their data.
So, if "being able to run code of your choice is a risk to their data" is a valid justification for preventing people from running code of their choice, then that justification applies to userspace just as much as it does do kernel mode, so it isn't actually a justification for your position that owners/admins should be prevented from running code of their choice in kernel mode, but not in userspace. If you indeed think that this is a valid reason, then it would follow that they should also be prevented from running code of their choice in user space, and if you think that people should be allowed to run code of their choice in user space, then your justification doesn't hold, and you will have to find a different one.
On all of the operating systems that I use, no vendor "owns" any API. I have all the source code to all of it and am legally explicitly allowed to modify all of it. So, it is obviously explicitly intended that I can add, remove, or change kernel mode code how ever I like it, be it with my own code, or code from any third party. So it is just obvious nonsense that it is somehow the universal model that some "vendor" controls what code I run on my operating systems in kernel mode.
That's because you are running Linux! The license is completely different. You are free to do whatever you like to any part of it. This is not true for Windows and MacOS. You don't have any of the source code for those OSs, and their license does not allow you to modify their operating systems.
Well, yeah? But for one, that doesn't change that your statement that this was somehow a universal thing with operating systems was bullshit. It was bullshit precisely because operating systems like Linux, OpenBSD, FreeBSD, NetBSD, Illumos, and who knows what, do have licenses that follow a very different model to the one that you claimed was universal.
But also, and maybe more importantly, it is mostly besides the point. The license maybe doesn't allow you to modify those operating systems. But the law does, within certain limits, and the law trumps license agreements. And you are suggesting that the law should also not allow it, i.e., the law, or the authorities enforcing the law, should allow Microsoft to prevent their customers from doing things with Microsoft's operating system that Microsoft's customers are allowed to do by law. So, it is a completel non-sequitur to say what amounts to "but it isn't legal for people to do these things with Windows" (i.e., "they 'own' the OS") as justification for why the law should be changed such that it would become illegal for people to do these things where they currently are legal. In this case, anti-trust law trumps copyright. You are just pointing to copyright law to support your position that anti-trust law should not apply ... that's just logical nonsense.
If you blame the manufacturer for not preventing their customer from doing whatever their customer wants to do, that simply is an expression of your authoritarianism, not some universally agreed view.
As I said, Windows does NOT let applications do "whatever their customers want to do". If you don't think that is fair or acceptable, then use a different OS (but not MacOS, because that doesn't, either). I can't comment on whether that counts as authoritarian or not, but it certainly isn't my authoritarianism.
That's just missing the point, though? Customers
are doing a thing that they want to do, i.e., they are installing Crowdstrike kernel drivers. And they are in fact allowed to do that, because the law, as enforced by competition authorities, says that they are allowed to do it. And you somehow conclude that it is therefore appropriate to blame Microsoft for the consequences of what their customers have done, because you think that Microsoft should prevent their customers from doing the thing that those customers are doing voluntarily, and them failing to do so somehow makes them responsible for those voluntary actions of their customers.
That is just plain authoritarianism: You want the strong man (Microsoft) to override the whishes of other people and you want to blame the strong man for not overriding the choices of those other people when those choices have negative consequences for those other people.
Now, the kernel API in particular is usually a privilege boundary. But it generally is not a privilege boundary between the owner of the machine and the kernel. It is a privilege boundary between users. The point is to isolate processes that run under different user ids, so that a process running under one user can not randomly read or modify data of some other user.
It IS a privilege boundary between the applications and the kernel (the owner only owns the hardware, remember).
No, I don't remember, because I never thought that in the first place, because it is nonsense, as I have explained at length.
When that boundary is breached, disasters like CrowdStrike become more likely.
Which isn't solved by forcing people to use kernel mode code from only one vendor. The kernel mode code runs in kernel mode in any case.
CrowdStrike was not trying to stomp over processes running under different user IDs. It tried to access memory (apparently off a null pointer) that was not allocated to it.
Your point being?
Protecting "the OS" is not something that has any inherent value, because "the OS" is not something the user cares about on its own. Protecting "the OS" only makes sense as a means to an end, i.e., of protecting user data against abuse or corruption. Preventing the user to do with their data what they want to do with their data is not something that helps with that.
You say the user doesn't care about the OS on its own. Probably true, but only because most users only have a vague understanding of how their PC works. The reason why the OS should protect itself from damage is because, whether they know it or not, the integrity of the OS is crucial to protecting the user's data and letting them get on with their work.
No, by "they don't care" I don't mean that they aren't hinking about it, or that they don't understand it, I mean that it makes no difference to them, i.e. that they still wouldn't care if you explained it to them sufficiently for them to understand the implications.
Also, your claim that the integrity of the OS is crucial to protecting the user's data is not really universally true. That very much depends on the usage scenario. The integrity of the OS is only crucial in so far as it does in fact prevent unauthorized access to relevant data. It isn't all that unusual to have servers, for example, where all the userspace software is running in one user account, with all of it having read and write access to all of the business critical data on the system. On such a system, the integrity of the OS often is almost completely irrelevant as far as the interests of the owner of the system is concerned, because every vulnerability in the system gives an attacker access to all the critical data anyway. If an attacker that compromises some service that is running in that one user account can access all of the critical data anyway (so they can exfiltrate or destroy it), it makes no material difference to the owner of that system whether the attacker can also compromise the kernel, because there is no damage that that allows the attacker to do that the attacker couldn't do without compromising the kernel.
And all of this is relevant here because, as I have already explained before, the nature of "security" solutions like Crowdstrike is that they do have access to anything of value by design. Even if that access were to be mediated by a kernel driver written by Microsoft ("the API") and even if we assume that that kernel driver would be free of bugs, Crowdstrike would still be able to see all of the data that's valuable to the user/the business, would still be able to make the system unusable, would still probably be able to corrupt data. As such, bugs or vulnerabilities in such software could still completely wreck anything that is valuable to the business using it. Which is why I said that protecting "the OS" in itself is not something that the user cares about. What the user cares about is their data. The integrity of "the OS" can be crucial to protect their data. But just protecting "the OS" is useless.
And also, you are still confusing reliability features with anti-user enforcement. I can add any kernel mode code I want to my Linux kernel, for example. That doesn't mean that root processes don't segfault when they access an unmapped page or whatever. It isn't required for Linux to be able to have these features that I am prevented from changing the kernel code.
Reliability and user access enforcement are both important and enhanced by keeping apps away from kernel mode as far as possible.
Generally, yes. But that is irrelevant for justifying your position that only Microsoft should be allowed to provide the kernel component of a system like Crowdstrike. What follows from this is that owners/admins and the vendors who produce the software that those owners/admins install on their systems should keep as much of the code that is necessary to implement the functionality of such a system in user space. It says nothing about whether Microsoft should (be allowed to) prevent their customers from using an implementation of the kernel component from a vendor other than Microsoft, which is what you are suggesting.
You certainly cannot add kernel mode code to the Windows kernel unless you jump through the hoops mentioned earlier.
Well, that is true. But for one, that does not justify that this is a good thing. And even less that Microsoft is allowed or should be allowed to arbitrarily reject kernel drivers. And my understanding of those hoops is that their only goal is to find and fix obvious show-stopper bugs before the code is deployed to tons of systems. It's not about security, nor about any particularly stringent reliability requirements, other than "doesn't just crash if you look at it wrong". The primary purpose, really, is to provide attribution, in that you as the user can be sure who the vendor of the driver is, so that you can avoid fake drivers.
And, I'm sure you will admit that your code - running in kernel mode - has the ability to wreak far more havoc than your code running in user mode.
Yeah, of course, obviously. But that never was the contention. The contention was that there is no good reason why the operating system vendor should force its customers to not run code of their choice in kernel mode. After all, there are good reasons to run code in kernel mode, or we wouldn't have any code running in kernel mode. And it should not be up to the operating system vendor to make that decision for their customer.
I think you are stuck in the Linux mindset, where everything is open and transparent. Windows isn't like that: Windows is a black box with published APIs. You can't mess with the OS because you can't get the source code.
No, i am not stuck in a Linux mindset, I am stuck in a liberal, democracy, open market competition, non-monopoly, mindset. And I think that that is a good thing. That Windows isn't like that might well be the case. But the discussion here is not about what Windows is like, but about what anti-trust law and enforcement is like or what it should be like. And in my view, if any product from any vendor is built in such a way that it prevents open market competition and creates monopolistic powers, then anti-trust law and its enforcement should stop that, because that sort of thin generally is to the detriment of the public at large. You are saying that Microsoft should have more monopoly power than they already have. And you are so far failing to justify why that would be a good idea.
I think the CrowdStrike disaster proves my point beyond doubt: an inept application was able to bluescreen Windows machines all over the world and caused absolute chaos to countless businesses because it was running in kernel mode. If it was running in user mode it couldn't have done that. That's why Microsoft is right in trying to reduce the amount of application code running in kernel mode.
No, it doesn't prove your point in any way, as that is just a serious of non-sequiturs. It doesn't follow that because Crowdstrike caused a ton of systems to bluescreen, therefore, Microsoft should be given the monopoly power to provide the only kernel driver for such applications. That is just pure logical nonsense. You have neither demonstrated that that would in fact solve the problem, nor that it would be the best solution to the problem, given that there are numerous other options to approach a solution to the problem, starting from the obvious option that customers could just voluntarily only use a kernel driver from Microsoft if they think that that would solve their problems.
You know, that sort of stuff is what I do for a living, and I can assure you that I understand how privilege boundaries on operating systems work. And I can also tell you that the way that you think about IT security is pretty confused.
Your ad hominem seems like a good place to stop. We've both got our heels dug in - I doubt there is any value in continuing. Also, we really should get back to talking about microcontrollers. Your professional experience with Linux surely means you can suggest some lessons that are relevant to microcontrollers.
It's weird that you write "I get the impression you aren't aware of the architecture of modern operating systems, and especially the concept of the API", but when I write the equivalent in the other direction, that's a problem, isn't it?
But also, neither of those are ad hominems. An ad hominem is a fallacy of the form "person X has character flaw Y, therefore, the claims that they make are false". That is obviously logical nonsense, as you just would have to find a person with a character flaw and have them say '1 + 1 does not equal 3' in order to prove that 1 + 1 equals 3, if that form of an argument were valid, which is why it is a fallacy. Neither "person X is not qualified on topic Y, therefore you shouldn't trust their claims on topic Y" nor the mere statement of "person X is not qualified on topic Y" are ad hominems, and they obviously are not fallacious.
And no, I don't have my heels dug in. I am just pointing out the logical flaws in your arguments, and asking you to make arguments that don't have logical reasoning errors, while you keep making the same errors over and over.
Home
Help
Search
Login
Register
