Is "uncorrectable" still a valid description?
There seems to have been some progress lately in eliminating ME that are not necessary?
Uncorrectable freedom and security issues on x86 platforms (2016)
71–80 of 141 posts
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#72I was struck by the following passage: >including Secure Boot, which even now requires FOSS users to purchase a license from Microsoft to boot FOSS on affected machines that lack an appropriate Secure Boot override." Can someone explain this to me, would this be for instance be Lenovo laptops making a deal with Microsoft since Windows is the default OS installed on these laptops? Is Microsoft mandating all OEMs/hardw…
> now requires FOSS users to purchase a license from Microsoft to boot FOSS
This isn't actually true, is it?
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#73Earlier quoted context omitted.
Secure boot has 4 types of keys: The signature database (db) and forbidden signature database (dbx) contain a whitelist and blacklist respectivly of keys, signatures, and hashes that are trusted to run. Updates to either of the above lists must be signed by a Key Exchange Key (KEK). Most implementations allow multiple Key Exchanges Keys. Updates to the list of Key Exchange Keys must be signed by the Platform Key (PK)…
Thanks for the detailed answer. In regards to: >" Most implementations only allow 1 PK, and that PK is Microsoft's." Isn't this a bit monopolistic and coercive though? "If you want the Microsoft Hologram on your product the PK has to be has to be Microsoft and there can only be one PK." I can't believe this doesn't violate some type of anti-trust laws.
How so? The OEMs want to make hardware that runs Windows. Microsoft provides a specification[0] and certification suites[1] that defines what "Windows-compatible" means, which OEMs then follow. Nothing coercive about that.
There is no open standard that defines what a PC is. Linux and other operating systems are piggybacking on the Windows PC standard. If they want OEMs to manufacture hardware to their standards, they'll have to create their own "Linux-compatible" specification and persuade OEMs to follow it.
[0] https://msdn.microsoft.com/windows/hardware/commercialize/de...
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn...
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#74Want complete software freedom? How about the MIPS chips the Russian military uses[1]? Those don't have an NSA back door. Sucks you can't really buy them as they are only made for use in Russian military and government applications. "Last year, the Russian government announced that it doesn't want to rely on Intel and AMD chips from the U.S. anymore and will focus more on using homegrown chips from Russia." [1] http:…
Those probably have Russian backdoors though.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#75Earlier quoted context omitted.
Please. While no-doubt the NSA take advantage of this probably-insecure privileged processor, I seriously doubt they were behind it. Secure boot is an obvious business need and Intel and AMD clearly implemented it in the laziest way possible. And by laziest I mean: nobody is going to argue with you in a meeting if you say "we don't need to release the source code for this". Seriously, anyone who has actually worked i…
We're not talking about secure boot, we're talking about Intel Management engine, which is a totally different story. You do not need ME at all to implement Secure Boot feature. Actually, no one really knows what Intel ME is doing, and _that_ is a huge problem.
The businesses which pay extra for vpro know at least some of what ME is doing.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#76Earlier quoted context omitted.
Libreboot and coreboot are trying to open source things on the software side of things (think dd-wrt or openwrt or tomato for routers, custom firmware basically). With hardware it's a bit of a different story. You hear about attempts from time to time, but getting away from Intel / AMD is really hard. The suggestions from the article about alternative architectures seem to be our best bet currently.
Alternative architectures is definitely the most pragmatic thing to go for. I was going off on a bit of a tangent from the article and just wondering if anyone has tried redoing the 70's - 90's without trying to be compatible with any existing technology but still learning from the mistakes.
The crowdfunded Open-V implementation of RISC V comes to mind.
https://www.crowdsupply.com/onchip/open-v
However, it doesn't look like they're going to come remotely close to hitting their funding goal. Fabricating chips is expensive.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#77Would love to see and ARM or MIPS setup get within shouting range of Intel. I have yet to hear any explanation of the IME that makes sense without the presence user-hostile intent.
Consumer ARM-based platforms in the market right now are even more locked down and spy-hook-infected than any x86 laptop. The baseband CPU on most phones is a far more capable device than the microcontrollers used for this on big core machines, and they routinely have access to all of DRAM without the possibility of interception by the application core.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#78The article states the following for RISCV: >"While this architecture is extremely limited in performance, price" Can anyone say thy the performance of RISCV is so lacking?
> Can anyone say thy the performance of RISCV is so lacking?
"Because no one has manufactured a high performance RISC-V implementation yet" isn't answer enough for you? All that exists for purchase at the moment are microcontrollers aimed at the ARM Cortex-M market niche.
There's nothing about the ISA that says you couldn't make a deeply pipelined, six-way issue implementation with three levels of cache running at 4 GHz. But that fact doesn't make such a machine appear from nothing either.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#79Would love to see and ARM or MIPS setup get within shouting range of Intel. I have yet to hear any explanation of the IME that makes sense without the presence user-hostile intent.
> I have yet to hear any explanation of the IME that makes sense without the presence user-hostile intent. The entirety of enterprise laptop management. Not because you don't want users to change their laptop. The point is to be able to run updates for the users. Or consider the remote KVM option. Disregarding security, that is a sysadmin's wet dream. Being able to recover a system that can't boot saves a lot of boot…
I get all that - I've worked in enterprise IT my entire career.
It does not explain the 30 minute timer.
Re: Uncorrectable freedom and security issues on x86 platforms (2016)
#80Earlier quoted context omitted.
Please. While no-doubt the NSA take advantage of this probably-insecure privileged processor, I seriously doubt they were behind it. Secure boot is an obvious business need and Intel and AMD clearly implemented it in the laziest way possible. And by laziest I mean: nobody is going to argue with you in a meeting if you say "we don't need to release the source code for this". Seriously, anyone who has actually worked i…
We're not talking about secure boot, we're talking about Intel Management engine, which is a totally different story. You do not need ME at all to implement Secure Boot feature. Actually, no one really knows what Intel ME is doing, and _that_ is a huge problem.
Though I agree that there is a high likelihood that there is nefarious activity going on, I also ageee that there are legitimate uses for extra processors and firmware.
Take microcode for example. At one time (as I understand it) microcode was not a signed blob. However companies wishing to hide details of their microarchitecture chose to encrypt it.
My guess is that these encrypted blobs grew first out of corporate closed source culture, which is strong in HW companies. If they are subverted with actively malicious code it was probably by secretive efforts, not the NSA simply propositioning the HW manufacturer.
Finally I'd like to point out that unless you design your CPU chip yourself and oversee the layout of it on the die, it is also possible that the semiconductor manufacturer you hire could embed their own nefarious processor within your design.
In practicality, I think running RISC V on an FPGA would have a very low risk of subversion. Though the FPGA design tools might add nefarious logic too.