Is there something to learn for embedded/IOT from the Crowdstrike disaster? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: July 22, 2024, 11:42:10 am
content: Obviously nobody should deploy a "critical" system which is subject to 3rd party updates which have not been tested by the implementer on another (non critical) system.But obviously millions of IT guys didn't know thatAnd then we have the endless debates about "latest patches" on IOT products. Who wants to destroy their company? Micro$oft and Crowdstrike will survive this because they have contractually excluded all liability and anyway nobody is big enough to sue them.

author: jzx
author_rank: Regular Contributor
timestamp: July 22, 2024, 11:59:51 am
content: Learn to do backups

author: mikerj
author_rank: Super Contributor
timestamp: July 22, 2024, 12:17:23 pm
content: Quote from: jzx on July 22, 2024, 11:59:51 amRestoring "Backups" is not a very practical solution when hundreds or thousands of important systems have gone down due to an update and you need to get them running ASAP.

author: peter-h
author_rank: Super Contributor
timestamp: July 22, 2024, 12:26:04 pm
content: Someone will point out that Samsung, Apple, etc, regularly issue updates to their phones. So how do they manage the risk? Probably by- having a lot more testing resources than Crowdstrike- doing a rolling deployment, starting with some small country in AfricaIndeed; restoring backups is useless. Firstly, you will lose all new data, and secondly if the system has "done a BSOD" then it needs a site visit which is a disaster in most cases.

author: hans
author_rank: Super Contributor
timestamp: July 22, 2024, 12:47:14 pm
content: Don't update if you cannot handle any prolonged downtime. But also don't postpone updates forever. Vulnerabilities will be exploited, so schedule maintenance and downtime regularly.Having a "rolling release" update model has never worked for critical infrastructure. Just like "Continuous Delivery" is not a thing in the embedded world; if devices instantly get updated with the last Git commit you make to the production branch of your repository, as you can see, it has the potential to brick all your devices in the field. A webserver or computer OS can be rescued, but whatever embedded IoT gadget you in the field probably not without shipping it back and taking more costs than a 'throwaway' product would be worth.

author: mark03
author_rank: Frequent Contributor
timestamp: July 22, 2024, 06:16:01 pm
content: Informed users are learning software updates are frequently not in their best interest. Consider Windows for example. Setting it to "critical updates only" certainly does not screen out the non-security-critical bloat. There are similar examples in the embedded space, where a vendor decides to disable some popular feature against users' preferences. Examples in smartphone apps are legion (the BBC news app is a prominent example).So, this is slowly corroding users' trust in their SW suppliers, which---given the conflicting motives of user and vendor---is unavoidable, but obviously not good for security and reliability.The Crowdstrike incident is different, mostly. By definition, what they are trying to do requires frequent (daily?) updates, so the systemic blame (besides what has been mentioned above---which I agree with) needs to fall on the OS which requires mitigations like Crowdstrike to function safely.Despite this, to me it's another example of how a computing culture of "continuous updates == security == good" can come back to bite you. The benefits of software updates need to be balanced against the potential harms; this is rarely if ever discussed, probably because it tends to shine a light on user-hostile policies. Personally, I would avoid software updates on most of my embedded devices if I could, and I make embedded software for a living.

author: madires
author_rank: Super Contributor
timestamp: July 22, 2024, 06:48:38 pm
content: Some customers can blame themselves for not reading the terms & conditions. Crowdstrike explicitly warns to not use their products for critical systems.

author: agehall
author_rank: Frequent Contributor
timestamp: July 22, 2024, 07:02:15 pm
content: Yeah, don’t let all your nodes update automatically. Test any updates on a few nodes that you can live without if something bad happens and only roll out the update once the test nodes have proven they can survive a reboot.Everyone pushes a bad update once in a while. That isn’t the big f-up imho (but it was an f-up). Blindly trusting updates was the major f-up here.

author: wek
author_rank: Frequent Contributor
timestamp: July 22, 2024, 07:29:40 pm
content: Quote from: mark03 on July 22, 2024, 06:16:01 pmMaybe; but maybe it's just that people want things to be simple. "Discussing or estimating benefit/drawback balance == complicated == bad".Ideally, the culture should be shifted so, that the burden of proof of benefit is on whoever provides the update.JW

author: tszaboo
author_rank: Super Contributor
timestamp: July 22, 2024, 07:54:52 pm
content: Quote

author: wraper
author_rank: Unknown
timestamp: July 22, 2024, 08:12:32 pm
content: Don't deploy to prod on Friday.

author: wraper
author_rank: Unknown
timestamp: July 22, 2024, 08:17:59 pm
content: Quote from: jzx on July 22, 2024, 11:59:51 amBackup is not an issue here whatsoever, no data corruption happened. The issue is about how do you boot many thousands of computers to delete the file that causes BSOD. Basically needs a physical access and manually doing one by one unless it's running on a virtual machine.

author: wraper
author_rank: Unknown
timestamp: July 22, 2024, 08:21:53 pm
content: Quote from: peter-h on July 22, 2024, 11:42:10 amMS is not liable whatsoever. They have nothing to do with causing the problem. However MS stepped in and released a tool for simplifying the fix.

author: langwadt
author_rank: Super Contributor
timestamp: July 22, 2024, 08:31:12 pm
content: Quote from: wraper on July 22, 2024, 08:17:59 pmand if you are using bitlocker, which is default now I believe, you need the key you can't just boot in safemode

author: peter-h
author_rank: Super Contributor
timestamp: July 22, 2024, 08:48:51 pm
content: QuoteIt is probably not possible to do that, in the contractual sense. Microsoft dominated that market (windows servers and the applications, basically) and youhadto use that Crowdstrike stuff. The smart thing, which probably few did, was to test the updates first. The fact that some or many did a BSOD suggests that the simplest test setup would have shown the issueIn embedded/IOT the vendor may sometimes be dominant but often the customer will be dominant and thus be able to sink your company if you push out a damaging update. Customers in particular do that because of internal company politics: a corporate ladder climber needs to show ruthlessness, and of the three options on who to scalp (customer, employee, supplier) the last one is the only safe option.You can screw an employee but only if it is a heterosexual white maleEspecially if the failed update requires on-site action.This business should be an eye-opener for IOT vendors. But it's not easy to explain to a customer that you are not doing updates because of liability

author: langwadt
author_rank: Super Contributor
timestamp: July 22, 2024, 08:49:43 pm
content: Quote from: wraper on July 22, 2024, 08:21:53 pmafaiu the way crowdstrike gets around having to get every update signed by MS (it's a kernel driver to run in ring0) is that the crowdstrike driver is basically an interpreter that can execute code in kernel mode delivered separately as update files.MS allowing that to me sound like it basically makes the whole idea of drivers being wetted and signed, pointless

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2024, 09:58:03 pm
content: Quote from: langwadt on July 22, 2024, 08:49:43 pmYes, this is what Dave Plummer explains in his video.This is absolutely atrocious.We can all see how it would make CrowdStrike's life infinitely easier, but that's completely insane in terms of security. Compromising security for more security being a schizophrenic approach.Besides, no OS should require a third-party kernel driver for adding security to the OS - that's bogus.Everything is wrong in that story. The fact that it blew up in everyone's face is, IMHO, actually a very good thing. If it could be a lesson. Which, unfortunately...

author: peter-h
author_rank: Super Contributor
timestamp: July 22, 2024, 10:25:16 pm
content: Wonderful indeed

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 23, 2024, 12:36:00 am
content: Quote from: SiliconWizard on July 22, 2024, 09:58:03 pmYup, it's nuts. Microsoft side steps security, by giving the keys to someone else.Even with that, it's still hard to fathom howany release got past sand box testing ?!Surely they runanythingfor 24 hours or more, on a slew of candidate windows versions,before they release ?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 23, 2024, 02:41:07 am
content: I don't know the details, but from what I've heard, the code was correct at the test step and it got messed up at the "packaging" step - so what was actually deployed.Which would mean that they do not test with the final artefacts as deployed, but with intermediate build artefacts. Which, btw, is not that unsual - I've seen that on several occasions in companies of various sizes.I can't guarantee for sure that's what happened here, but something I've heard.

author: zilp
author_rank: Frequent Contributor
timestamp: July 23, 2024, 05:47:43 am
content: Quote from: langwadt on July 22, 2024, 08:49:43 pmYou are misunderstanding the purpose of code signing. The purpose of code signing is primarily authentication/attribution. Also, I think it is misleading to say that Microsoft vets drivers. AIUI, they don't even review the code. All their testing program does is try to find obvious reliability/stability problems. The point is to improve the average user experience due to easily discoverable bugs, not to provide anything close to a quality or security guarantee. Essentially, the signature from MS doesn't say "this is high-quality, secure software", it just says "this doesn't fall over quite as easily as shoddy drivers in past windows versions often did".

author: harerod
author_rank: Frequent Contributor
timestamp: July 23, 2024, 08:42:49 pm
content: In an IOT/MCU environment, which is much simpler than where Crowdsource is being used, one possible approach is double everything critical. Provided you have enough FLASH memory, you can have two bootloader sections and two application sections. A failed update can always switch back to the last known good version. If FLASH is not that abundant, make at least the bootloader redundant. When done correctly, you can recover the application after a missed update AND have a fallback for bootloader updates. The exact details need to be hammered out for each use case.Double BIOS images for PC's have been around for ages. One or two layers above BIOS, Crowdsource under Windows failed at having a fallback for a foul-up during a critical kernel driver update. In the past I have heard about "security concerns" preventing an automatic roll-back. One can only hope that they will figure out some solution.

author: langwadt
author_rank: Super Contributor
timestamp: July 23, 2024, 09:47:56 pm
content: Quote from: zilp on July 23, 2024, 05:47:43 amwhich would be better than crowd strike causing likely the biggest most expensive outage in historyapparently MS did try to force antivirus vendors to use a special MS api instead of everyone inventing they own stuff running in kernel mode, but were told that was monopolistic so they couldn't do that, but Apple could

author: IanB
author_rank: Super Contributor
timestamp: July 23, 2024, 10:06:17 pm
content: It is easy to say that security software can be worse than the problem it is trying to protect against. It is like installing malware to protect against malware. The latest "innovation" is when the security software randomly deletes files it doesn't like, or blocks installers from completing their tasks. Like, hey, isn't that what malware does?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 23, 2024, 10:15:08 pm
content: Quote from: langwadt on July 23, 2024, 09:47:56 pmWhich looks pretty reasonable. Running anything in kernel mode, if you can do otherwise, is insane.Quote from: langwadt on July 23, 2024, 09:47:56 pmWe don't know the full details I think, so it's hard to tell what exactly they were told.If Windows kernel was a microkernel, this would never happen. But, of course, that's just a if and impossible without a complete rewrite of the kernel. So, not a solution. Just a thought.So in the meantime, MS has no choice but try to offer alternatives to kernel drivers for basic security. What else could they do than provide a corresponding API?For once, it's definitely none of MS's fault (apart from the kernel not being a microkernel, but none of the major OSs currently is a microkernel, so...) If anything, they should change their WHQL policy to prevent kernel drivers from doing what Crowdstrike did, that is run as an interpreter to code that can be updated without requiring new driver tests. But maybe even just that would be considered monopolistic. Who knows.Heck, even preventing mass pushing updates on critical systems without any local sysadmin action, which should make a bit of sense, may be seen as monopolistic, preventing third-party companies from doing business as they like. Just stay away from Windows would be my pragmatic advice at this point.

author: langwadt
author_rank: Super Contributor
timestamp: July 23, 2024, 10:31:05 pm
content: Quote from: IanB on July 23, 2024, 10:06:17 pmI remember some maybe 25 years ago a guy at work spent days try figure out why a file to flash update a DSP kept getting corrupted, it turned out something at that binary file triggered a match in the antivirus that then just silently nulled that part

author: zilp
author_rank: Frequent Contributor
timestamp: July 24, 2024, 06:22:37 am
content: Quote from: langwadt on July 23, 2024, 09:47:56 pmNo, you are misunderstanding. That is what happened. Crowdstrike doesn't fall over quite as easily as shoddy drivers in past windows versions often did. That explicitly does not mean that it doesn't ever fall over, so in particular, things falling over doesn't mean that the process didn't work as designed.This failure mode was not a common cause of problems in the past, which is why it is simply an inappropriate expectation that processes that are designed to minimize failures from common past causes of failure would prevent it. That was never the goal.Quote from: langwadt on July 23, 2024, 09:47:56 pmDoes Apple even have antivirus software?

author: zilp
author_rank: Frequent Contributor
timestamp: July 24, 2024, 07:27:12 am
content: Quote from: SiliconWizard on July 23, 2024, 10:15:08 pmI would think that it would only be considered monopolistic if they themselves had better conditions?I mean, in practice, I would think that this is not a viable strategy because I suspect that any testing done by MS on drivers simply takes so long that it makes anti-virus software even more useless than it already is anyway. And to avoid accusations of monopolistic behavior, they'd have to subject their own solutions to the same testing delays. After all, deploying detection of an exploit after the vulnerability fix has been deployed is kinda pointless (even though that's kinda the primary business model of anti-virus software).Also, I'm not really sure that this is even correctly attributing the cause. I mean, sure, if this Crowdstrike stuff were some userspace process that only interacted with the kernel via an API that doesn't allow random corruption of the kernel, this particular method of crashing the system wouldn't have worked. But would that have changed anything about the effective result? I mean, if the security concept of your system is based on this Crowdstrike thing being active ... then, if that Crowdstrike userspace process were to crash, you would still have to halt the system, wouldn't you? So, what would be the difference?

author: woofy
author_rank: Frequent Contributor
timestamp: July 24, 2024, 01:09:06 pm
content: Dave Plummer has an update worth a watch.https://youtu.be/ZHrayP-Y71Q?si=gr81yvJK_4nVib30

author: wraper
author_rank: Unknown
timestamp: July 24, 2024, 08:37:47 pm
content: Blame the EUhttps://news.microsoft.com/2009/12/16/microsoft-statement-on-european-commission-decision/https://www.pcmag.com/news/why-did-crowdstrike-update-only-hit-windows-blame-the-eu-microsoft-saysQuote

author: zilp
author_rank: Frequent Contributor
timestamp: July 24, 2024, 09:04:26 pm
content: Quote from: wraper on July 24, 2024, 08:37:47 pmSo, where exactly did the EU force companies to install crappy software?Yeah, exactly, it didn't, but if some PR guy from a big company tells a story about how they would have saved the world if only the EU hadn't prevented them from abusing their monopoly position, as they have done many times in the past, then you sure are happy to eat up their propaganda, as long as they blame the EU, right?Also, not to forget that this whole "security software" industry only exists because of Microsoft's recklessness concerning IT security in the first place.

author: IanB
author_rank: Super Contributor
timestamp: July 24, 2024, 09:11:26 pm
content: It seems the EU position on this is not quite what those words imply. Evidently, Microsoft had proposed to create a special security API so that vendors could write security products that interact with the OS in a safe way without destabilizing it. This is something that Apple has apparently already done. It seems the EU viewed this proposal as a way of putting independent software vendors at a disadvantage, so they rejected it. The EU position is, of course, nonsense. The existence of a safe API in no way prevents vendors from continuing to write and install kernel mode drivers, if they so wish. It's just that no customers should want to buy those products. Every time my computer does a blue screen, it is due to a third party device driver (yes, Logitech, I'm looking at you).

author: wraper
author_rank: Unknown
timestamp: July 24, 2024, 09:16:59 pm
content: Quote from: zilp on July 24, 2024, 09:04:26 pmDue to EU MS had no other choice but to allow Crowdstrike to run at kernel level. At 6:00 Dave Plummer says MS was working to move antivirus software out of kernel but was hit by EU regulators

author: ejeffrey
author_rank: Super Contributor
timestamp: July 25, 2024, 03:13:41 am
content: Quote from: peter-h on July 22, 2024, 12:26:04 pmThis is basically the entire solution.If you distribute updates to more than a few hundred systems, you need a randomized phased deployment protocol.Having test systems and beta tracks is great, you want to catch as many bugs as you can there. But these systems and their deployment process never perfectly reflect reality and some problems will still only show up in production. So you randomly select 0.01% or so of your fleet to receive the update first, and you monitor for problems. Then you do 0.1%, 1%, 5%, watching for failures at each point. You want it to be random so that you get good coverage of the possible client configurations. It's not foolproof but as long as you do the rollout slow enough to actually respond to early problems this approach will catch a very large fraction of defective updates and keep the impact mangagable.I don't know why crowd strike doesn't do this. Maybe they do but bypassed it in this case?

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 25, 2024, 03:49:54 am
content: We've usedBerkeley Packet Filterstate machines to do with network communications what virus scanners do with storage I/O fordecades: a filter interpreter running in privileged mode "executing" unprivileged filter "code". Even the per-processseccomp filtersin Linux are based on BPF.There is ample experience and research on embedding interpreters and state machines in privileged environments safely, even when the instructions or filter is unprivileged/untrusted. (The equivalent is BPF/eBPF filter validation (offline and runtime) and privilege separation.)Even if CrowdStrike implemented a completely novel kernel-mode interpreter, they should be well aware and experienced with the security aspects, since it is well known and well researched; this kind of failure really does indicate horrible development practices. It should not have been possible to happen, and is not an understandable accident or failure at all.The question is, why did CrowdStrike implement their kernel-mode interpreter so poorly allowing it to hang Windows machines at bootup; it is not why EU required Microsoft to allow CrowdStrike to implement a kernel-mode interpreter. The difference is similar to blaming a hardware store for selling a hammer to a person who later went on a rampage with it.To be clear, I personally do not blame Microsoft or EU at all here; it's all purely on CrowdStrike.

author: zilp
author_rank: Frequent Contributor
timestamp: July 25, 2024, 04:35:27 am
content: Quote from: wraper on July 24, 2024, 09:16:59 pmDid you notice how that is not an answer to what I wrote?I'll spell it out for you: Just because Microsoft is not allowed to prevent some other company from building a product, doesn't mean that other people are forced to use that product.Also, the premise of your argument, if one can call it that, is that Microsoft would have been guaranteed to build a better product.For all we know, Microsoft would have built that kernel driver ("the API") with a bug in it that would have caused millions of windows machines to crash while using Crowdstrike, and then you would be going on about how the EU allowed Microsoft to prevent Crowdstrike from building their own kernel driver that wouldn't crash machines.The point of having a market economy is that the market participants decide which products thrive and which don't, rather than having the government decide, because the idea is that the broad market is much better at picking out the best products vs. the government picking the products that are allowed to exist.Your "argument" here is that the EU government should decide which company is allowed to build the kernel component of security solutions, rather than have the market decide which vendor they prefer. That's what is called a planned economy, i.e., what the USSR tried. As you might be aware, that experiment failed catastrophically.All the EU did here is that they guaranteed equal market access to all vendors, so that the market has a chance to decide. Your demand is that the EU should have picked Microsoft and should have allowed Microsoft to prevent competition.

