> Intel management engine and Computrace decedent features are not always removable
Intel ME and Computrace have nothing to do with UEFI secureboot.
> “chain of trust between firmware and OS” assumes physical security in logistics and co-locations is perfect
Secureboot isn't just about physical security. It also (probably even more important) ensures malware can't modify anything in the chain of trust. Meaning malware can't backdoor the bootloader and in turn also can't install a rootkit in the kernel. If you would modify the binary of the bootloader or kernel their signatures would be modified. The firmware (ie. UEFI) won't load the bootloader anymore (because the signature check fails) and the bootloader (which verifies the kernel signature) won't boot the kernel.
Except there are already POC UEFI level rootkits that can't be detected by the host OS. Thus, such systems would appear to function normally to the common users, but offers zero benefit and may actually worsen the situation. Are you sure you are not confusing this with the TPM extensions?
Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, and historically this process has already proven problematic to secure (Acer, Asus, Lenovo, CISCO etc.) ;-)
> Except there are already POC UEFI level rootkits that can't be detected by the host OS.
I don't see how that changes anything? There are also HDD firmware hacks which can't be detected by the OS. Does that mean we should do away with filesystem security and permissions?
You still have to hack the UEFI to get a rootkit in there. And yes, everything can get hacked. But that's not an excuse not to have security, is it?
> Thus, such systems would appear to function normally to the common users,
Secure boot changes nothing in that scenario. You can also hack the UEFI and install a root kit without the UEFI even supporting secure boot.
> Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place,
If you find supply chain security important, then you should choose your supplier accordingly. That has nothing to do with secure boot.
"then you should choose your supplier accordingly" Yes, choose the refurbished, quietly restocked, and or disgruntled worker malware for your CEO. If you sell out, than don't go halfway dude... but buy a SSD/HDD retail like a sane person. ;)
"I don't see how that changes anything?" Well... Lenovo just patched 70 models for UEFI security issues, so some people see this a little differently. While I respect you opinion, it is irresponsible to frame blatant illegal product tying as a security feature.
"Secure boot changes nothing in that scenario"
We can agree it does nothing for security in most scenarios, and it is really weird some are so emotionally invested in convincing people otherwise.
"we should do away with filesystem security and permissions?" While I appreciate the off-topic rhetoric, one needs to recognize the main issue I see is who holds the signing keys. Would you buy a car someone in the next town needs to unlock for you everyday, well apparently some people are that lame.
I think we will have to agree to disagree on this issue =)
"Is this more common or less common with a chain of trust built in?"
False dilemma, my point was... when someone else holds the signing keys... there is no longer a real chain of trust. Thus, determining whether that someone else is intentionally evil or just grossly incompetent after detected incidents is an irrelevant thought exercise.
It's not a false dilemma. If it provides better protection to the overall set of customers, then it may be a net benefit.
No one had validates every virus signature and each line of code (or reverse engineers) in their virus scanner, yet those provide immense value to everyday users. This is no different - adding a feature that protects many users that are not sophisticated enough to manage their own CA, or that don't care to.
>there is no longer a real chain of trust
I trust a large security focused team to keep machines safe much more than I do the average PC owner or enterprise.
If you personally need the trust of your own CA, simply put on in. Many people here (and on the original blog post) point out how easy it is to do.
>exact arbitrary silliness we have seen countless times before
You continue to make the same mistake: contrast this 70 to how many breaches were prevented by the feature.
People with anti-virus software get viruses, both before and after getting updates. Is it therefore silliness to use anti-virus software? Or is there huge benefit to running it.
Cars with locks get robbed. Is is silliness therefore to have car locks? Or is there still large benefit to having locks?
Many people died after getting the COVID vaccine. Does that mean the vaccine had no benefit?
You repeat this exact error over and over, even after having it pointed out. Why?
“contrast this 70 to how many breaches were prevented by the feature.”
You mean... just like how elephants may be scared by computer mice, and that's why most offices are not infested by pachyderms. Your straw-man arguments will continue to incur ridicule friend, as they are provably irrelevant to the stated facts.
https://en.wikipedia.org/wiki/Simpson's_paradoxhttps://en.wikipedia.org/wiki/Informal_fallacy
“Is it therefore silliness to use anti-virus software?”
Starting another straw-man 2? let us discuss placebos that incur liabilities again… Many antivirus packages quietly collect user telemetry data, provide remote access, and break the host OS. People have documented armored-malware that utilize the antivirus program itself to bust through into kernel privileges ( https://www.zdnet.com/article/this-new-malware-exploits-bugs... ). Note, people primarily run signature scans on servers to protect Windows OS users from known email worms.
“ Is is silliness therefore to have car locks?”
Starting another straw-man 3? If you are a 2012-2022 Honda owner, than the factory digital-locking system is already broken for thousands of users. A physical key to a lock is something you possess, where a factory fob can be broken once the third party is eventually compromised.
https://www.thedrive.com/tech/i-tried-the-honda-keyfob-hack-...
“Does that mean the vaccine had no benefit?”
Starting another straw-man 4? A vaccine dose only protects against known variants, but often reduces the chances of dying due to how the virus variants severity has attenuated thus far. In my country we have above 86% immunization rates, but testing shows roughly 43% of the population were still infected at some point. Knowing people that were affected before the vaccine was available, in my anecdotal opinion the vaccine likely saved a lot of people suffering.
“You repeat this exact error over and over, even after having it pointed out. Why?”
I am polity waiting for a valid argument to teach you something important, but so far only see petulance driven fallacious nonsense. You have failed to convince anyone an off-topic straw-man strategy is valid, and I recommend this video as an introduction on evaluating information: https://www.youtube.com/watch?v=aNSHZG9blQQ
Intel ME and Computrace have nothing to do with UEFI secureboot.
> “chain of trust between firmware and OS” assumes physical security in logistics and co-locations is perfect
Secureboot isn't just about physical security. It also (probably even more important) ensures malware can't modify anything in the chain of trust. Meaning malware can't backdoor the bootloader and in turn also can't install a rootkit in the kernel. If you would modify the binary of the bootloader or kernel their signatures would be modified. The firmware (ie. UEFI) won't load the bootloader anymore (because the signature check fails) and the bootloader (which verifies the kernel signature) won't boot the kernel.