author: zilp
author_rank: Frequent Contributor
timestamp: July 25, 2024, 04:54:36 am
content: Quote from: IanB on July 24, 2024, 09:11:26 pmDo you have a source for this? Because based on what I've read about this so far, things were about "moving antivirus software to a new API", not about "providing a new API that antirvirus software can use", including the quotes in this thread, like:"The agreement says: "Microsoft shall ensure that third-party software products can interoperate with Microsoft’s Relevant Software Products using the same Interoperability Information on an equal footing as other Microsoft Software Products."Nothing in that suggests that Microsoft is not allowed to provide such an API. All it says is that it can not prevent other companies from building a competing product to that API.

author: madires
author_rank: Super Contributor
timestamp: July 25, 2024, 07:24:39 am
content: Back then it was a measure against Microsoft creating an anti-virus - equivalent to the Internet Explorer - and taking over the anti-virus market. If Microsoft wanted to establish a more safe API for anti-virus they could have done that under the premise that they provide access to that new API to all anti-virus companies. Microsoft partly blaming the EU for the Crowdstrike disaster is just classic FUD to influence current EU antitrust investigations into Microsoft's latest endeavors.

author: peter-h
author_rank: Super Contributor
timestamp: July 25, 2024, 04:22:40 pm
content: QuoteProbably zero-day exploits.Also people don't have a choice on what to buy. Corporate IT life is about ticking boxes, to demonstrate "best practice". And if M$ bundle a product, you have to buy it. It ranks up there with LGBTQ+ recruitment, etc.That is also what enabled Office 365 to blow up. It is another way of ticking the best practice box, plus permanently valid software licensing which avoids employing somebody who keeps checking PCs to make sure they are not running bootleg software

author: Siwastaja
author_rank: Super Contributor
timestamp: July 25, 2024, 04:42:06 pm
content: Even if you fail to do anything else, do updates with canary testing. In other words, update say 1% of your customers first. Wait for a few days, update 10% and so on. This costs almost nothing to implement, and is the last line of defense against poor quality updates, greatly limiting the extent of the damage. 100 pissed customers is so much better than 100 000 pissed customers.

author: IanB
author_rank: Super Contributor
timestamp: July 25, 2024, 04:57:03 pm
content: Let's be brutally cynical about this. Companies like CrowdStrike tend to have their origin as startups with leaders who spin a good yarn to get venture capital investment, and young, inexperienced developers whose ambitions exceed their abilities. Expecting this event to be due to anything other than incompetence is to give far too much credit to those concerned.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 25, 2024, 05:02:46 pm
content: Quote from: IanB on July 25, 2024, 04:57:03 pmWhich is completely OK - they say themselves not to use their product for anything serious, but idiots are buying. The only thing to blame is the sick corporate culture of "no one ever got fired byIBM<insert trend thing of the year>". Certain products (for example, in open source world,docker) get a cult status are getting usedjust because, to the point of using something else for good technological reason is considered like some kind of extreme rebellion needing almost impossibly strong arguments, when it should be the other way,choiceof a certain product should be justified by arguments. (In more healthy culture, this would lead to varying, different choices being made, in a distributed way companies not even knowing about each other. But if everyone copies others, that puts all the eggs in one basket.)Those tech team middle managers should have some serious explaining to do to their company higher-ups and finally shareholders. Why choose a product the manufacturer of which says it is not suitable for the job, just because others are doing the same?

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 25, 2024, 08:50:58 pm
content: Yes, Crowdstrike's fault. pure and simple.So what's the likelihood of crippling litigation?Yes, sure the fine print says "we wont be responsible for anything" but that matters little in a court where the judge can probably be fairly easily convinced of cowboy behaviour , the crowdstike people knew their kit was being used in commercially critical infrastructure, with big dollars at stake due to non performance- they cant hide from that.. .

author: IanB
author_rank: Super Contributor
timestamp: July 25, 2024, 09:18:15 pm
content: Quote from: glenenglish on July 25, 2024, 08:50:58 pmLeonard French posted a video on YouTube where he suggested that if litigants could prove gross negligence on the part of CrowdStrike, then this might persuade the courts to put aside any limitation of liability claimed in the EULA.

author: radiolistener
author_rank: Super Contributor
timestamp: July 28, 2024, 06:11:10 pm
content: The lesson learned is to keep away from software/hardware products which is controlled by some world wide corporation.Any kind of OS like Windows, Android, iOS, ChromeOS is a real danger and should be avoided.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2024, 02:11:06 am
content: Quote from: radiolistener on July 28, 2024, 06:11:10 pmExactly, this is the very mechanism of forced updates which is at fault here. Companies should be in full control of their servers. The companies who trade their freedom for false security do not deserve neither and will lose both.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2024, 09:30:48 am
content: Quote from: NorthGuy on July 29, 2024, 02:11:06 amSo you should not outsource to other companies? How about outsourcing to consultants? Hiring under your own payroll? Or maybe the CEO should run the whole business alone?In other words, I disagree in general.Usually, outsourcing to specialists is a good idea, so that you can concentrate on your core business. If everyone invented their own security solutions and hired their own security experts to write/manage/update their own firewall software, quality in general would be order of magnitude worse.Then again, the other extreme end, everyone buying from one giant supplier isn't that great either. Healthy competition and somewhat diverse ecosystem of technical solutions is what offers good middle road in reliability, cost, and limitation of consequences if something goes wrong.

author: eutectique
author_rank: Frequent Contributor
timestamp: July 29, 2024, 10:19:47 am
content: Quote from: quince on July 29, 2024, 10:01:48 amDoes Rust do automagic sanity checks of user input?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2024, 11:04:04 am
content: Quote from: quince on July 29, 2024, 10:01:48 amToo obvious troll post. Almost got me, but not quite. 2/5.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2024, 12:10:24 pm
content: Quote from: Siwastaja on July 29, 2024, 09:30:48 amThis has nothing to do with outsourcing.They give full control of their servers to Microsoft, Crowdstrike, most likely to other companies too. These "providers" can do anything on the servers and PCs under their control, and the owners do not even have the ability to cut off this control in a state of emergency. The "providers" may not have malicious intents, but their employees may be bribed, radicalized, tortured or what not. They may be infiltrated by terrorists or foreign powers. This give them an ability to control most of the computers in the world, for example take down the infrastructure of any country in a matter of hours. With all eggs in one basket the consequences may be dare. Is that your idea of security?Do you believe that Crowdstrike should be given full control of nuclear weapons too? May be they are not secure enough without Microsoft or Crowdstrike?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2024, 01:22:32 pm
content: Quote from: NorthGuy on July 29, 2024, 12:10:24 pmIt haseverythingto do with outsourcing, it's a prime example of a case where everyone outsources to the same company and probably no one does their due diligence to monitor the reliability of their service provider, because "no one ever got fired by buying IBM".So while it's an example of outsourcing producing bad result, the answer is not to stop outsourcing, but outsource more carefully.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2024, 02:32:45 pm
content: Quote from: Siwastaja on July 29, 2024, 01:22:32 pmIf you hired a company to install a secure steel door, this is outsourcing, and this strengthens your security.If at the time of installation you sign a contract that no duplicate keys are ever made, this is where you strengthen your security further.If, instead, you sign a contact where the installer makes a duplicate key and acquires the right to enter your premises at any time and do there anything they want without being liable for consequences, this is where you weaken your security and give up your rights.How did it happen that, in the software world, the later case is perceived more secure than the former is also a very interesting question. If you have time, may I suggest a good read - "Extraordinary Popular Delusions and Madness of Crowds" by Charles MacKay. The book is about trading, but it explains how people may part their way with common sense and make really stupid decisions. It is an interesting read regardless.

author: wraper
author_rank: Unknown
timestamp: July 29, 2024, 03:47:54 pm
content: Quote from: NorthGuy on July 29, 2024, 02:32:45 pmVery poor analogy for an antivirus-like software. Not to say even you don't do any updates ever, you still need to trust them that there are no backdoors.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 29, 2024, 04:30:04 pm
content: Do note that however you look at it, the outsourcing problem is prevalent in free/open source projects as well.Way too much stuff, including security sensitive stuff, relies on some library a poor developer trying their best with very limited resources, with everyone relying on the end product but nobody contributing to its upkeep. I'm not talking about money, either; the xz backdoor was possible due to lack of developer time and resources. At the same time, there are well funded developer teams who believe they should be shielded from criticism by end users, with someone else acting as their secretary and bouncer. Some of the open source developers are just as bad as the bad proprietary software companies, and some of the proprietary companies behave very well wrt. their customers and even open source projects.It is a human and cultural problem, not a technical one.Is there anything to learn from the CrowdStrike disaster? Nothingnew, just the same old story. Just compare this to the various physical disasters caused by specific companies (ships blocking Suez canal, building collapsing bridges and other buildings, et cetera). Though, I must admit, a $10 Uber Eats gift card does not compare favourably to actual insurance payouts...

author: IanB
author_rank: Super Contributor
timestamp: July 29, 2024, 05:19:29 pm
content: Another human and cultural problem is that CrowdStrike apparently just released a blog post about the incident, that basically says:"There was a temporary problem with an update that caused some Windows systems to crash, but we quickly corrected it, so it didn't last very long. We are going to avoid this in future by doing more adequate testing of what we release. Nothing to see here, move along now."Public statement linked and attached for posterity.https://www.crowdstrike.com/wp-content/uploads/2024/07/CrowdStrike-PIR-Executive-Summary.pdf

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2024, 05:44:37 pm
content: Quote from: wraper on July 29, 2024, 03:47:54 pmSame as with steel doors, you need to trust the manufacturer not to make a duplicate key and go rob you in the middle of the night.As to the anti-viruses, people trust them absolutely, and also fear viruses too much. Consequently they let anti-viruses do whatever they want and patiently tolerate all the problems caused by anti-viruses. Such approach is certainly heavily biased.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2024, 05:57:04 pm
content: Quote from: NorthGuy on July 29, 2024, 02:32:45 pmIncorrect analogy, because a steel door with physical key requires very little maintenance, so the whole challenge of antivirus/data security (the fact it's a moving target) is bypassed. Better analogy is hiring security officers at your premises. Maybe they even carry weapons. They need access to your secret areas to effectively do their job. And it's a totally nontrivial problem to choose whether you hire them on your company payroll, or outsource from a security-related company, latter is very likely a wise thing to do, but on the other hand you can't do that blindly, as this resource can be compromised either by accident or on purpose.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 29, 2024, 10:17:09 pm
content: Quote from: IanB on July 29, 2024, 05:19:29 pmThis is hilarious.

author: langwadt
author_rank: Super Contributor
timestamp: July 29, 2024, 10:39:54 pm
content: Quote from: Siwastaja on July 29, 2024, 05:57:04 pmand in this case it seems like the security company thought it would be too much hassle to have every security officer go through the front entrance, so instead they had one guy go in and open a backdoor for easy access

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2024, 11:01:56 pm
content: Quote from: Siwastaja on July 29, 2024, 05:57:04 pmYou keep trying to make it about outsourcing. The problem is the behaviour.Many software companies (not only Microsoft, CrowdStrike, but others as well) overstepping their boundaries, disrespecting their customers, pushing their updates as if they were more important than customers' business. Do you really like that? Is that how you would want it to be?As to CrowdStrike specifically, they have a driver which reads pseudo-code from files and executes it in Kernel mode. This can do anything - wipe out the hard drive, or steal all the files. An attacker can overwrite some of their files and thereby make their driver execute them. This is a new vulnerability that didn't exist before. Shouldn't the customers think about that? Or should they unquestionably believe that everything made by CrowdStrike is good?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 30, 2024, 06:09:05 am
content: Quote from: NorthGuy on July 29, 2024, 11:01:56 pmNo, it was you who gave impractical advice of "don't give power to others".QuoteI fully agree.QuoteI fully agree as well. The solution is not to stop giving power others by contracting, it's about choosing partners wisely and monitoring their contributions. The fundamental issue is excess trust in partners only due to their sheer size - "no one ever got fired by buyingIBMMicrosoft". And in reality, companies blindly using Microsoft products causes massive loss of productivity every day, not to mention the huge risk of having all the eggs in the same basket.

author: wek
author_rank: Frequent Contributor
timestamp: July 30, 2024, 07:34:38 am
content: Quote from: Siwastaja on July 30, 2024, 06:09:05 amPutting absence of real competition aside, based on what are you going to make decision, how to split the eggs and how to select the baskets? And how to reject eggs you don't need or want at all?Being secretive about what the "updates" constitutes is the norm; plus "updates" are today widely seen as universally good, without questioning the risks/benefits ratio at all. This in turn makes "push whatever garbage you have out of the door, fix later" mindset to be a winning strategy; and this even did not include the "side" income from gathering data/intelligence or extortion.I may despise this approach, but for many maybe this is the real takeaway for the embedded/IoT (whatever that is).JW

author: zilp
author_rank: Frequent Contributor
timestamp: July 30, 2024, 08:28:18 am
content: Quote from: Siwastaja on July 30, 2024, 06:09:05 amIt wasn't, though. He said "full control" and "do not even have the ability to cut off this control in a state of emergency". That goes beyond just "giving power to others".Quote from: Siwastaja on July 30, 2024, 06:09:05 amWhile all of that is true, the problem is not just excess trust for bad reasons. One problem is trust in large corporations period.This is the exact same problem that democracy is trying to solve, namely, the risks of concentrations of power.Which is precisely why the interpretation of "don't give power to others" is oversimplified, even though there is some kernel of truth in it. It is true, in a way, that democracy works by putting limits on "giving power to others", in that giving all power over a country to one person is the antithesis of democracy. But obviously, the idea is not to never "give any power away". Rather, one defining characteristic of democracy are elections, the purpose of which is explicitly to "give away power", i.e., to delegate the power to make decisions to others. But the important part is that the system as a whole is ideally set up in such a way that no single person or small group of people gains an exceedingly large amount of power. That is how democracy tries to limit the damage that can result from a person going rogue, being incompetent, being blackmailed, whatever--and, maybe even more importantly, this also decreases the incentive to corrupt people, because the power that you can gain by corrupting people is also limited.Analogously, the solution is not to avoid all outsourcing. But the solution requires limiting how much power ends up in the same hands. And in that context, it is not sufficient to just look at how many other customers some supplier has. It is also important to consider how much power they gain over you when you buy their product. And forced automatic updates of software that runs with unlimited privileges on all of your systems is the maximum of power that you could possibly be giving away to a single entity ... as was just demonstrated. Mind you that this effectively means that the admin password of the build machine of Crowdstrike is effectively the admin password to all of your machines. So, it's not just about whether you trust the integrity of the people in that company, you also have to consider the size of the target on their back. Someone who manages to compromise their systems effectively gains admin access to millions of systems that guard trillions of dollars of value, that can be used to cause even more trillions of dollars of damage ... i.e., it is a very high value target for both corruption and for compromise, even if your own company by itself might not be of much value to an attacker.Also, I just want to remind everyone that it is not a law of nature that constant software updates are a necessity for having secure systems, but that rather a lot of vulnerabilities are the result of bad engineering, and often ultimately of business priorities. It isn't just a law of nature that products you buy are full of defects. In many ways this is equivalent to it being accepted as completely normal that your industrial machinery constantly explodes, and that you think the obvious solution would be to hand keys to your factory to the manufacturers of those machines, so that they can sneak in at any time to swap parts.And with anti-virus and similar products, you further have to consider that they are largely useless unless you are doing things very wrong elsewhere, so the potential gain from handing over so much power (and the risks you accept as a result of that) is rather limited. If there is a piece of malware that exploits a vulnerability that does not exist on your systems (either because you simply aren't using the affected software, or because you installed the security fix), then having software that prevents that malware from reaching your systems is useless. Malware that exploits vulnerabilities that don't exist on your systems is not a danger to you. At the same time, all of the code of anti-virus software that deals with all of the untrusted data to check if for malware, is itself a huge attack surface, and given the complexity, is pretty much guaranteed to have vulnerabilities. So, you are potentially installing additional vulnerabilities for the purpose of preventing stuff from reaching your systems that would not have any negative impact if it did reach your systems.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 30, 2024, 12:25:22 pm
content: I tried to think of examples illustrating why the cultural reasons that lead to CrowdStrike disaster are not specific to any software product, but are ubiquitous. (I do not knowwhythat is; I am only trying to point out the bigger picture here.)There are some that come to my mind, all on the web server side, but they do apply to embedded/IoT development, integration, and deployment too.The first is server configuration in Linux distributions. How many of those who maintain web servers (at the Apache/Nginx configuration level) use a different active server configuration directory from the default one? Very, very few. This means that whenever software updates are applied, any web server related configuration will be automatically applied and take effect, too. While most distributions are quite good at using "safe" default configuration files, installing the wrong package may enable a web-based service (specialized Apache/Nginx module) that compromises the security on the machine due to cross-service interactions.(I always use a dedicated directory, with a separate configuration information. For about a decade, I even published one designed for group-based maintainer access (when you have may webmasters with different levels of access to a mixed tree) at my previous home page. This way, I can allow automatic security patches to the server, but monitor the distribution-provided configuration directory –– which does not affect the running service at all –– for important changes that may need to be ported to the server. I did this on a number of rather public servers, with very good results (both security and support to webmasters); and not because they were small and quiet: they were constantly bombarded with exploit access patterns based on the log files! Yet, to introduce the pattern to new sysadmins/sysmasters/web root admins, I always need to explain the whole story with examples before they realize the small inconveniencethey imaginethis causes, actually improves their work product for everyone, and typically reduces the time taken for maintenance in the long run. This should be the obviousdefaultpattern, not something that has to be pushed through heavy resistance!)The second is self-modifying web scripts –– "required" only so that one can update the web framework by clicking on a button on a web page ––, and the third is embedding credentials in the firmware.Allowing web service executables to rewrite themselves or create new executables is the reason why script drops, trojans, and worms are still plagueing web frameworks. If they could not modify themselves or create new executables, almost all exploits would immediately stop working, with entire approaches becoming impossible to exploit.Embedding credentials in the firmware, even if in salted password form, allows anyone excavating those credentials to pose as that device. It makes it possible to create infiltration and exploitation devices that pose as the original device, but produce attacker-controlled output. In IoT devices communicating with upstream servers, it allows the attackers to communicate with those upstream servers without the upstream servers being able to detect it. This applies to both custom protocols and common protocols like http and smtp. A lot of spam is injected to email servers via exploited trusted clients, for example.Now, I'm not here to argue whether the above is correct or not (especially with zilp), because I've observed this in practice for a long time; decades. I described them only as examples, to illustrate the analogous human behaviour to that underlying the Crowdstrike disaster, so give some slack.The point I am trying to make here is that doing things the above way is what most sysadmins, webmasters, systems integrators, developers, et cetera nowadayslearn to do by default, because it aligns with the cultural approaches we have. We don't build buildings to last, so why would one expect us to build software to last either? It isnot cost-effectiveto do so. When we teach software development, error checking is at best an afterthought, normally omitted to "save time".You have to train people to think along better lines, in better patterns, or they will repeat the mistakes others have repeated before, learning nothing from history. (And, they will typically complain all through training how much a waste of time this is, because <the example exploits> are so rare in practice, they're not worth worrying about. Just like you see when you write code that say checks the return value ofclose(); because "it cannot fail for normal files on typical desktop file systems".)Of course, exactly what those better patterns are, is a separate discussion; it is more about "how to avoid Crowdstrike disaster situations" than "what to learn from the Crowdstrike disaster").

author: peter-h
author_rank: Super Contributor
timestamp: July 30, 2024, 01:10:30 pm
content: In the embedded context, this debacle ought to make manufacturers think about the risks of firmware updates, especially if they have sold a lot of the boxes to a customer big enough to sue

author: madires
author_rank: Super Contributor
timestamp: July 30, 2024, 01:57:37 pm
content: Quote from: Nominal Animal on July 30, 2024, 12:25:22 pmActually the problems already start with using the distrbution's apache/whatever package. Usually you'll get a daemon with all features enabled. It might not be the best setup for your specific environment (performance-wise) and also increases the attack surface with features you don't use. Especially for apache's httpd there are compile-time options which have a huge impact on performance in specific environments and on the use of other features. If someone finds a critical security issue in feature xyz and you don't have that feature enabled in your daemon you can relax.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 30, 2024, 03:44:50 pm
content: Quote from: madires on July 30, 2024, 01:57:37 pmYes; fortunately, most of the modules are configurable, so it's a matter of using a completely separate configuration directory rather than recompiling the daemon. Any configuration I do always starts from the absolute minimum; usually from the choice of the worker module and its initial configuration.My own configuration schemes require a few local users and groups per virtual host, just to correctly manage access rights to filesystem resources. Unfortunately, this is not compatible with most web hosting services (using cPanel, Plesk, etc.) as they are designed for one user account per site. So silly...And it's not just multiple user accounts, either. If only the robust methods of creating directed graphs of allowed user identity transitions –– that user A can switch to user B but not vice versa; that user B can switch to user C but not vice versa (and user A to user C only by switching to user B in between), like a very simple state machine allowing identity transitions ––, we could make web scripting environments even more secure. (We can do it now based on process ID's and an external daemon, but it is fragile with several attack scenarios.) The script interpreter instances are configured on a per-vhost basis in both Apache and Nginx, with specific user and group privileges. Those would be sufficient to obtain the necessary credentials to databases and e.g. a connection to the user verification. For each incoming request, a fork of that process would then drop privileges as soon as the request URI is received (final privileges depending on that URI), before even fully parsing the request. For pages involving user password of configuration in read-write form, you could use a separate user account than on normal pages; similarly for pages that upload static file objects, and administrator interfaces. The kernel then manages the privilege separation between parts of the site. Very little of the site code would be security-sensitive. For example, a bug in scripts generating user-configurable style sheets could not be exploited for a script drop, no matter what bugs it had, because it simply does not have the privileges to create any filesystem objects in the first place. It sounds complicated, but isn't.Simply put, wecanalready minimize these attack/exploit/catastrophic error surfaces; we simplydo not do so yet. We can, but most people object to it when it comes to do the grind –– or at least whenever I've done this stuff, I've had to seriously fight against those demanding for simpler (butclearlymore vulnerable/fragile) approaches, and definitely not because the others didn't know what they were doing: their priorities just differed from mine.Hell, I'm not even sure anymore whether the more secure and robust approach is the one weshoulduse, because marketplace competition says users arenotdemanding it, nor are they willing to pay for it. They just want to express their outrage on social media for a few days, then revert back to the same old behaviour.

author: madires
author_rank: Super Contributor
timestamp: August 03, 2024, 04:59:15 pm
content: Crowdstrike doesn't like parody and tries to take downhttps://clownstrike.lol/. You can read the DMCA and the response athttps://clownstrike.lol/crowdmad/. Streisand effect at work.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 03, 2024, 09:20:17 pm
content: Nice.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 04, 2024, 12:45:58 pm
content: Baseless DMCA claims are wonderful, since they transform the company which only made a mistake, into an actual fucking criminal organization.People who are in positions where they decide this stuff, should remember using services from criminal organizations is not a really good idea, and might get you fired.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 04, 2024, 01:52:45 pm
content: Quote from: Siwastaja on August 04, 2024, 12:45:58 pmI wonder how well these officers making horrible decisions (including baseless DMCA claims) impacting share price recognize the risks of shareholder lawsuits especially in the USA. Using a "reputation manager" company as a shield works to an extent (and that's exactly why they're used), but at some point the largest shareholderswillintervene.

author: madires
author_rank: Super Contributor
timestamp: August 07, 2024, 03:20:04 pm
content: Fromhttps://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/:QuoteClassic lack of input validation.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 07, 2024, 10:13:21 pm
content: Excellent. But that's nobody's fault! Input validation was in none of the user stories.

author: wek
author_rank: Frequent Contributor
timestamp: August 08, 2024, 09:33:10 am
content: Quote from: quince on August 08, 2024, 05:45:42 amThe reason why this can be seen, at the same time, by some as trolling and by others as freeing truth is, that there's practically no evidence for nor against.AsDerek Jonessays, there is often little science in computer science.JW

author: floobydust
author_rank: Super Contributor
timestamp: August 12, 2024, 05:12:52 am
content: CrowdStrike External Technical Root Cause Analysis — Channel File 291https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdfBASIC and PASCAL have run-time array-bounds checking. Out-of-bounds array indexing, ahhh C++ is shit as is C, let's celebrate 50 years of this crap

author: Siwastaja
author_rank: Super Contributor
timestamp: August 12, 2024, 06:34:00 am
content: Quote from: floobydust on August 12, 2024, 05:12:52 amThis is oversimplification of what happened. Lately I have been dealing with shit caused by array-checked language causing complete crash of everything. To the customer, the end result is exactly the same: either white screen of death; or complete misbehavior of all random stuff.Or it can be worse; maybe, by luck, the variable which would get corrupted would be some rarely needed or unimportant thing. But range checking escalated that into full blown total crash.For developers of course, it is much nicer to have a repeatable crash with clear explanation why, instead of weird bugs that affect something else in execution flow. But if developers are not interested in quality, then this opportunity is wasted. Range checked languages require as much care as non-range checked. Fanboyism leads to false sense of security.In this particular case, as it often is, the crash clearly was instant, repeatable and easy to reproduce and find (e.g. by using a debugger), so the root issue was that developers were not interested in checking their inputs and not interested in testing their product (they first tested the 21-parameter use case on customers). Which means that even if language had exception mechanism to catch over bounds accesses, developers would not have used it either, instead letting it to escalate into full crash like these languages usually do by default if you don't try-catch (or whatever the mechanism) with fine enough granularity. Which you should do, just like on C++ you should range check arrays.It is tempting to do simple conclusions, but be careful not to make wrong ones. Advanced tools usually do not remove complexity, just move responsibilities elsewhere.

author: Marco
author_rank: Super Contributor
timestamp: August 12, 2024, 08:31:39 am
content: There's always javascript, it doesn't panic on out of bound.There's some work in Rust to try to prove code can't panic, though I have no idea how it handles the possibility of stack overflow.

author: mfro
author_rank: Regular Contributor
timestamp: August 12, 2024, 12:43:38 pm
content: Quote from: Siwastaja on August 12, 2024, 06:34:00 amCertainly. Simpler languages like Basic and Pascal just offer to terminate the program when array-bounds checking finds an offence.That obviously wouldn't help much in an OS kernel - where should it terminate to?If that routine had been written in Ada with a simple catch-all exception handler that would just restart skipping the offending channel file, nothing had happened. If that routine had been written in Ada and verified using SPARK, it wouldn't even have needed the exception handler.Even better, if Microsoft had decided to write their OS in Ada (and some SPARK for verification) first place, most likely the whole Crowdstrike business model would fall apart since it wouldn't be needed anymore.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 12, 2024, 03:13:56 pm
content: I think one good thing to come from this is that the EU will have to revisit their policy which stopped MS from employing that new API they'd developed which stopped security-related drivers from running in kernel mode.It was a bad decision by the EU, who were obsessed with stopping a Microsoft monopoly and overlooked the security and reliability implications.So I expect an improvement in the resilience of the Windows OS to follow along in due course.

author: mfro
author_rank: Regular Contributor
timestamp: August 12, 2024, 03:34:22 pm
content: Quote from: SteveThackery on August 12, 2024, 03:13:56 pmNonsense.The EU did not stop MS from implementing a new API in any way - they just said that independent security vendors need to have access to that API.The EU also didn't talk Crowdstrike into implementing crappy software.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 12, 2024, 04:14:53 pm
content: The OP asked about lessons that could be learned, and I'm guessing that was intended to be in the context of microcontroller (the title of this forum).The user mode vs kernel mode argument is probably a bit less relevant in the world of microcontrollers. However, one thing that struck me from Big Dave's video was that the kernel mode driver - signed, of course - wasn't what was updated. Rather, it was a data file that the driver read from disk and then processed that caused the driver to choke.So to me, one lesson that absolutely applies to microcontrollers is the need to make sure all parts of your code are resilient to bad incoming data - whether that is from a sensor, a file, the user, or another part of your code. It implies sanity checking all such data before making use of it.* In many cases this won't be trivial. It requires a full description of what "sane" data looks like, and I can imagine this will be non-trivial in many cases.Furthermore, even when the incoming data has been sanity-checked, there is still a need for a policy on what to do when "not-sane" data is encountered. When it is user input it might be reasonable to show an error message and ask for the data to be re-entered correctly. But what about when it is from a sensor, or a file read from disk? Yes, a proper sanity check will warn when it's bad, but then what? Your policy for handling these circumstances will probably require a fair bit of effort to design and implement. Plus you need to make sure its scope is comprehensive enough to handle all conceivable sanity check failures.I wonder if there is a development process or model that makes sure this is properly addressed during the design and coding stages. Exception handling and try-finally blocks provide some of the "how", but the big picture - the "what" - still needs defining.*When I was learning to code, like almost all of us I had to develop a simple calculator: add, subtract, multiply, divide. And probably like many of us, I experienced my first crash - a 'divide-by-zero' exception. That led to my first sanity checking lesson: ensuring that the denominator is not zero before going ahead with the division. I then extended that to screen out non-numeric inputs. However, I don't recall receiving or reading much more on the topic of sanity checking and software resilience. Yes, throwing and catching exceptions is taught, but the next layer up - the "so now what?" layer - doesn't seem to play a big part in learning to code. Mostly because its apolicythat needsdesigningbefore the code gets cut.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 12, 2024, 04:35:37 pm
content: Specifically funny in how Rust fanboys are jumping into the case is that, in this particular case, due to sheer luck, overindexing happened into a page not allocated by the OS, and therefore - again by sheer luck - producedsame responseas a range checked language - again in absence of error handling - would have produced.There are advantages in languages which always range-check. For example, this non-checking bugcould haveallowed access into allocated kernel page, possibly allowing an attacker full privileges to silently enter the system and access any data, or turn the computers into botnets, which arguably iseven worsethan the kernel crash and related downtime.Yet, in this particular case, this did not happen. By luck, the behavior of non-checking was exactly like in most decent range-checked languages: crash and downtime.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 12, 2024, 04:52:29 pm
content: Quote from: mfro on August 12, 2024, 03:34:22 pmIt isn't nonsense. Watch Dave's video for a fuller explanation - minute 6 onwards. The EU regulators explicitly stopped Microsoft from incorporating that API into Windows, despite Microsoft designing it specifically for "users like CrowdStrike". The whole truth seems to be more complicated: Microsoft intended that the API would only be available to SOME vendors, and the EU insisted the API be available to ALL developers or it doesn't go in. As usual the regulators won.But this doesnotmean that Microsoft were in the wrong, or being unreasonable, or anti-competitive. We cannot make that judgement until we know the full story. Why did Microsoft apparently limit the API to vendors "like CrowdStrike"? What were the criteria that must be met for a vendor to get access to the API?For all we know, those criteria might be perfectly reasonable. For all we know, they might have been quite easy to meet. For all we know, keeping the amateurs well away from that API might be extremely wise.We don't know the full story. All we know is that if the EU hadn't intervened, that API would be in place now and Windows would presumably be much more resilient to cock-ups like CrowdStrike made.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 12, 2024, 06:24:19 pm
content: Quote from: quince on August 12, 2024, 05:48:09 pmNo, obviously range checking in rust must be at both compile and runtime. This should be very obvious even to beginners, but... often you can't range-check during compile, for example in following example written in made-up pseudo language:Code:int idx, val;int array;cout << "Enter data index to write at (hopefully 0 - 9)?" << endl;cin >> idx;cout << "Enter value to write?" << endl;cin >> val;array = val;Compile-time checks, in those sadly rare or trivial cases where they are possible, are great not only due to the always-stated obvious reason that they waste no CPU or program memory during runtime, but also for a much more significant reason that proving the check would never fail also frees the user from having to think what to doifthe test fails - how to recover.Because that recovery is the very issue right here. A language which forces runtime checks (whenever it cannot check compile-time, which is very often in complex piece of software) does not magically know how to recover. While the programmer does not need to write explicit "if (idx > MAX_IDX)" type checks, they still need to write very explicit handlers for out of bounds accesses. Which is 99% of the work.The problem with fanpersonism is the oversimplification and false sense of security leading to fact that actual problems are not addressed at all.PS. If you use old and crappy languages like C in mission critical systems, consider using additional tooling. Static analysis tools that can detect misindexing at compile time are readily available, and much more.

author: Marco
author_rank: Super Contributor
timestamp: August 12, 2024, 06:50:50 pm
content: Quote from: SteveThackery on August 12, 2024, 04:14:53 pmI think having a rock solid bootloader which can do network updates of later stages is more important. It allows you to remotely recover from anything but the bootloader update going disastrously wrong, and wiping out the AB update mechanism ... in which case you should have a proper factory reset too.

author: wek
author_rank: Frequent Contributor
timestamp: August 13, 2024, 10:44:01 am
content: This may be something to learn from, not only for embedded/IoT:https://www.theverge.com/2024/8/12/24218536/crowdstrike-accepts-def-con-pwnies-award-most-epic-fail-global-windows-it-outageNow compare this with Microsoft's whining.JW

author: JPortici
author_rank: Super Contributor
timestamp: August 13, 2024, 11:36:16 am
content: Quote from: quince on August 12, 2024, 05:48:09 pmAnd that is GCC's fault.now try ClangCode:<source>:4:12: warning: array index 50 is past the end of the array (that has type 'int') [-Warray-bounds]4 | return x;| ^ ~~<source>:2:5: note: array 'x' declared here2 | int x[] = {1,2,3,4,5};| ^1 warning generated.ASM generation compiler returned: 0<source>:4:12: warning: array index 50 is past the end of the array (that has type 'int') [-Warray-bounds]4 | return x;| ^ ~~<source>:2:5: note: array 'x' declared here2 | int x[] = {1,2,3,4,5};| ^1 warning generated.Execution build compiler returned: 0Program returned: 64

author: zilp
author_rank: Frequent Contributor
timestamp: August 14, 2024, 11:55:03 pm
content: Quote from: SteveThackery on August 12, 2024, 04:52:29 pmFor all we know, if the EU hadn't intervened, that API would have had a bug that twould have caused millions of Windows machines to crash, and you would now be complaining how the EU had forced people to use Microsoft's crappy software instead of allowing more competent vendors to enter the market.The job of the people making that decision within the EU is to ensure that competition isn't hindered. The technical quality of products is simply not something that is relevant to their job. It is not their job to decide which products are good and which are bad and to then decide based on that which products are allowed to exist. Their job is to ensure that all vendors have a chance to offer their product in the market, so that customers have the choice, and can use whatever criteria they prefer to decide which product to buy.It isyourassumption that the MS API would have been higher quality. But for one, that's not really something that you know, much less that you would have known a priori. Then, even if that were true, that doesn't mean that that is true of all other products that are enabled by that EU decision. And in any case, that is not their job.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 12:37:22 pm
content: Quote from: zilp on August 14, 2024, 11:55:03 pmAh, I'm afraid you have let your anti-Microsoft bias show, which does weaken your argument somewhat. In fact your argument is really strange, coming from an engineer. It boils down to this:1/ Microsoft want to re-architect part of Windows to make it more secure.2/ But there might be bugs in the new code, undermining the gains it can offer.3/ The regulators don't care about bugs or the quality of anyone's code.4/ Therefore there is no case for allowing the improved architecture and we should continue with an architecture whichthe ownerhas identified as insecure and fragile.Can you see how silly this is? You are probably right that code quality is not the concern of the EU, but security vulnerabilities surely should be! If not, then the EU is the party that needs to do some serious thinking.Take your own code. Suppose you can see a fundamental weakness in the architecture that leaves it vulnerable to bad third party code. Do you leave it unfixed in case your solution introduces new bugs? (Don't say yes, because no one will believe you). The truth is that nobody's code is bug-free, but to use that as a reason not to close a gaping security hole in your software is absolutely nuts.There is a new architecture available that should greatly improve the resilience and security of Windows. Yes, theremightbe critical bugs in it, but we now knowwith certaintythat the existing architecture is extremely vulnerable.Getting the architecture right is crucial, and improving a bad architecture is crucial. It means you are starting from a better place with your coding.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 01:49:13 pm
content: Quote from: SteveThackery on August 15, 2024, 12:37:22 pmThat is not an established fact. That is Microsoft's claim.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmFor one, I still haven't seen any source that actually establishes that "the improved architecture" was not allowed. As far as I know, this was only about not allowing Microsoft to prevent competitors from accessing interfaces. If you actually have a source for that, feel free to point me to it.But also, this still is just Microsoft's claim, not an established fact.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmNo, they shouldn't either. Not in that part of the bureaucracy. Security vulnerabilities are adressed via liability rules and possibly via product quality standards, not as part of antitrust law.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmThis is simply misleading framing. You are phrasing this as if there is a security vulnerability in Microsoft Windows. There isn't. Or, at least not in this particular case. A security vulnerability is something that allows an unauthorized party to compromise the integrity of a system. That was not the case. What you call a "vulnerability" here is nothing more than the freedom of authorized parties (i.e., the owner of the computer) to install any software they want - and that happens to include software that crashes their system, or that contains security vulnerabilities, because that is an unavoidable consequence of having control over your own computer. It is your computer, and the fact that it is "vulnerable" to you installing any software that you want to install on it is a feature, not a bug.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmNo, I wouldn't, because that's a misrepresentation of my position.I would indeed potentially leave it "unfixed", because, in my view, it is not a vulnerability that the owner of a product that I developed can do with it whatever they want.And also, what I would do is not particularly relevant to what the competition authority should do.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmThere is no security hole in Windows.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmWe do know that the existing architecture of CrowdStrike is extremely fragile. That doesn't mean that it therefore makes sense to allow Microsoft in particular to have a monopoly on the part of the system that CrowdStrike screwed up. And that is what you are suggesting. It doesn't follow that because CrowdStrike was bad at it, therefore, Microsoft will build a better product than all other competitors, nor that that is something that the competition authority should be concerned with.Quote from: SteveThackery on August 15, 2024, 12:37:22 pmYeah. But making it so that only Microsoft is allowed to build the architecture isn't a useful approach to that problem.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 02:10:56 pm
content: Quote from: zilp on August 15, 2024, 01:49:13 pmThis is a seriously weird conversation. The existing architecture allows third party code to run in kernel mode. This means that third party code has the potential to crash the OS, or even read data from memory being used by other processes or threads.If youreallydon't think that is a security vulnerability, then you might be the only engineer on the planet to think that.Don't you remember the consternation in the early days of NT, when the decision was made to run video/graphics drivers in kernel mode? People couldn't resist pointing out how badly it undermined the whole secure and resilient architecture of this lovely new OS. They were right: it does.

author: IanB
author_rank: Super Contributor
timestamp: August 15, 2024, 02:23:16 pm
content: Quote from: SteveThackery on August 15, 2024, 02:10:56 pmPerhaps, but how are you going to define third party code?It's my computer. If I want to write and execute code in kernel mode onmycomputer, I can. That's first party code. It would be wrong, and worthy of serious complaint for anyone to prevent that.If I want to pay a consultant to write code for me that executes in kernel mode on my computer, I can. That's second party code. And likewise, I have every expectation to do so.Or I can license code available on the open market and have it run on my computer in kernel mode. That's third party code.So how should anyone, practically, technically, or legally, differentiate between first party, second party or third party code?Such differentiation is done, for example, by Apple on iPhones, but then, nobody is pretending that an iPhone is a general purpose computer. The iPhone can only be locked down the way it is, specifically by not being a general purpose computer.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 03:17:17 pm
content: So we're falling back on semantics now. I don't think I need to spend much longer on this. In the context of this discussion, when I wrote "third party" I meant "not Microsoft". I'm pretty sure everybody reading this thread - including you - knew exactly what I meant.The problem is this: ifyoucan write code that executes in kernel mode, so can anyone else. I'm sure you don't wantyourdesktop machine to be vulnerable to someone with hostile intent running kernel mode code on your machine. It would give them a level of control equal to the OS itself.I'm sure you would appreciate Microsoft making it as difficult as possible for said people to do that. I'm sure you would appreciate being protected against people who are merely incompetent, with no evil intent, like CrowdStrike.Allowing non-Microsoft code to run in kernel mode is an obvious security and reliability hole. It is time to revisit the EU decision, including getting to the bottom of why MS wanted to restrict access to only some vendors. The whole thing needs reviewing.

author: IanB
author_rank: Super Contributor
timestamp: August 15, 2024, 03:23:32 pm
content: Quote from: SteveThackery on August 15, 2024, 03:17:17 pmBut you can do that. Simply don't install or run such code on your computer.Here, "you" also means corporate IT departments.Such security software is at least as effective as the elephant fence around my home, which works perfectly. In all the time I have been living here, I have never once seen an elephant in my garden.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 03:25:21 pm
content: Quote from: SteveThackery on August 15, 2024, 03:17:17 pmThe idea of "third parties" not being able to do kernel modules is absolutely weird. It happens inanyOS, including those considered quite secure.The key is processes of approval, signing etc. so that users do notaccidentallyinstall low-quality kernel modules. And while not Windows expert, AFAIK MS has at least tried to do something about it. It's not like some Crowdstrike software gets randomly installed. You downloaded it, read the EULA, got warning message from Windows, were asked for Administrator privileges by Windows, to which you clicked OK, I'm an administrator.And this is again question of outsourcing. You are the one who is making it about semantics. In real world, I don't think there is any fundamental difference between a team working in a Microsoft building, vs. team in another company qualified by Microsoft to supply software. Both can make similar mistakes.Besides, MS has a long tradition of being completely unable to provide a safe operating system, and unable to provide firewall/virus protection for their own product (the need of which mostly stems from their own product design). 3rd party firewalls, virus protection etc. has been a thing for nearly three decades now.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 03:28:48 pm
content: Quote from: IanB on August 15, 2024, 02:23:16 pmNo, you can't, actually. Or at least not without jumping through some serious hoops. Firstly, it's your computer but it's not your OS: you have licensed it from Microsoft. Secondly, and more importantly, you would need to write your code as a driver, get it tested by Microsoft, and get it signed.**Ithinkthat's the process in outline - please correct me if I'm wrong.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 03:56:01 pm
content: Quote from: Siwastaja on August 15, 2024, 03:25:21 pmYes, I did go through that in my next post.The problem is simple: there is only one Microsoft, but there are an unlimited number of other software vendors out there. Of all of them, only Microsoft has an imperative to keep their OS, and especially their kernel, bulletproof. The other vendors have different shareholders with different priorities. The Windows kernel is not their code - it alters the dynamic.The best way to protect the kernel from bad code - even from Microsoft's own coders - is to restrict or prevent access to the kernel as thoroughly as possible.Quote from: Siwastaja on August 15, 2024, 03:25:21 pmActually I'm not sure you install something called "CrowdStrike" and do all that business you describe, do you? But even so, access to kernel mode is inherently dangerous, and MS are wise to reduce the need for such access as widely as possible. Ultimately, the author of the code is of secondary importance.You say MS "tried to do something about it". Well, sure, one of the things they tried to do was implement a new API which prevented any code using that API running in kernel mode. That is automatically a good thing. Hostile or incompetent, the best thing is to prevent it.I have no idea why MS apparently wanted to restrict access to only some vendors (vendors "like CrowdStrike", whatever that means). It sounds odd to me, but none of us know the full facts so we can't judge.Quote from: Siwastaja on August 15, 2024, 03:25:21 pmWhich misses my point. Blocking kernel mode protects the OS against mistakeseven from Microsoft's own coders.Yes, of course this new API might have bugs in it, but they can and will be flushed out as time passes. This is Microsoft's golden goose - it's in their interests more than anyone else's to protect it. There is one API, but presumably dozens or hundreds of products wanting to use it. It is obviously easier to nail down one API than to nail down hundreds of non-Microsoft drivers.Making the OS more resilient and secure against hostile or incompetent code is automatically a good thing. And that includes against incompetent code coming from Microsoft's own coders.

author: nctnico
author_rank: Super Contributor
timestamp: August 15, 2024, 03:57:54 pm
content: Quote from: SteveThackery on August 12, 2024, 04:14:53 pmTrue. And actually the problem is not whether using a language where you need to implement all the range checking yourself or a language which does it for you, the problem of how to deal with an error is the one to tackle.If you look at the OSI model for example (which was quite popular in the 1990's), you see there is absolutely nothing in the stack with layers which deals with error handling. However, when designing / implementing a communication protocol, the key element is how to deal with errors and how to do recovery.And then there is also the right place to pick for where to put error checking. A long time ago one of my employers sub-contracted development of a large machine. One day we heard the loud bang and the building was shaking.Turned out the machine ran beyond it's limit switches and crashed into itself. So the internal software engineering team was send out to investigate what the contractor was doing. It turned out the contractor had mixed safety features with regular code. And due to putting a few remarks here and there for a test, the safety features got bypassed as well. The contractor had a bad day for sure.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 04:04:02 pm
content: Quote from: SteveThackery on August 15, 2024, 02:10:56 pmNo, that is exactly how anyone with any clue of IT security thinks about this. A vulnerability is something that allows unauthorized parties to interfere with a system. The fact that the owner of a computer can "compromise" their own computer is not a security problem. And really, it is nonsensical to call it a "compromise", because by definition, the computer doing what the owner commands it to do, is not a compromise. A compromise is when the computer does what an unauthorized party commands it to do. "Third party software" is simply not a category that is of any relevance here, whatever that even means.Also, it is completely arbitrary that you pick out the user/kernel space boundary as the special case. When you have all your important business data in one user account without backups, say, then any old batch script running with the privileges of that user account can delete it all and thus ruin your business. Does that mean that the fact that you can "run third-party batch scripts" is a security vulnerability?It is a vulnerability if a process that runs with user privileges can run arbirtrary code in kernel mode, because granting the user privileges does not authorize the user to do such a thing. But it is not a vulnerability if the owner/admin can run arbitrary code in kernel mode, because they are authorized to do so. And also, it's just a nonsensical goal to prevent this, because, obviously, the owner/admin can access all the data anyway, and they can just put the machine in a shredder, for that matter, so it's not like you can prevent the owner from damaging their system, or from using the data on the system in whatever way they like.Quote from: SteveThackery on August 15, 2024, 02:10:56 pmNo, I don't, I never cared about Windows much to know anything much about its history.But regardless, did you notice how you didn't say that that was a vulnerability? Because it wasn't. What it was (based on your description of the situation here) was an architecture that made vulnerabilities in drivers a bigger problem, because it allowed those vulnerabilities to be used to gain more privileges than they would with a different architecture.Also, mind you that there is a difference between providing infrastructure that mitigates exploitation of vulnerabilities for people to use and forcing people to use it/preventing people from doing things differently. The latter is the sort of thing that competition authorities are concerned with, the former not so much. Though they might be concerned with the former, too, but also for reasons that have nothing to do with the usefulness or quality of a product, but only with market behaviour, namely, when the former happens to be a thing that competes with products from other vendors, and you bundle your version of it with another product in such a way that the other vendors are left without a market, because you force your customers to buy your version of it, rather than selling it as a separate product that then has to compete with other offers.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 04:23:14 pm
content: Quote from: SteveThackery on August 15, 2024, 03:17:17 pmNo, I certainly didn't, because it is a nonsensical distinction in this context.Quote from: SteveThackery on August 15, 2024, 03:17:17 pmBut that was not the situation here. It wasn't "someone with hostile intent". It was the authorized owner of the machine. That is exactly why it is not a vulnerability.Noone could run code in kernel modewithout the authorized owner of the machine auhtorizing this to happen.Quote from: SteveThackery on August 15, 2024, 03:17:17 pmIt is already impossible. Noone can run code in kernel mode on your machine without your authorization. So, if you don't want code to run in kernel mode, then don't run code in kernel mode, noone is forcing you to. What you are arguing about here is whether Microsoft should forceother peopleto not run code in kernel mode, because you somehow think that your system is vulnerable due to the fact thatother peoplemight run code that you consider too risky to run on your own machine. For you to not run that code on your machine, you don't need Microsoft to force you, you can simply not do it.Quote from: SteveThackery on August 15, 2024, 03:17:17 pmNo, that is not in any way obvious. You are constantly making the completely unsubstantiated assumption that Microsoft is the most competent company to build kernel mode code. Without that assumption, your argument makes no sense at all.Like, obviously, Microsoft could build this API that handles hooking into the system in a way that products like CrowdStrike need, and build it with the goal of making it hard to compromise or crash the system via that API. That is obviously just a kernel-mode driver written by Microsoft, right?Now, obviously, other companies besides Microsoft could also build such a kernel-mode driver with the same goal, right?Now, why do you think that Microsoft's will necessarily be the best and no other vendor could do it better? Or, if that is not what you think, then why should Microsoft be allowed to prevent competitors from selling their superior product to customers?And note, again, that noone is preventing Microsoft from selling their own solution, or preventing you from buying Microsoft's solution. So it is irrelevant that you would prefer to use Microsoft's solution, because noone is preventing that. All this is about is whetherother peopleshould be prevented from selling and buying alternative solutions, and you so far have failed to support that demand.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 04:31:03 pm
content: Quote from: SteveThackery on August 15, 2024, 03:56:01 pmSo, you are saying that Microsoft is the only company that has an interest in keeping their customers secure? Can you substantiate that in any way?Quote from: SteveThackery on August 15, 2024, 03:56:01 pmYou are, again, confusing concepts.Software security is about preventing accidental privilege escalation.Competition authorities are concerned with intentional privilege escalation.That is the difference between authorized and unauthorized access. It is, generally speaking, perfectly fine for Microsoft to provide mechanisms that software can use to preventaccidentalprivilege escalation, i.e., to mitigate the risks of vulnerabilities. What is not fine is Microsoft preventing the authorized owner of a system fromintentionalprivilege escalation, i.e., when the owner of a system intentionally installs a kernel-mode driver.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 04:41:56 pm
content: Quote from: zilp on August 15, 2024, 04:04:02 pmI didn't say anything about a special case. It is one of the most important cases because it provides a back door to the OS, with the ability to steal data, corrupt data, inject a virus, crash the OS, send DDOS packets, etc. It is a particularly important vulnerability to address for those reasons. And crucially, this can happen without the owner giving permission or knowing it's about to happen.Quote from: zilp on August 15, 2024, 04:04:02 pmI don't think you can protect against that sort of thing because the user might legitimately want to delete all their data. I don't think this is a useful analogy becauseunlike the OS, those data files belong to the user and they can do whatever they want with them. It is Microsoft's job to secure the OS. It is the user's job to secure their own data. This is widely known and accepted (hence the exortations to backup, backup, backup).Just because a user can destroy their own data, it doesn't mean the OS shouldn't protect itself from corruption or destruction. As I said, the data belongs to the user, but the OS belongs to Microsoft, and I want them to make it as bulletproof as possible. With the possible exception of yourself, pretty much everyone else on the planet would agree. When MS is found not to do that, they get strung out to dry.Quote from: zilp on August 15, 2024, 04:04:02 pmAre they? Who authorises it? I might be wrong, but I don't think anyone can run arbitrary code in kernel space. I think the only way to do that is to write a driver, get MS to test and green-light your code, then get it signed.I'm afraid I didn't understand the rest of your post so I won't try to respond to it.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2024, 05:01:07 pm
content: Quote from: SteveThackery on August 15, 2024, 03:28:48 pmNot really. You can only do with it what Microsoft allows.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 05:03:57 pm
content: Quote from: zilp on August 15, 2024, 04:31:03 pmYou naughty person! Putting words into my mouth is a sure sign of desperation. Even when it's by inference. Because I'm a nice guy, I will respond constructively, but don't do it again, OK?What I said is that Microsoft has more incentive than anyone else to keep theirOSsecure. I didn’t mention customers in that part of my argument. Also, it only has to secure that open doorway once, and it will remain closed against the dozens or hundreds of products using that API. That is clearly better than trying to bulletproof hundreds of said products.There is no case for leaving this doorway open.The anti-competitive argument is aboutMSrestricting access to the new API, and that is quite a different matter. It sounds wrong to me (as it did to the regulators), but none of us know the full story on that.Quote from: SteveThackery on August 15, 2024, 03:56:01 pmQuote from: zilp on August 15, 2024, 04:04:02 pmWay to miss the point!Anyprivilege escalation - intentional or unintentional - renders the OS vulnerable to damage because nothing can stop the elevated code from stomping over the OS. That's why the OS runs in kernel mode - to protect it.Anything that reduces the need for privilege escalation is a good thing.That's what that new API was intended to do.Let me be clear: I don't know enough about why MS wanted to restrict access to that API. I am not defending it; it sounds dodgy to me.I am defending any steps which reduce the need for privilege escalation.That is the key takeaway, and it is something every OS owner would agree with.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 05:05:06 pm
content: Quote from: NorthGuy on August 15, 2024, 05:01:07 pmThat was my point, although I would repeat: the computer belongs to you; the OS belongs to Microsoft.

author: IanB
author_rank: Super Contributor
timestamp: August 15, 2024, 05:13:38 pm
content: Quote from: SteveThackery on August 15, 2024, 04:41:56 pmOf courseyoucan run kernel mode code onyourcomputer atyourdiscretion, if you want to. You just download the appropriate developer tools, SDKs and debugging tools from Microsoft and code away. Now, of course, all the tutorials exhort you to run and debug the driver remotely on a dedicated test machine or VM, and not on any machine you care about, but if you choose to disregard such advice, that's your funeral.If you want to, you can also share the driver you write with friends and colleagues to run on their machines too. You just need to give them a copy of the test certificate you created for it. And of course, they need to trust you before they install and run such a driver.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2024, 05:42:33 pm
content: Quote from: IanB on August 15, 2024, 05:13:38 pmYou need to disable secure boot and enable test signing mode. At some point, new computers will appear where it may be impossible to disable secure boot. Then you won't be able to do so anymore.

author: IanB
author_rank: Super Contributor
timestamp: August 15, 2024, 05:55:03 pm
content: Quote from: NorthGuy on August 15, 2024, 05:42:33 pmThis is an electronics forum. If I cannot design and construct a hardware peripheral for my computer, and then write a driver for it, then my computer will have become useless for that purpose and I will have to use another OS instead.Also, how is anyone supposed to write a driver in the first place and get it signed, if there is no way to test and debug it?

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2024, 06:20:53 pm
content: Quote from: IanB on August 15, 2024, 05:55:03 pmI don't know. For Mac you need an Apple account and you need to register your Mac with apple, then you can run your driver on this Mac (and on this Mac only). And Mac's drivers are user-mode now.I guess Microsoft may come up with something as well. It's only get harder and harder to write drivers with time. It is silly to expect any improvements in this area. It can only get worse. The Crowdstrike accident may give rise to a new wave of driver policies hardening.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 06:39:59 pm
content: Quote from: SteveThackery on August 15, 2024, 04:41:56 pmNone of those, with the exception of crashing the OS, is specific to kernel mode. Which is why I said what you quoted. Every batch script can steal the data that it has access to.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmIt still is not a vulnerability, because no unauthorized access is possible.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmSo, Crowdstrike can be installed on a system without the owner giving permission? Or what?Quote from: SteveThackery on August 15, 2024, 04:41:56 pmI didn't ask whether you can protect against that, I asked whether that makes it a vulnerability, because it fits the definiton that you gave for what makes a security vulnerability a security vulnerability.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmThat's a pretty wild claim. Especially so given that I am not the only person who runs an operating system where you can edit all of the source code, recompile it, and run it. And all of those people obviously don't think that that means that open operating systems are a security vulnerability. Because we tend to use a sensible definition of vulnerability, as I have explained repeatedly.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmThe owner of the computer, by installing/executing that code.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmI think that is roughly correct. But that doesn't mean that Microsoft is allowed to just arbitrarily decide which code they sign. Because it is, after all, not their computer.Quote from: SteveThackery on August 15, 2024, 04:41:56 pmWhat specifically was unclear? Because it seems like that is actually the important part, in that you keep bringing up stuff that is simply irrelevant to matters of competition law.

author: Marco
author_rank: Super Contributor
timestamp: August 15, 2024, 06:55:48 pm
content: Lets examine for a moment exactly why Mx Mac's don't have third party kernel drivers any more, it's not because they have a microkernel with isolated drivers ... they simply have no third party hardware which pushes enough data to suffer from context change any more.So lets make everything vertically integrated and giant monopolies of a scale even the old Microsoft couldn't touch! That's great!PS. lets not forget about the time when in Apple's great wisdom they decided they want to do an online certificate check where a certificate revocation list with delta updates would work just fine and completely screwed it up.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 07:17:27 pm
content: Quote from: SteveThackery on August 15, 2024, 05:03:57 pmI certainly didn't intend to.Quote from: SteveThackery on August 15, 2024, 05:03:57 pmOK ... secure from what? And why would that be in the interest of anyone other than Microsoft?I mean, I assumed that you meant some form of security that is in the interest of the customer, because "security" that prevents customers from doing what they want to do with their property in order to serve the interests of the manufacturer obviously is not in any sensible meaning of the word "security" as used in this thread.Quote from: SteveThackery on August 15, 2024, 05:03:57 pmOK, maybe? But you haven't explained why Microsoft should be the vendor that gets given the privilege of building this one solution that everyone else has to use. Why shouldn't some other company that is better at it get the chance to build it?Quote from: SteveThackery on August 15, 2024, 05:03:57 pmThere obviously is, and I have made it repeatedly in this thread: The fact that you haven't demonstrated that other vendors wouldn't provide a better solution for securing the doorway.Quote from: SteveThackery on August 15, 2024, 05:03:57 pmNow, I don't know the actual facts, either. But it's not really difficult to guess, I would think. Because your assumption that not allowing random vendors to write their own kernel modules would actually solve a problem makes no sense, even if we assume that Microsoft is exceptionally good at building their API, noone else could do it better, and the API could do everything the competing "security" vendors need. Because the whole point of those "security" solutions is that they have access to everything that matters. The whole point is that they can see everything every process on the system does, and all the data that they access, and all the network traffic, and that they can intervene in operations that are recognized as suspicious. That API would provide access to all of that anyway. The most you can achieve this way is that maybe the kernel doesn't crash, but that is of barely any value to the user, because you can make the system completely unusable even if the kernel has not crashed.So, obviously, Microsoft is aware that handing out access to this API instead of allowing kernel-mode drivers wouldn't actually help their customers in any relevant way. And so, they then got the idea that they only hand access to companies that they trust ... or so they claim.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 07:36:42 pm
content: Quote from: SteveThackery on August 15, 2024, 05:05:06 pmIt's just that ... it doesn't.Microsoft has the copyright. That's it. Now, you can call that "belongs to" in some context. But that doesn't mean that all the others meanings of "to belong to" also apply. And having copyright of a particular piece of software does not mean that you have a right to do with the data that is being processed by that software whatever you want, nor that you are allowed to prevent people from interoperating with it, nor that anti-trust laws don't apply to you, nor anything much, really. It first and foremost means that other people aren't allowed to create and distribute copies of it, that's it.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2024, 08:09:11 pm
content: Quote from: SteveThackery on August 15, 2024, 05:05:06 pmThe computer may belong to you in a sense that you can sell it or destroy it. However, you gave up all the control over your computer to Microsoft - they posses it and you must obtain their permission for anything you want to do. They also have full access to your data and any software that is located on your computer. In that sense, your computer belongs to them.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 09:05:29 pm
content: Quote from: zilp on August 15, 2024, 06:39:59 pmYes, I think so. Isn't it a technology that is licensed to the vendors of other security products? I've had a look at their website and there doesn't seem to be any sort of application that I can actually buy. I think it gets incorporated into other products.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 09:11:13 pm
content: Quote from: NorthGuy on August 15, 2024, 08:09:11 pmI think you are stretching the definitions of "possess" and "belong" somewhat. Microsoft owns the OS and you buy a license from them that allows you to use it, within the terms and conditions of the license.But you absolutely do own the hardware and your own data. You can vape the hard disk, you can add an ext3 drive, you can install a different OS, if you like. You don't need Microsoft's permission for anything other than what is specified in the license.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 09:22:35 pm
content: Quote from: zilp on August 15, 2024, 07:36:42 pmNo, that's wrong. Yes, Microsoft has the copyright, but it's more than that. Microsoft sells you a license to use their OS, and that license contains various terms and conditions which you agree to when you install the OS, or use it for the first time. If you then fail to observe those terms, Microsoft is legally allowed to prevent you using their software. None of this is controversial - pretty much all commercial software has similar terms and conditions.Quote from: zilp on August 15, 2024, 07:36:42 pmWe agree on all of that except for the last sentence. That isn't "it". Microsoft owns the copyright AND you buy a license to use it from them, which means you agree to various legally enforceable terms and conditions. (Legal in the sense that MS can withdraw your right to use their OS).

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 15, 2024, 09:23:06 pm
content: Quote from: SteveThackery on August 15, 2024, 09:11:13 pmYou can vape the hard disk, but if you use any online MS account at all, your data is going to end up one way or another on MS servers.Regarding the license, do you actually have any accurate idea of what it entails?Like"It's ok, everything is specified in the license agreement. There is no trap here.- Have you read it?- Uh, no."

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2024, 10:09:05 pm
content: Quote from: SteveThackery on August 15, 2024, 09:11:13 pmI didn't say they do it illegally. You give them the full control of your computer and data voluntarily. According to the license.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 10:14:02 pm
content: Quote from: zilp on August 15, 2024, 07:17:27 pmSecure from inept or hostile software that could damage the OS, obviously.And as for your second sentence, that is exactly my point! Microsoft has much more at stake when it comes to the stability and security of Windows than any other software vendor, so it cannot simply rely on on all those vendors being honest and competent. Only Microsoft is responsible for the security and stability of Windows, nobody else. That is why it wants to take steps to protect the OS from hostile or incompetent applications. And one of the most powerful tools at their disposal is to reduce as far as possible the non-Microsoft code running in the kernel space. (In fact, even their own code, because anyone can make mistakes.)Quote from: zilp on August 15, 2024, 07:17:27 pmRestricting access to kernel modeisin the interest of the user, because code running in kernel mode can corrupt or even steal the user's data. That is why the OS blue-screens: it is to protect the users data by halting execution.Quote from: zilp on August 15, 2024, 07:17:27 pmBecause the function of an OS is to provide a range of services to applications in order that they can do their job, whilst at the same time taking all possible precautions to protect the user's data. The OS belongs to Microsoft, so it is their job to deliver that. The model is the same across all operating systems: all operating systems provide a suite of APIs. The OS vendor owns the APIs and everything behind them; the application writers write their code to interact with those APIs. This model is universal and has been for decades.If "some other company" thinks they can do a better job, they are welcome to write their own OS. As it happens, for reasons of expedience, Microsoftdoesallow breaches in their APIs, and the CodeStrike disaster is a perfect illustration of why it's a bad idea. I repeat: it is obviously easier to nail down the OS - once and properly - than to rely on every application vendor being sufficiently honest and competent to nail down their own apps. There are hundreds of them, and new ones come along all the time.Whenever Windows blue-screens Microsoft is blamed, and rightly so. It is Microsoft's responsibility to protect their OS from damage, not some other vendor. In the recent case, it appears that Microsoft's effort to improve the protection never got implemented due to some regulatory issue.I get the impression you aren't aware of the architecture of modern operating systems, and especially the concept of the API: I will repeat: the OS presents the APIs to the applications, and the applications make calls to the APIs to make stuff happen. The APIs act as the boundary between the OS and the applications. The APIs and the code behind them belong to the OS vendor. The OS vendor is responsible for making those APIs and the OS behind them secure against damage by the applications. The application writers are responsible for ensuring their code is bug-free and, in particular, never damages the user's data. The recent disaster shows the risks involved in not strictly observing that model.I think at this point I have adequately covered the remaining points in your post, so I will stop here.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 10:29:27 pm
content: Quote from: SiliconWizard on August 15, 2024, 09:23:06 pmSome of it - it depends on how much you put one OneDrive. I've lost track of what the relevance is, though. The data is yours, despite being on Microsoft's servers. Microsoft has agreed to provide a particular service - synchronisation and backup - as part of the license that you have agreed to, but that doesn't change the legal ownership of the data, just as it doesn’t change the legal ownership of the OS.Quote from: SiliconWizard on August 15, 2024, 09:23:06 pmI've deleted the sarcasm because we are adults having a respectful conversation. Re. the license: I've read most of it; not all of it, and not recently. But that isn't important: it's the concept of software licenses that I was explaining. As I said, the software remains the property of the vendor; the license permits use of the software, but in compliance with the various terms and conditions set out in the license. Again, this is standard fare throuout the industry, even open source software. The ownership and responsibilities are clear.If you don’t agree to those terms, the owner of the software has the right to stop you using it. And you are always free to use some other software. Including some other OS, of course.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 10:35:09 pm
content: Quote from: SteveThackery on August 15, 2024, 09:22:35 pmThat's mostly incorrect in the EU. If you buy a computer with Windows pre-installed, for example, then whatever "license" that is displayed on first use is just irrelevant. You gained certain rights to use the software as part of the purchase contract, and one party can't just impose additional contract terms after the fact.Quote from: SteveThackery on August 15, 2024, 09:22:35 pmWell, for one, that's not necessarily true, see above. But also, there are quite a lot of laws that limit what kinds of terms are enforceable in license agreements.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 15, 2024, 10:43:11 pm
content: I wouldn't argue with you about the complicated legalities of software licenses!My only interest was to explain that no, youdon't ownthe OS. You buy a license to use it (which comes with certain terms and conditions). In fact, you don't own any of the software on your PC unless you wrote it yourself. All software is licensed.I do feel we have overworked this aspect of the discussion, because it isn't really on topic. The OP was wanting to discuss the lessons that could be applied in the domain of microcontrollers. See my extraordinarily insightful and erudite essay in reply #82.https://www.eevblog.com/forum/microcontrollers/is-there-something-to-learn-for-embeddediot-from-the-crowdstrike-disaster/msg5602391/#msg5602391

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 11:26:46 pm
content: Quote from: SteveThackery on August 15, 2024, 10:14:02 pmThat's still incoherent nonsense.Code running in user space can also corrupt or steal the user's data, so that doesn't have anything to do with kernel mode or not.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.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmSo, only Microsoft should be allowed to provide application software for Windows?I mean, this is so incredibly vague that I don't see how that even allows to distinguish between what would fall under this and what wouldn't. Nothing of this explains why this should only apply to kernel mode code.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmNow, this is just complete and utter bullshit.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.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmWell, I have explained at length why this is nonsense, so I won't repeat myself here.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmIf 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. It's a pretty insane view, really.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmThat's pretty much just wrong.For one, an "API" is just any interface between software components and has nothing to do with privilege boundaries per se. You average library also has an API, but it's mapped into your process address space, so there obviously is no privilege boundary, and no expectation that anything prevents corruption of the library or its data structures if other code with in the process decides to do so.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.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.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.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.

author: zilp
author_rank: Frequent Contributor
timestamp: August 15, 2024, 11:32:55 pm
content: Quote from: SteveThackery on August 15, 2024, 10:43:11 pmNo, that is simply false. That is not how it works.And also, you are still using "own" as if that were one coherent concept. It isn't. In the legal space, there are all kinds of distinct legal rights that are colloquially called some form of "ownership", from physical property to financial debt to copy rights, trademarks, and patents.So, you can in fact own and not own software at the same time. You can purchase a physical copy of software, so you have physical property rights on that physical copy, so you own it. Which under the legal framework of the EU automatically also includes the right to use that software. But at the same time, you possibly don't have the copyright on that software, so you don't own it in that regard.But then, also, almost all of the software on my PC is software that I don't have the copyright for, but that I still am allowed to use and modify and copy and distribute as much as I like, as a result of the licenses. So, in some way, I don't own it, in that I don't have the copyright. But then again, there is pretty much no restriction on what I can do with it, so in practical terms, it is pretty close to some sort of ownership anyway.So, really, talking about "ownership" of software without being specific is pretty useless and only will lead to confusion.

author: Marco
author_rank: Super Contributor
timestamp: August 16, 2024, 07:34:49 am
content: Interoperability exemption means you can even bypass integrity mechanisms to distribute kernel level code if you want ...

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 09:52:16 am
content: Quote from: zilp on August 15, 2024, 11:26:46 pmIt'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.Re. your last sentence, I think I have donenothing butjustify why apps are best kept away from kernel mode.Quote from: SteveThackery on August 15, 2024, 10:14:02 pmEh? I said only Microsoft should be allowed to provideOS services and APIs. The application software - running in user mode - is open to any provider.Quote from: zilp on August 15, 2024, 11:26:46 pmThat'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.Quote from: zilp on August 15, 2024, 11:26:46 pmAs 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'tmyauthoritarianism.Quote from: zilp on August 15, 2024, 11:26:46 pmIt IS a privilege boundary between theapplicationsand the kernel (the owner only owns the hardware, remember). When that boundary is breached, disasters like CrowdStrike become more likely. CrowdStrike wasnottrying 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.Quote from: zilp on August 15, 2024, 11:26:46 pmYou 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.Quote from: zilp on August 15, 2024, 11:26:46 pmReliability and user access enforcement are both important and enhanced by keeping apps away from kernel mode as far as possible. You certainly cannot add kernel mode code to the Windows kernel unless you jump through the hoops mentioned earlier. 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.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.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.Quote from: zilp on August 15, 2024, 11:26:46 pmYour 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.

author: Marco
author_rank: Super Contributor
timestamp: August 16, 2024, 11:55:45 am
content: I'm fairly sure Apple's GPU and nvme drivers run in kernel mode.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 12:00:02 pm
content: Quote from: Marco on August 16, 2024, 11:55:45 amThey do indeed, as do Windows video/graphics drivers.But these are drivers, not applications, and Microsoft and Apple both employ rigorous testing, certifying and signing regimes to these drivers before they can be installed. That's because Apple and Microsoft know that code running in kernel mode has vastly more ability to destroy data and crash the OS.

author: Marco
author_rank: Super Contributor
timestamp: August 16, 2024, 04:58:51 pm
content: There's WHQL, but both Microsoft and Apple (before they just first partied all important hardware) let developers sign their own drivers.

author: zilp
author_rank: Frequent Contributor
timestamp: August 16, 2024, 05:37:43 pm
content: Quote from: SteveThackery on August 16, 2024, 09:52:16 amWhat 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amYes, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amYeah, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amWell, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amThat's just missing the point, though? Customersaredoing 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amNo, I don't remember, because I never thought that in the first place, because it is nonsense, as I have explained at length.Quote from: SteveThackery on August 16, 2024, 09:52:16 amWhich 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amYour point being?Quote from: SteveThackery on August 16, 2024, 09:52:16 amNo, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amGenerally, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amWell, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amYeah, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amNo, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amNo, 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.Quote from: SteveThackery on August 16, 2024, 09:52:16 amIt'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.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 05:49:22 pm
content: Excellent and interesting reply - thanks, @zilp.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 06:09:51 pm
content: As I work through it, I am struck by how we seem to be talking past each other. You keep saying my arguments are irrelevant or non sequiteurs. But when I read your own posts I am struck by what seems like a "stuck" mindset that can only think in one way ("This is how I do it in Linux, so that's how it should be for everyone and all OSs").We both think our arguments are simple, clear and valid, and yet we shout straight past one another.Before doing a proper reply, I'm going to pause and spend some time trying to understand why we have so far failed to communicate.Once again, thanks for taking the time to write such a comprehensive post.

author: zilp
author_rank: Frequent Contributor
timestamp: August 16, 2024, 08:51:24 pm
content: Quote from: SteveThackery on August 16, 2024, 06:09:51 pmIrrelevant arguments or non-sequiturs are fallacies. "Being stuck" is not. I would assume that you are stuck on the position that 1 + 1 equals 2? Does that mean that there is some problem with that position?Also, what I think how things should be done is irrelevant for whether your arguments contain logical flaws. The point of explaining how things work with Free Software is to demonstrate how one can achieve the goal that you supposedly want to reach without the measures that you claim are necessary to reach them, and how what you claim to be universal views are obviously not actually universal views, because it would follow from those that users of Free Software consider their systems to be insecure ... which they usually, rather unsurprisingly, don't.Quote from: SteveThackery on August 16, 2024, 06:09:51 pmYou are welcome--and I am curious what conclusions you are going to come to :-)

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 10:01:08 pm
content: Quote from: zilp on August 16, 2024, 08:51:24 pmWell obviously I don't think my arguments are irrelevant or non-sequiteurs!I think they are clear, simple and incisive. For my part I think you are too stuck in your ways to properly embrace an alternative point of view. I strongly suspect you have just skim-read my posts withoutreally thinkingabout what I'm actually saying.But let's not do this - criticising each other is not at all helpful and it just leads to unpleasantness and upset feelings. Feel free to take another pop at me (I know you want to), but after that we should stop.Right now I'm trying really hard to understand your arguments, including doing some background reading on Linux (I only write Windows applications). There'll be a slight pause, but I will get back to you.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 16, 2024, 11:44:47 pm
content: One point that we could clarify is this:Quote from: zilp on August 16, 2024, 08:51:24 pmYou frequently refer to owners/admins, and I'm not totally sure what that means. To you, it seems to mean an individual with complete access to all aspects of the OS, a deep understanding of how it works, who can write and run code that operates in user space or kernel space, and, crucially, is willing to take responsibility for all consequences of their actions. It is an intimate relationship between the owner/admin and the OS, with no secrets between them.Now, this isn't remotely like 99% of the Windows users that I have ever known. Most Windows users have only the vaguest awareness of what Windows is and does. They don't know what an API is, they've never written a line of code, and they have no knowledge of user space and kernel space. What they see is the email app they use every day, the social media apps they use every hour, and some of them know how to use powerful applications like Microsoft Office. Some of them understand the hierarchical nature of the filing system; others don't and just save files to wherever is the default for the application (usually just piling files up in 'Documents').So one thing I'm hoping you will recognise is that the great majority of these people are not remotely like the "owners /admins" you describe in the world of Linux. They are just users who really only care about the applications. To them, the OS is what provides the Start menu, the File Manager, and a nice picture on the desktop.These are the people who form the great majority of Microsoft's customers. Obviously there are others: admins who are responsible for supporting dozens or hundreds of PCs in an organisation; programmers, who write applications that PC users will hopefully buy; and "power users" who like and understand computers and enjoy trying out different apps and spend ages in the "Settings" app, fine-tuning the transparency of the Taskbar.Can you at least acknowledge that the 99%* of Windows PC users are very different from the owners/admins you describe in the Linux world? I hope so - you only have to walk into any busy office and you will see a room full of them.A simple yes or no would suffice at this stage.*Let's not quibble about whether it is 99% or 95% - I'm sure you get my point.

author: IanB
author_rank: Super Contributor
timestamp: August 17, 2024, 01:12:31 am
content: Quote from: SteveThackery on August 16, 2024, 09:52:16 amI really don't agree with the point you keep trying to make at all.The CrowdStrike disaster occurred because professional system administrators installed software on critical machines across organizations, without doing sufficient due diligence, and without establishing the required level of trust in the software. They did not (apparently) demand to see the test, verification and quality assurance procedures employed by the vendor, and they did not (apparently) verify for themselves that such procedures were satisfactory before purchase. They paid the price as a result.Nobody was forced to deploy the faulty software, and it was not installed silently, or by any surreptitious means. The organizations affected voluntarily shot themselves in the foot.Bear in mind that the software was deployed by corporate IT departments, people who are supposed to be informed and knowledgeable professionals, people who are supposed to know what they are doing.

author: radiolistener
author_rank: Super Contributor
timestamp: August 17, 2024, 01:42:57 am
content: Quote from: zilp on August 15, 2024, 04:23:14 pmWindows become a system for not smart peoples who don't understand and don't want to understand what they want. They just want to provide their machine to be used by MS software and will be happy with all crap that they receive.If you want to control your system, you definitely needs to use different OS which is designed for peoples who understand what they want and don't need MS control on all what they doing on computer.If you use Windows, don't surprise that your computer doing things that you didn't asked and be ready to allow that MS dictates the rules of what and how you should do on your PC...Just look, first you selected OS which is designed to use your PC without your consent and enforce you to do things that you don't want. And then you complain that it works not as you want. This is strange, if you don't want it and don't like it then why you choose it?The same thing with Android. Such kind of software is designed for not smart peoples who don't want to learn or understand something. They just want to give full control on their PC/smartphone to MS or G, and allow them to use it as MS/G wish. All what they expect in response is just to get some service from these companies and even ready to pay for that.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 17, 2024, 07:21:15 am
content: Quote from: radiolistener on August 17, 2024, 01:42:57 amWhile this is probably... kinda-sorta... true-ish, remember now we are talking about IT administration departments of some massive mega corporations - banks, airlines, and so on, who use Windows on their critical server infrastructure, not end users of consumer PCs. That is -ifyou are right in what you say, it's actually quite sad, and very alarming.

author: madires
author_rank: Super Contributor
timestamp: August 17, 2024, 09:54:41 am
content: Absolutely! When you're forced to be a Microsoft junkie you pray that the next monthly update won't cause too much trauble, and that nobody clicks on something malicious.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 10:09:08 am
content: Quote from: SteveThackery on August 16, 2024, 11:44:47 pm@zilp:although I have had a bit of fun describing the types of Windows users, I hope you will agree that my descriptions are broadly valid, and in particular nothing like the Linux "owner/admin" you frequently refer to.My next question is another yes/no question. Do you agree that a BSOD is a pretty serious inconvenience for these users? That when a BSOD happens, most of these users would have no idea how to fix it? Even for system admins, it's a major ballache?And in addition, do you agree that BSODs, especially widespread ones like CrowdStrike, reflect very badly on Microsoft (whether fairly or not)?You will obviously see where I am going with this.....

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 10:20:48 am
content: And now my third question for@zilp: do you agree that Microsoft would be wise to make Windows as crash-proof as possible? That BSODs should, ideally, never happen? That is in the interests of both the user and Microsoft that BSODs don't happen?I'm not going for the big reveal, here: I'm just setting out a very simple and transparent principle which I hope is obvious, and obviously desirable.

author: zilp
author_rank: Frequent Contributor
timestamp: August 17, 2024, 10:32:05 am
content: Quote from: SteveThackery on August 16, 2024, 10:01:08 pmWell, I guess so? But they still are!Quote from: SteveThackery on August 16, 2024, 10:01:08 pmNo, I fully understand what you are saying. But your conclusion does not follow.Quote from: SteveThackery on August 16, 2024, 10:01:08 pmI mean, feel free to read up on Linux, I guess, or even on Free Software in general, but really, the relevant points to this discussion are that Free Software comes with all the source code and a license that allows you to read, modify, and redistribute it all, which obviously flies in the face of any idea of "the vendor" preventing you from running kernel mode drivers, because it obviously is impossible for "the vendor" to prevent you from doing so if you can just edit and recompile the kernel, and if anyone is allowed to redistribute modified versions, and the fact that, obviously, people running Linux, FreeBSD, or OpenBSD servers, do not consider their systems to be insecure, even though nothing prevents them from running any kernel-mode code whatsoever if they wanted to.

author: zilp
author_rank: Frequent Contributor
timestamp: August 17, 2024, 11:12:13 am
content: Quote from: SteveThackery on August 16, 2024, 11:44:47 pmNo, I just mean the person who has the property rights to the machine. Their qualifications are not relevant. I just write owner/admin because in practice, often, the owner is a corporation, which obviously can't act unless a human acts for it, which usually would be the responsibility of an IT administrator.Quote from: SteveThackery on August 16, 2024, 11:44:47 pmWhile that is all true, mind you that the context that this thread is about is software bought by corporations and installed by IT administrators, who should be expected to have a deeper understanding of how their IT systems work than your average end user.Quote from: SteveThackery on August 16, 2024, 11:44:47 pmYeah, that's all true--and irrelevant.Let's do a car analogy: 99% of car users have no idea how a car works in detail or would be able to repair one if it breaks down. Also, working on a car can be dangerous if you don't know what you are doing.Your suggested solution: Have car manufacturers put a lock on the engine hood that only they have the key to and force car owners to buy all repairs from the manufacturer, because that's the only way to keep people safe. And your "proof" is that you point to one independent repair shop that screwed up a bunch of cars.And that's a non-sequitur. People can refrain from repairing their own car without being locked out of it, so it doesn't follow that you have to lock them out to keep them safe. And it doesn't follow that because some people are incompetent at repairing cars, that therefore, the manufacturer is best at it. It also doesn't follow that because you can show someone who repaired cars incompetently, that therefore, the manufacturer is best at it. As can be seen with the large number of independent repair shops who do employ competent people and often offer better service than the manufacturer. And it follows even less that the manufacturer would be best under monopoly conditions, given that they aren't even necessarily the best when confronted with competition ... what motivation would they have to offer the best possible service when you have no other option anyway? And not to forget the effect on prices when there is no competition.And, not to forget: If people feel safest to have their car repaired only by the manufacturer, that still does not require that the manufacturer puts a lock on the hood. The existence of competing independent repair shops does not prevent anyone from only having their car repaired by the manufacturer.There simply is no logical connection between "crashing cars can be dangerous" and "therefore, the manufacturer should be allowed to force their customers to buy all repairs from them". And equally, there is no logical connection between "crashing operating systems can be dangerous" and "therefore, the manufacturer should be allowed to force their customers to buy all kernel drivers from them".This has nothing to do with the competence of the users. It doesn't follow that, because a user is incompetent, therefore, the product from Microsoft is the best. And it also doesn't follow that, because some user feels safest with only products from Microsoft, therefore, other people need to be forced to only buy from Microsoft, too. Those are plain and simple non-sequiturs. If a customer only wants to run Microsoft software, they can do so, it is not necessary to allow Microsoft to force their customers to use only Microsoft software in order to allow them to do that.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 11:29:43 am
content: Quote from: zilp on August 17, 2024, 10:32:05 amRight! And this isabsolutely nothinglike Windows works!!This, I am certain, is why you can't see my point of view - we are coming from such different places that we have almost no common ground to stand on for our discussion. With Linux, every app and the entire operating system is wide open and transparent, and literally anyone can do literally anything they like to any part of it. And obviously these individuals take full responsibility for their own actions. The people you describe can write and run any kernel mode software they like, in the full knowledge that their code can crash the OS if they make a mistake, or even deliberately crash it. So most of the time these owner/admins write the best quality code they can, and that means of course they don't consider their systems to be insecure! They trust their own code!But I repeat -nothing whatsoeverin the paragraph above applies to Windows.

author: zilp
author_rank: Frequent Contributor
timestamp: August 17, 2024, 12:00:00 pm
content: Quote from: SteveThackery on August 17, 2024, 10:09:08 amYeah, sure.Quote from: SteveThackery on August 17, 2024, 10:09:08 amI guess so? But the "fairly or not" is actually the critical part. Because PR interests of a corporation don't (and shouldn't) trump property and similar rights.To continue the car analogy from above: Imagine people started modding their cars of a certain model. Imagine further that somehow those mods caused accidents. Imagine further that many people would put the blame on the manufacturer of those cars, completely unfairly, because the accidents were unambiguously caused by the modifications. Do you think that it would therefore be acceptable or even desirable for the car manufacturer to put locks on the engine hood that prevent all independent modification of repair?Quote from: SteveThackery on August 17, 2024, 10:09:08 amI mean, I can guess, and so, maybe I have already answered the next step?Quote from: SteveThackery on August 17, 2024, 10:20:48 amBSODs should, ideally, never happen,unless the owner of the machine wants them to happen, in which case there is nothing wrong with them happening.Mind you, my disagreement is with forcing things on owners/admins, not with helping them prevent BSODs. Your position is that people should be prevented from causing a BSOD on their own machine even if that is what they want to do.Then, I'm not sure whether Microsoft would be wise to make Windows as crash-proof as possible, and I mostly don't care, because whether something is wise for Microsoft to do tells us nothing useful about whether we, as society, should allow them to do it. It is generally wise for corporations to establish as many monopolies as they possibly can. But it is rarely beneficial for anyone but that corporation and its shareholders. Mind you, we are talking about forcing owners/admins to do things a certain way, not about providing them with options.But also, and maybe more importantly, you would have to demonstrate that your proposed measure would in fact reduce the expected rate of BSODs. You have not even demonstrated that Microsoft's code for the same purpose ("the API") could not possibly have had the same bug. It doesn't automatically follow that because the code that was written by Crowdstrike was bad, that therefore, the code written by Microsoft would be better. And if the code isn't better, then your argument doesn't work.Quote from: SteveThackery on August 17, 2024, 10:20:48 amBut it isn't desirable to have authoritarian control of your IT systems by a global monopoly.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 12:26:31 pm
content: Quote from: zilp on August 17, 2024, 11:12:13 amAnd there we have it: your analogy falls at the first line becauseWindows is exactly like a car with the hood bolted down.You keep going on about how wrong that is, and how anyone should be able to get under the hood, modify things, even deliberately or accidentally break things. You claim that this level of access does not affect the integrity of the car. You might be right, you might be wrong, I really don't care! But the crucial point is thatWindows is not like that: Windows is a car with the hood bolted down.Microsoft has the keys to the hood and can do anything they want to it. They also lend the keys to carefully chosen third parties, but they always test what those third parties have done and only when everything seems OK do they let the third party install their new component to the engine. I believe this is almost identical to the way Apple works with MacOS.I am not trying to convince you that this is a good model! I am trying to explain that this is how Windows works. You or I don't have to agree with it. But it is what it is.If only you can open your mind to the fact thatWindows is just different(not necessarily better, not worse, but very different) from Linux, I am certain that you will see the validity of my arguments.Yes, my arguments are completely wrong and largely irrelevant to a Linux owner/admin like yourself.You have pointed that out countless times and I am obliged to take your word for it because you are a Linux expert.But we are talking about Windows: a car with the hood bolted down that only Microsoft can open, and anyone who wants access needs Microsoft's agreement.Yes, I know how difficult this is for you to stomach - you've made thatoh, so clear! But try to put aside how youthinkit should be, and please at least try to embrace how itactually is. Nobody gets the keys to the hood without Microsoft's agreement, and nobody gets to install anything under the hood without Microsoft (or Apple) approving it.At risk of putting too much reliance on an imperfect analogy, Microsoft has kitted out the cockpit with a wide array of controls (APIs)which they have designed and built, and which arethe only way the user* can interact with whatever is under the hood.* (and, breaking out of the analogy, applications)--------I think any reasonable person would answer my questions in the following way:1/ Do you agree that most Windows users have a limited understanding of what Windows is and what it does? And that most of them have never written a line of code? And most of them aren't interested in the workings of Windows, they just want to get their work done, their emails sent, their Facebook page updated? YES2/ Do you agree that a BSOD is a pretty serious inconvenience for these users? That when a BSOD happens, most of these users would have no idea how to fix it? Even for system admins, it's a major ballache? YES3/ And in addition, do you agree that BSODs, especially widespread ones like CrowdStrike, reflect very badly on Microsoft (whether fairly or not)? YES4/ Not a question, a statement: Windows is a car with the hood bolted down, and only Microsoft and its trusted partners can unlock it and make changes.My arguments are based on this clear, four-part foundation, which describes what Windows is, and how it gets used. It may seem a profoundly wrong model - objectionable, even - to@zilp, but that is the world of Windows.------Having laid that foundation, later on today I am going to review my earlier arguments and demonstrate how they are not "irrelevant" and "non sequiteurs" in the world of Windows. We need to stop talking about Linux now, becausewe are not talking about how Windows should be, but how it is.

author: zilp
author_rank: Frequent Contributor
timestamp: August 17, 2024, 12:45:44 pm
content: Quote from: SteveThackery on August 17, 2024, 11:29:43 amYeah. And this is just missing the point.You made some point above about how, supposedly, the security of operating systems is universally viewed.This is the demonstration that that is not the case.The view that you presented is particular to your corner of the world, and not universal.That this is absolutely nothing like Windows works is exactly the point that I was making. And that therefore, what you consider universal, is in fact not universal at all, but particular to Windows (and other proprietary systems), because there exists a whole world outside of that that views things very differently. Therefore, your appeal to your view as a universally accepted truth does not work, this supposedly universally accepted truth is nothing of the kind.Quote from: SteveThackery on August 17, 2024, 11:29:43 amThe only common ground that is needed for most of it is simply logic.Quote from: SteveThackery on August 17, 2024, 11:29:43 amThe latter is not particular to open systems. If you decide to install proprietary software, you still are fully responsible for that decision.Quote from: SteveThackery on August 17, 2024, 11:29:43 amNone of that addresses why it would be in the interest of Microsoft's customers to be prevented from buying certain kernel drivers from other vendors.You really should reflect on why it is so important to you that people who want to buy that driver from some other vendor should be prevented from doing so. You seem to be very focused on how many people might not want to bother with other vendors, how they are happy to buy everything from Microsoft, how they think that they get the best product if they buy everything from Microsoft ... but none of that is relevant for justifying why people who feel differently should be forced to also buy from Microsoft, which is what you are proposing. People who want to buy from Microsoft do not need to be forced, and for people who don't want to buy from Microsoft, those arguments don't apply.

author: zilp
author_rank: Frequent Contributor
timestamp: August 17, 2024, 01:11:37 pm
content: Quote from: SteveThackery on August 17, 2024, 12:26:31 pmBut it isn't. The whole premise of your contribution to this thread is that is isn't.The competition authorities in the EU have forced Microsoft to remove some of the locks/bolts/whatever.Your position is that this is bad and Microsoft should be allowed to bolt it all shut.And I am asking you to justify why they should be allowed to do that.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmNo, they can't. And the anti-trust laws are only one of many that limit what they can do with it. Or at least, what they can legally do with it.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmAll of this is also subject to anti-trust laws. They are not allowed to freely decide on the criteria.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmI mean, for one, I have already established that that is in fact not how it works.But also, the whole point of you writing in this thread was to argue about whether this model should be allowed, so it's kinda dishonest to now claim that you only wanted to describe how it works.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmIt just happens to be a false statement, because, by law, Microsoft is required to give certain parties access, whether they trust them or not. And you are proposing that that should be changed. And failing to justify this proposal.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmExcept it evidently isn't. If it were as you claim, then noone would have ever had the Crowdstrike driver installed, presumably, because Microoft wouldn't have allowed it. The fact that they did shows that that is not how Windows in fact does get used, because people do in fact voluntarily install software that Microsoft would not approve of. And it even demonstrates that at least a significant proportion of the people using Windows don't want the model that you are proposing either, because noone forced them to install Crowdstrike, and they did it anyway. So it is obviously absurd to claim that those people who completely voluntarily installed Crowdstrike would have preferred to not install it. If they had preferred to not install Crowdstrike, they would not have installed Crowdstrike.Quote from: SteveThackery on August 17, 2024, 12:26:31 pmYou haven't laid any foundations.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 01:41:49 pm
content: Quote from: zilp onTodayat 12:45:44 pmYou're doing it again and IDETESTbeing misquoted, having words put in my mouth, being deliberately misrepresented in order to win an argument.I NEVER SAID that it is important to me that people who want to buy a driver from someone else should be prevented from doing so!I explained that this is the way it works for Windows: kernel mode drivers can only be installed if they are from Microsoft or one of Microsoft's trusted partners (and they are tested and approved by Microsoft).These are FACTS. At no time did I ever say that policy is "important to me". It isn't! I was trying to explain why it's important to Microsoft!!Time and time again you have misrepresented my position in order to undermine my argument. Your repeated refusal to eventryto engage with my arguments, and now another blatant lie about what I said, is just too much. I'm out of here, and@zilp: if you are going to keep lying about what I said you can piss off.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 17, 2024, 01:46:11 pm
content: zilp, why are you wasting any time with this guy who produces a lot of unnecessary, incoherent, illogical and uninteresting wall-of-text?

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 01:47:59 pm
content: Quote from: Siwastaja on August 17, 2024, 01:46:11 pm@zilphas wiped the floor with me regarding word count!

author: Siwastaja
author_rank: Super Contributor
timestamp: August 17, 2024, 02:00:18 pm
content: Quote from: SteveThackery on August 17, 2024, 01:47:59 pmHence my remark about wasting time.

author: Marco
author_rank: Super Contributor
timestamp: August 17, 2024, 04:58:04 pm
content: Quote from: SteveThackery on August 17, 2024, 01:41:49 pmNo, you are wrong.https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-requirements--windows-vista-and-later-Drivers signed through attestation are not tested by Microsoft.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 05:43:54 pm
content: Thanks, Marco, this is the first useful contribution in pages. Much appreciated.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 05:47:56 pm
content: "Attestation signed drivers can't be published to Windows Update for retail audiences. To publish a driver to Windows Update for retail audiences, you must submit your driver through the Windows Hardware Compatibility Program (WHCP). Publishing attestation signed drivers to Windows Update for testing purposes is supported by selecting CoDev or Test Registry Key / Surface SSRK options."When a driver receives attestation signing, it's not Windows Certified. An attestation signature from Microsoft indicates that the driver is trusted by Windows. But because the driver hasn't been tested in HLK Studio, there are no assurances made around compatibility, functionality, and so on. A driver that receives attestation signing can't be published to retail audiences through Windows Update. If you wish to publish your driver to retail audiences, you must submit your driver through the Windows Hardware Compatibility Program (WHCP)."

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 05:51:37 pm
content: Quote from: Siwastaja on August 17, 2024, 01:46:11 pmSays the guy who hasn't made a single useful contribution and probably doesn't understand the issues anyway. Come back when you're a grownup.

author: Marco
author_rank: Super Contributor
timestamp: August 17, 2024, 06:57:28 pm
content: Quote from: SteveThackery on August 17, 2024, 05:47:56 pmGuess how most GPU drivers get released ...

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 08:10:32 pm
content: Quote from: Marco on August 17, 2024, 06:57:28 pmTake it up with Microsoft. That's who I'm quoting.

author: IanB
author_rank: Super Contributor
timestamp: August 17, 2024, 08:32:08 pm
content: Quote from: SteveThackery on August 17, 2024, 08:10:32 pmTake what up with Microsoft?If Microsoft is going to deliver updates to millions and billions of consumer machines around the world through their automatic update mechanism, you can be damned sure they are going to apply some quality control mechanism to the updates they ship."Hey, Microsoft, here's a bit of random code I wrote. I want you to install it on everyone's computer around the world through Microsoft Update. It's perfectly safe, honestly. Trust me, OK?"I mean, what exactly is there to take up with Microsoft about this?

author: SteveThackery
author_rank: Super Contributor
timestamp: August 17, 2024, 09:54:31 pm
content: Quote from: IanB on August 17, 2024, 08:32:08 pmI was talking to Marco. I believe he was taking a pop at Microsoft over their process for releasing GPU drivers.FWIW, I entirely agree with your sentiment about Microsoft's interest in ensuring the quality of third party drivers.

author: Marco
author_rank: Super Contributor
timestamp: August 18, 2024, 12:11:15 am
content: Quote from: SteveThackery on August 17, 2024, 08:10:32 pmMost GPU drivers get released through the manufacturer and their own update mechanism. Untested by Microsoft.

author: radiolistener
author_rank: Super Contributor
timestamp: August 18, 2024, 03:17:45 am
content: Quote from: zilp on August 17, 2024, 01:11:37 pmI think that "a car with the hood bolted down" analogy is not clear.More close analogy will be "Windows is a rented car". You can use it to move, but obligated to pay for that and take care about - don't modify and use it according to the rules developed by their owner. You don't have right to dictate how the company (that rented you the car) should modify their car and how they needs to do their business.If you want to do something that you want, doing it on a rented car is a wrong way. Just because you signed an agreement with the company that you will use their car in such way as they want. If you want to do with car what you want, you need to use another car, it can be your own car bought in a car shop, but not rented car...A company that rented you the car can install tracking device on the car and can spy where is the car and what you're doing with it. This is required for security reason...The same with OS. If you want to use OS as you want, you need to use Linux, but not Windows. The same MS can track and spy where is their Windows and what you're doing with it. This is required for security reason...They don't lie you that these updates for security reason, just hide that this is not for your security, but for their security...

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 18, 2024, 04:28:32 am
content: Quote from: Marco on August 18, 2024, 12:11:15 amThere are drivers for main GPUs directly from MS, but they are rarely "up to date". So people usually update them directly from the vendor (either manually or automatically if they have installed accompanying software).But that doesn't mean these drivers are "untested" by MS. Actually, for main vendors, GPU drivers are WHQL (so "tested" by MS), except beta versions (which nobody forces you to install).Among main vendors (AMD, NVidia, Intel), I don't know any of them which releases drivers that are not WHQL (again unless beta or explicitely marked as such and it usually takes some explicit steps to install these).

author: mfro
author_rank: Regular Contributor
timestamp: August 18, 2024, 06:37:21 am
content: Quote from: SiliconWizard on August 18, 2024, 04:28:32 amMy understanding is that WHQL does not mean "tested by Microsoft" at all, but rather "tested by vendor according to MS' guidelines" and "vendor's test protocol checked by MS".

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 09:16:39 am
content: Quote from: SteveThackery on August 17, 2024, 05:51:37 pmThat's an ad hominem, by the way.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 09:21:06 am
content: Quote from: mfro on August 18, 2024, 06:37:21 amThat sounds right. Happy to be corrected.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 09:21:49 am
content: Quote from: zilp on August 18, 2024, 09:16:39 amYou don't say.

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 09:36:33 am
content: Quote from: radiolistener on August 18, 2024, 03:17:45 amAt least as far as the EU is concerned, that is not correct. That might well be what Microsoft whishes were the case, but it just isn't.And even with a rental car, the rental company can not make completely arbitrary rules as to how to use the car. They have a legitimate interest that they get their car back in the same state (modulo wear) that they handed it to you, but that's obviously not a thing that applies to software installed on your own computer.Quote from: radiolistener on August 18, 2024, 03:17:45 amThat would also be illegal in the EU (because of data protection laws).Quote from: radiolistener on August 18, 2024, 03:17:45 amThat is also illegal for the same reason. (Though enforcement is lacking a bit ...)

author: radiolistener
author_rank: Super Contributor
timestamp: August 18, 2024, 10:18:40 am
content: Quote from: mfro on August 18, 2024, 06:37:21 amInitially WHQL means that driver manufacturer paid certification fee to MS, 250 USD per operating system familyNow WHQL just shows that someone who signed the code paying at least 200 USD per year for code signing certificate. That sign means that only this person, government security services or very professional hackers can modify driver and apply signature again.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 01:56:29 pm
content: 1/ BSODs damage Microsoft's reputation; Microsoft is wise to try to prevent them.2/ To the best of my knowledge, the architecture of Windows prevents user-space software from causing BSODs. Code running in kernel modecancause BSODs, as was demonstrated by the kernel mode driver from CrowdStrike.3/ For some security functions, code must run in kernel mode in order to do it's job. This code - regardless of who wrote it - has the ability to to BSOD Windows, so it should be high quality and as free of bugs as possible.I don't know how many vendors of security software need to use the same gateway to kernel space as CrowdStrike - 50? 100? 10? Let's say 10, just for the sake of argument. I expect it is more.4/ At the moment, all ten of those vendors need to write their own driver with privilege escalation from user space to kernel space.If Windows is to remain free of BSODs, all ten of those drivers must be free of bugs, as far as possible.That's a lot of code, and a lot of debugging.5/ But there is another way. If Microsoft wrote their own privilege escalation driver, and forced all the security vendors to use that instead, thenonly one driver needs to be debugged and polished to near perfection.6/ So on one hand we have one driver that could BSOD Windows, on the other hand we have ten drivers that could BSOD Windows.Having ten BSOD-capable drivers in the ecosystem (all doing much the same thing, remember) is obviously more risky than having one BSOD-capable driver.7/ Therefore it is reasonable and logical for Microsoft to write that driver, and force our ten security vendors to use it, rather than writing, debugging and using their own.It does not guarantee freedom from BSODs, but it greatly reduces the risk.This is not remotely controversial.Windows is already full of APIs that handle privilege escalation, and which programmers must use. Keeping third party software out of kernel space is the rule, rather than the exception.8/ Microsoft has invested billions in Windows: it is their crown jewels.Nobody has as much interest in Windows as Microsoft. They cannot control what third party applications do, but they absolutely can control Windows itself.Making Windows as impregnable as possible is obviously in their interest.And one way to do that is to keep as much third party code out of kernel space as possible.Microsoft has limited control over the quality of third party software (basically just a testing regime) but it has (almost) complete control over Windows. It can put as much effort into driving up the quality, stability and security as it chooses.That is why, from Microsoft's point of view,forcing as much third party code as possible to run solely in user mode is an obvious step to take.------I am not supporting this model personally. I am simply trying to explain what Microsoft's interests are, and to explain one logical approach they can take to protecting those interests.------Now, our friend@zilp, if he has read this far, is at this very moment red-faced and the veins on his forehead are bulging. Even as we speak he is furiously typing averylengthy essay rubbishing every single sentence in my post. That's fine, we are all free to do that. I just wanted to take this opportunity to tell you what I think.@zilp's rubbishing won't change that. And if you want to be hostile, then please - go ahead. You will be ignored, though.On the other hand, polite and respectful disagreements are welcome, because such things are how we all learn and gain new insights.

author: madires
author_rank: Super Contributor
timestamp: August 18, 2024, 02:35:48 pm
content: What I see is that Microsoft can't even manage the security and quality of the parts they have full control of. The last few years there were so many issues with updates breaking things that admins are afraid of the next update. What will break this time? Remember the WinRE partition size issue? Users are required to fix the problem themselves. Picture your mother resizing disk partitions.

author: nctnico
author_rank: Super Contributor
timestamp: August 18, 2024, 02:52:32 pm
content: Quote from: madires on August 18, 2024, 02:35:48 pmI agree. Microsoft doesn't care about security. Only thing that counts is shareholder value. I still recall the 'Code red' incident in the early 2000's which infected millions of PCs overnight. That forced Microsoft to think about security for the first time. But how are you going to add security to a system which hasn't been designed for it?

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 02:58:54 pm
content: Quote from: SteveThackery on August 18, 2024, 01:56:29 pmThat is kinda true, but you are ignoring the actually important question: How will it be decided who gets to write and polish that driver, and why will that get a better overall result than having everyone write their own drivers?If one party gets to write and polish that one driver, but they are just polishing a turd, the overall result can still be worse than if everyone writes their own driver, none perfect, but only a few people end up using the turd, most people end up using a reasonably decent implementation.Quote from: SteveThackery on August 18, 2024, 01:56:29 pmThat is just false. Not only for the reason above, but also because monocultures create risks in themselves. The flip side of having only one implemention to maintain is that that implementation becomes a high-profile target.Also, you might be confusing "higher risk to have a BSOD happen somewhere" with "higher risk to have a BSOD happen on your machine". Your average machine will have only one of those installed, so any given machine is only affected by the risk associated with one driver regardless.And that difference is also important for global impact assessment: When everyone is using the same driver that end up crashing all machines using it, you have the world crash. When you have 10 drivers, and only every tenth company on the planet uses a given driver, only 10% of the world stops working. That resilience might even be worth using slightly lower-quality drivers.Quote from: SteveThackery on August 18, 2024, 01:56:29 pmThen why is the security of Windows systems so terrible that you need crap like Crowdstrike?Quote from: SteveThackery on August 18, 2024, 01:56:29 pmWhich is irrelevant for how EU competition authorities should decide, which is what your original claims were about, when you said that they maybe should change their decision.Quote from: SteveThackery on August 18, 2024, 01:56:29 pmYeah, I have already noticed that you are ignoring all arguments that contradict your claims.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2024, 04:46:31 pm
content: Quote from: nctnico on August 18, 2024, 02:52:32 pmThey never did. SteveThackery's interesting logic game falls apart as soon as you take real-world observations into account: the fact that Microsoft has always colossally failed to deliver software which is even remotely up to date with then-current security best practices, and Windows users havealwayshad to resort to third-party firewall and virus protection software, since the early days of connecting Windows PCs into the Internet.In an ideal world, Microsoft would make their operating system in itself more secure, such that complicated third-party security software would not be needed. This is by the way how every other operating system in existence works: the primary way of security is by design of software (both kernel and userland), where Windows has always followed a different principle, namely both OS kernel and userspace software (including that supplied by MS, e.g. Internet Explorer or Outlook) leaking like sieves, with near zero effort to do anything about it, leaving the mess for 3rd party software.And people always did install third-party firewalls and virus protection. Something which is nearly unheard of in every other operating system.Same EU rules of course apply to everyone, yet all the others (be it linux, BSD, MacOS, iPhone, Android or whatever) are fully capable of making orders of magnitude more secure operating systems. Being that this has not changed inthree fucking decades, andnowMicrosoft blames some pretty recent EU regulation nobody else has any trouble with, I would guess it's obvious to anyone it's a so calledexcuse. But clearly there are at least a few people who believe them!

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 05:07:44 pm
content: Quote from: Siwastaja on August 18, 2024, 04:46:31 pmConnecting to the internet, you say? You must have forgotten that autorun.inf was (is?) a thing! They managed to make putting a CD-ROM into the drive into a security risk by design ...

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 05:49:02 pm
content: Quote from: zilp on August 18, 2024, 02:58:54 pmPots and kettles come immediately to mind.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 06:10:22 pm
content: Quote from: Siwastaja on August 18, 2024, 04:46:31 pmI somewhat agree with this. Mind you, the ubiquity of Windows - especially in the hands of ordinary Joes - does make it a very attractive target, which probably skews the results a bit. There's an online database somewhere which reports on security attacks and responses, and I seem to recall that Linux has had more vulnerabilities exposed than Windows for most of the past few years. My recollection might be wrong.Even so, Windows' history of security vulnerabilities has long puzzled me. Windows was architected by Dave Cutler, who by then was already a serious heavyweight with extensive experience of other OSs. He was and is a highly respected software engineer. Given that, Windows NT must have had the best possible start - it was literally a clean sheet design, although it was required to implement a suite of APIs compatible with the DOS-based Windows 3 and 3.1.So where and why did it all go so wrong? According to Helen Custer's book, security and stability were baked into the specifications from the beginning. You would think that such a good start would produce a state of the art OS with class-leading security.Does anyone have any idea why NT lost its way and became so vulnerable?

author: nctnico
author_rank: Super Contributor
timestamp: August 18, 2024, 06:12:35 pm
content: Quote from: Siwastaja on August 18, 2024, 04:46:31 pmThat is not quite correct.MS-DOS has its fair share of virusses for which you also needed to have third party software installed in order to scan the system for virusses. Long before internet, some companies had computers setup at the entrance of the building where you could scan the floppies / diskettes you brought in from the outside.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 06:20:52 pm
content: Quote from: Siwastaja on August 18, 2024, 04:46:31 pmPoint of order, m'lud! I think Windows has been as good or better than Linux in recent years, according to that database that lists all the security breaches and patches. I wish I could remember where it is.About that EU regulation, I don't think that specific EU ruling applies to anyone except Windows. Do we know for certain that Linux has to comply with the same regulations, what with it being open source, so there is nobody the EU can take to court? Does Linux also have to allow third party security-related drivers to run in kernel mode? This is a genuine question - I honestly don't know the answer, but surely any such regulations would be unenforceable, because there is no organisation or legal entity behind Linux.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2024, 06:24:55 pm
content: Quote from: nctnico on August 18, 2024, 06:12:35 pmYeah. At least on a disk you had to run game.exe to get infected. CD autorun.inf as mentioned above made it funnier. At least most people knew about computer viruses, nearly hysteric about them. With internet connectivity more automated fun ensued, as Windows machines were known to get infected "on their own" without user downloading/installinganything; a known mitigation was to install the OS with network cable unconnected, and known-good firewall software installed from a disk / CD as a very first thing.I remember getting some virus by just clicking an email open on MS Outlook Express, without touching any attachment files or links within the message.

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 06:30:02 pm
content: Quote from: SteveThackery on August 18, 2024, 06:10:22 pmIt doesn't skew the obviously insecure design of a lot of software from Microsoft. Like, I dunno, executing email attachments.Also, Linux in the form of Android is also in the hands of ordinary Joes.Quote from: SteveThackery on August 18, 2024, 06:10:22 pmThat's a pretty useless comparison to make. What do you even include in "Linux"? All of Debian? Just the kernel? Just the parts of the kernel that are actually commonly used? What do you include in "Windows"? All third-party drivers? Application software from Microsoft? ...Also, how do you even count vulnerabilities? Is remote code execution the same weight as code running as root being able to load a kernel module when it shouldn't be?And how do you even know how many vulnerabilities Microsoft has fixed? It's not like you can have a look at their source repository. And how do you even know that the numbers you know for Windows aren't just a result of noone being able to look at the code?Quote from: SteveThackery on August 18, 2024, 06:10:22 pmBecause security is the result of more than just the kernel. That's one of the things that I've been trying to explain to you. And because the business doesn't care. They have always opted to do things in a way that's superficially "convenient" for the user, even if that was an obvious security problem.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 06:33:33 pm
content: Quote from: Siwastaja on August 18, 2024, 04:46:31 pmI'm not sure that is fair or true. You've obviously heard of "security by obscurity" - the exceptional popularity of Windows, combined with the lack of technical awareness of its users - has always meant that Windows has been a super-attractive target for hostile actors.What would be the point of attacking Linux, when all its users are geeks and techies with a fine understanding of how to secure an OS and how to mitigate any hacks that do get through? What would be the point of attacking MacOS when its adoption has always been in single figure percents?I'm not making excuses for Windows. I'm just saying a full and fair account must take those factors into account, along with the historical records of security breaches.Having said that, I do still wonder why Windows has such a bad record even taking those into account, for saying it had such a promising start.

author: madires
author_rank: Super Contributor
timestamp: August 18, 2024, 06:35:47 pm
content: Quote from: SteveThackery on August 18, 2024, 06:20:52 pmI remember that too. However, on the linux side they included stuff which is not part of the OS. It wasn't an apples to apples comparison.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 06:44:20 pm
content: Quote from: zilp on August 18, 2024, 06:30:02 pmI was hoping for a fuller and more nuanced analysis, to be honest, although I do appreciate hearing your view. I can't get my head around saying Microsoft "doesn't care". It's too sweeping a statement. I was wondering if there were fundamental mistakes in Cutler's design, for example. Or something else technical.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 06:50:09 pm
content: Quote from: zilp on August 18, 2024, 06:30:02 pmYour tone is becoming abrasive and hostile again. We're just guys having a chat - let's stay nice.Quote from: zilp on August 18, 2024, 06:30:02 pmAll excellent questions. And all easily answered if only we could find the damn database where this stuff is recorded and analysed.

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 06:57:08 pm
content: Quote from: SteveThackery on August 18, 2024, 06:20:52 pmFor one, yes, of course, anti-trust law applies to everyone. Also, there are Linux vendors in the EU, as well as foreign Linux vendors doing business in the EU, and so you obviously could take all of them to court in the EU if they were to violate anti-trust law, including if the Linux that they are selling were to have features that violated anti-trust law. After all, anti-trust law applies to legal entities and their behaviour, not to software.That does not necessarily mean that "Linux" would have to allow third-party kernel drivers, because anti-trust rules are about preventing monopolies. If some OS doesn't have any significant market share anywhere, say, chances are they can do just about anything as far as anti-trust law is concerned.But of course, it's just about impossible for Linux to violate anti-trust laws, as the lincense (GPL) is designed to make it illegal to monopolize it. Like, if you distribute Linux, it is mandatory that whoever receives a copy from you also can obtain the source code, and the license to modify and redistribute it, including to redistribute it in modified form. So, even if some company were to distribute a version of Linux that only allowed you to load kernel drivers signed by that company, they would also have to provide their customer with the source code of that particular version of Linux, and that customer would be legally permitted to remove the code that checks the signature, recompile it, and thus load whatever kernel drivers they like ... so it is just legally impossible for anyone to distribute a version of Linux that could actually prevent anyone from loading any kernel driver they want to load.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 07:13:55 pm
content: This summary might be helpful. It relates to the "big four" OSs and covers the past decade------Over the past decade, significant security vulnerabilities have been identified across major operating systems, including Linux, Android, Windows, and macOS. Here's a summary of the key vulnerabilities reported by operating system and year:Linux2014-2015: The "Shellshock" vulnerability (CVE-2014-6271) was a major issue affecting Bash, allowing attackers to execute arbitrary code. The "GHOST" vulnerability (CVE-2015-0235) was another critical flaw allowing remote code execution.2016: The "Dirty COW" vulnerability (CVE-2016-5195) was discovered, a privilege escalation bug that had existed in the kernel for nearly a decade.2017: The "Stack Clash" vulnerability (CVE-2017-1000364) allowed local privilege escalation.2018: "Spectre" and "Meltdown" (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) affected Linux, exploiting speculative execution in CPUs.2019: The "SACK Panic" vulnerabilities (CVE-2019-11477, CVE-2019-11478) affected TCP networking, leading to denial-of-service attacks.2020: The "BootHole" vulnerability (CVE-2020-10713) in GRUB2 bootloader could allow Secure Boot bypass.2021: Multiple vulnerabilities in systemd (e.g., CVE-2021-33910) could lead to local privilege escalation.2022: The "Dirty Pipe" vulnerability (CVE-2022-0847) allowed privilege escalation through the Linux kernel.2023: Recent vulnerabilities (e.g., CVE-2023-3269) targeted the Linux Kernel's TCP stack, leading to potential remote code execution.Android2014-2015: The "Stagefright" vulnerability (CVE-2015-3824) affected media processing, allowing remote code execution via MMS.2016: The "Quadrooter" vulnerability (CVE-2016-2503) involved four critical flaws in Qualcomm chips, affecting millions of devices.2017: "BlueBorne" (CVE-2017-0781) affected Bluetooth, enabling unauthorized access to devices.2018: The "KRACK" vulnerability (CVE-2017-13077) affected Wi-Fi WPA2, making Android devices susceptible to man-in-the-middle attacks.2019: "Strandhogg" (CVE-2019-14023) allowed malicious apps to hijack permissions of legitimate apps.2020: The "Strandhogg 2.0" (CVE-2020-0096) vulnerability further expanded the previous flaw’s scope, impacting almost all Android versions.2021: The "BadAlloc" vulnerability (CVE-2021-22292) in Qualcomm chipsets allowed remote code execution.2022: "Hermit" spyware vulnerabilities exposed security flaws in Android that enabled surveillance through malicious apps.2023: The "SpyNote" Android Trojan highlighted new risks in unauthorized surveillance and data theft.Windows2014-2015: "CVE-2015-1701" was a privilege escalation vulnerability in Windows' user-mode subsystem.2016: The "BadTunnel" vulnerability allowed remote attacks without user interaction. Microsoft also patched the "AtomBombing" technique (CVE-2016-7255) that allowed attackers to inject code into other processes.2017: "EternalBlue" exploit (CVE-2017-0144) led to the widespread WannaCry ransomware attack.2018: "Spectre" and "Meltdown" vulnerabilities also impacted Windows systems.2019: "BlueKeep" (CVE-2019-0708), a critical RDP vulnerability, could allow remote code execution.2020: The "SigRed" vulnerability (CVE-2020-1350) in DNS server could lead to a wormable remote code execution.2021: The "PrintNightmare" vulnerability (CVE-2021-34527) allowed remote code execution through the print spooler service.2022: Multiple vulnerabilities in Windows Defender and zero-day exploits like "Follina" (CVE-2022-30190) affected Office software and Windows.2023: The "Acropalypse" vulnerability (CVE-2023-1685) compromised image cropping in Windows, potentially exposing sensitive data.macOS2014-2015: "Rootpipe" (CVE-2014-4453) was a privilege escalation vulnerability discovered in Yosemite.2016: "CVE-2016-1757" and "CVE-2016-1825" involved privilege escalation and kernel vulnerabilities.2017: The "High Sierra Root Bug" (CVE-2017-13872) allowed unauthorized root access.2018: "CVE-2018-4237" and "CVE-2018-4280" addressed privilege escalation and kernel code execution.2019: "CVE-2019-8781" was a kernel memory corruption issue leading to arbitrary code execution.2020: The "Thunderbolt" vulnerability ("Thunderspy") exposed physical access risks to data.2021: "CVE-2021-30892" exploited a flaw in macOS' Gatekeeper, allowing malware to bypass security checks.2022: "CVE-2022-22674" and "CVE-2022-22675" were zero-day vulnerabilities that Apple quickly patched in Monterey.2023: Vulnerabilities in macOS Ventura (e.g., "CVE-2023-23529") continued to expose the OS to remote code execution and malware risks.------Of course we will all immediately feel the need to question what it says about our personal favourite OS. We would need a fuller analysis of the raw data to get the most complete picture.To me it says that security holes are to be found in all OSs, and on the basis of that summary, no one OS stands out as being "orders of magnitude" better or worse than the others.Anyway, with all caveats acknowledged, it might still be of interest.

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 07:19:00 pm
content: Quote from: SteveThackery on August 18, 2024, 06:50:09 pmIt's just a statement of fact. If you don't like it, that's on you.Quote from: SteveThackery on August 18, 2024, 06:50:09 pmNo, they wouldn't. The question wasn't how they did the comparison, the question was how one could possibly make a useful comparison based on such numbers, because it is just impossible to make a universally valid apples-to-apples comparison, because, no matter which was you answer these questions, there are common use cases that don't match those choices.

author: zilp
author_rank: Frequent Contributor
timestamp: August 18, 2024, 07:46:28 pm
content: Quote from: SteveThackery on August 18, 2024, 07:13:55 pmWell, OK, this is even more useless than I exepected.That is just a completely random selection of vulnerabilities that tells you just about nothing. It seems like this was mostly just "whatever was in the press", which isn't particularly interesting.Quote from: SteveThackery on August 18, 2024, 07:13:55 pmThis one, for example, was effectively a vulnerability that affected particular web server setups. In particular, it was pretty much irrelevant for desktop users, as well as most other types of servers.Quote from: SteveThackery on August 18, 2024, 07:13:55 pmThose were vulnerabilities in CPUs, so it is insane to list the workarounds for those vulnerabilities implemented in Linux as vunerabilities in Linux.Quote from: SteveThackery on August 18, 2024, 07:13:55 pmThe text even says this was a vulnerability in Qualcomm chips ... why is this listed under Android, then?Quote from: SteveThackery on August 18, 2024, 07:13:55 pmThe text also says that this was a vulnerability in the WPA2 standard, which also happened to affect Windows, so why is this listed under Androis?Quote from: SteveThackery on August 18, 2024, 07:13:55 pmSo, another Qualcomm vulnerability listed under Android?Quote from: SteveThackery on August 18, 2024, 07:13:55 pmWell, yeah, it affected all systems running on the affected CPUs ...Quote from: SteveThackery on August 18, 2024, 07:13:55 pmTo me it says that this is just useless to base anything on.

author: madires
author_rank: Super Contributor
timestamp: August 18, 2024, 07:58:54 pm
content: Yep, that excerpt is pretty useless for drawing any conclusions, no matter for which OS.

author: madires
author_rank: Super Contributor
timestamp: August 18, 2024, 08:21:49 pm
content: Quote from: SteveThackery on August 18, 2024, 07:13:55 pmHave a look at OpenBSD.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 08:52:23 pm
content: Quote from: zilp on August 18, 2024, 07:19:00 pmSo on what basis can you say that Linux, in particular, and all OSs in general, are so much better than Windows?

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 08:54:35 pm
content: Quote from: zilp on August 18, 2024, 07:46:28 pmYeah, I agree. When I read some more rigorous reports, I was amazed to find that there are recorded tens of thousands of vulnerabilities every year.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 18, 2024, 09:07:19 pm
content: Quote from: madires on August 18, 2024, 08:21:49 pmIt looks impressive!I've got three different Linux distros in virtual machines and quite enjoy messing around with them. But I could never use any of them for my main desktop because the applications are so shit. Old fashioned, crude, clunky, and almost universally lousy UIs. The world of Linux desperately needs an equivalent of Microsoft's or Apple's Usability Labs.I tried to convince myself LibreOffice could be my main office suite, but I just couldn't bear the plug-ugly UI, and when I found it wouldn't even support select-and-extend-by-sentence I vaped the decrepit piece of junk. Day-to-day productivity tasks on Linux are like going 30 years back in time. One fine day we might get to see some state of the art applications like the Affinity suite on Linux, but until then Linux is no substitute for Windows.EDIT: Your mate Linus agrees with me.ANOTHER EDIT: Sorry! Way off topic. This is supposed to be about microcontrollers.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 19, 2024, 01:29:28 am
content: Quote from: SteveThackery on August 18, 2024, 08:52:23 pmLinux is an OS. It is software which you run on your PC at your own will.Windows is a service. You give full access to your computer to Microsoft and they use it to provide OS services. That's how it's been since Windows 10 (2015).This is the most important distinction in my view, which makes all further comparisons irrelevant. I, for example, don't need a service, I need an OS. Hence I use Windows 7, but when it becomes impossible, I have no other choice than using Linux (or possibly Mac).

author: SteveThackery
author_rank: Super Contributor
timestamp: August 19, 2024, 07:17:49 am
content: Quote from: NorthGuy on August 19, 2024, 01:29:28 amI think W7 is the best version of Windows by far. I have that running in a virtual machine, too. To me, W7 is the ultimate development of the WIMP concept. I detest the way MS forced a touch-based UI (Metro/Fluent) onto us desktop users. Even now, years later, we have a half-baked UI with Fluent looking after the most common elements, and dropping back to W7-style (Aero) for the more techie stuff. What a horrible kludge.Trouble is, several of my favourite apps don't work on W7 (or at least they say they don't - maybe I should test that) so I'm currently using W10. It's OK - good, even - but it's still got the schizophrenic UI.Two of my machines are running W11. When I first saw it, I thought "Microsoft! What the f*** are you doing?". I still think that now: W11 is a major face-palm moment for Microsoft.

author: madires
author_rank: Super Contributor
timestamp: August 20, 2024, 10:01:21 am
content: This is becoming even more hilarious. Remember how Microsoft tried to blame the EU for the Crowdstrike disaster? Now Talos published an article about Microsoft deliberately circumventing MacOS security measures for their Office applications:- How multiple vulnerabilities in Microsoft apps for macOS pave the way to stealing permissions (https://blog.talosintelligence.com/how-multiple-vulnerabilities-in-microsoft-apps-for-macos-pave-the-way-to-stealing-permissions/)We screw up your IT security! No matter which OS!

author: SteveThackery
author_rank: Super Contributor
timestamp: August 20, 2024, 10:24:21 am
content: I think it equally raises questions about macOS's security model."This situation points to a key aspect: macOS trusts applications to self-police their permissions. A failure in this responsibility leads to a breach of the entire permission model, with applications inadvertently acting as proxies for unauthorized actions, circumventing TCC and compromising the system's security model. This highlights the importance for applications to implement robust security measures to avoid becoming vectors for exploitation."It off-loads a significant degree of responsibility to the applications.

author: Marco
author_rank: Super Contributor
timestamp: August 20, 2024, 11:39:11 am
content: No, that just shows you hate freedomJust use an iPad with a keyboard cover.I like a system where I can install a third party browser without having to beg Apple to certify and cripple it.

author: radiolistener
author_rank: Super Contributor
timestamp: August 20, 2024, 12:05:00 pm
content: Quote from: NorthGuy on August 19, 2024, 01:29:28 amI remember that this thing was started from Windows Vista.I even remember that I had a talk with fellow, it happens before Windows 7 released, and I said that Windows become a paid service soon. I almost guessed, it happened a little bit later

author: SteveThackery
author_rank: Super Contributor
timestamp: August 20, 2024, 02:37:35 pm
content: Quote from: radiolistener on August 20, 2024, 12:05:00 pmCould you explain this a bit more,@radiolistener? I've got machines running W7, W10 and W11 and I've only paid once for any of those licenses.I have tried the subscription model for MS Office ("Microsoft 365"), but I gave that up and reverted to Office 2010, which I think is the best version of Office ever. And I've only paid once for that license, too.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 20, 2024, 02:48:05 pm
content: Quote from: radiolistener on August 20, 2024, 12:05:00 pmI didn't see that coming. I only figured that out when Microsoft released an update with forced upgrade to Windows 10.It wouldn't be that bad if the service was paid - many people would drift away. But it was free, so nobody fought back. Never mind that free cheese can only be found in a mousetrap.

author: radiolistener
author_rank: Super Contributor
timestamp: August 20, 2024, 03:45:14 pm
content: Quote from: SteveThackery on August 20, 2024, 02:37:35 pmI don't remember details, just remember this talk when I said that they will change their business to paid services. Probably I had this thoughts after using their libraries like .net remoting or something like that. Don't remember exactly why I had such impression, but this talk happens just after Windows Vista release...and I am still surprised at how accurately I predicted what would happen next, although I myself did not fully believe it at that time.If I remember correctly, I had these thoughts when they rolled their online credential serivice, .net password or something like that, don't remember exactly...

author: SteveThackery
author_rank: Super Contributor
timestamp: August 20, 2024, 06:37:29 pm
content: Hmmm... OK, well I'm a Windows user primarily, because it has the second best apps after Apple, and I object strongly to Apple's "walled garden" business model.I can say with complete certainty that there are no recurring charges with any version of Windows. If you opt in, you can get MS Office as an ongoing subscription (now known as Microsoft 365), but you can also get it as a one-off payment and no ongoing updates. Also, Windows users have had free updates to the latest version for ages now - I can't remember when I last paid to upgrade, but it was many years ago.So there is nothing to complain about, really. Until we get to W11. This is the first version where MS seems blatantly to be monetising Windows. Not with a subscription, but with adverts. Can you imagine? - an OS with actual adverts! Of course they are presented as "suggestions", and you can turn most of them off. But even so, pretty bloody naff.The two best versions in recent years are W7 and W10. W7 was the peak development of the WIMP model user interface, and it was a fine OS to use. It remains my favourite. W10 had a half-baked, half-touch, half-WIMP UI, but was very well sorted, stable and with really good security and stability.I'll soon be building a new workstation, and I'm going to try to install W10 on it, not W11.EDIT: I forgot to say that I have no idea what the charging model is for Windows when it is deployed into a commercial organisation. I suspect there has been a subscription model for many years.

author: Marco
author_rank: Super Contributor
timestamp: September 18, 2024, 06:12:10 pm
content: Quote from: Marco on August 12, 2024, 06:50:50 pmNow we haveAppleproving my point, in a slightly different situation.