>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/hardware vendors to configure secure boot with a MS signing key? Even if I order a laptop with no OS installed?
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). Most implementations only allow 1 PK, and that PK is Microsoft's.
This means that any binary run on a secure boot machine with Microsoft's PK has a chain of trust rooted at Microsoft.
It may be possible to update the PK before transitioning the system to secure mode; but most consumer devices ship already in secure mode. This is different from simply disabling secure boot, which would still not allow you to update PK (for obvious reasons).
EDIT: It appears that it is called "user mode" and "setup mode" instead of secure mode.
Also it seems that some systems allow you to re-enter setup mode from the "bios" [0].
On an unrelated note, what do we call the firmware provided settings app now that it is no longer part of the BIOS.
[0] https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Co...
>" 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.
Not but the OEM vendors and not MS should be the owner of the sole PK allowed in the engine. MS doesn't make the hardware yet they are in charge of it. I think that's the issue, it has nothing to do with a grand conspiracy.
Basically yes; it's required to get the Windows sticker. I haven't heard that MS charges money to sign bootloaders, though.
If you look at the UEFI requirements for Windows 10[1], specifically clauses 19 and 20, it says for non-ARM systems the user MUST be able to put Secure Boot into Custom signature-checking mode.
[1] https://msdn.microsoft.com/windows/hardware/commercialize/de...
This isn't actually true, is it?
In fact, many distributions don't support Secure Boot at all.
The 30-minute timeout is particularly mischievous. It's like they REALLY want to slow down any effort at patching out the ME.
Are we going to have to wait on an insider leak on what's the real deal here? Or have I completely missed out on a perfectly good excuse for what's going on?
Seriously, anyone who has actually worked in a real company knows that it is a huge amount of effort to get source code released to the public, and if any of it is licensed from third parts it is probably near-impossible.
If you think there's a evil NSA front for this type of stuff -- its Absolute Software. Their bits have been embedded in most BIOS packages since the 90s, and nobody has heard of them.
We have CJDNS (which salsa20's all your data & can VPN legacy networks to ya), fully FLOSS SBCs for under $20ea, and 802.11n and AC outdoor radios can be had for cheap, this is merely a community involvement problem.
What about the other powers? China, France, Russia have their own NSA's that would be asked to provide solutions to protect all the PCs in the service of their own governments, what are they doing about it?
https://en.wikipedia.org/wiki/Rainbows_End
(see also https://en.wikipedia.org/wiki/Trusted_computing_base)
Although I recommend switching off x86, I don't buy the claim that we cant do another x86 without backdoors. For one, Intel or AMD might do a "semi-custom" design without one for a price. Second, Centaur has long been the 3rd player in x86 for low power stuff sold by VIA. They'd probably do a high-performance design if incentivized. Third, many x86 players showed up over time that simply failed in market or were acquired. Nothing stopping another unless there's a legal restriction Im unaware of.
There is also microcode, and many patches are issued through microcode.
>"While this architecture is extremely limited in performance, price"
Can anyone say thy the performance of RISCV is so lacking?
This is not easy to acquire or build. Some is wisdom from decades of design and iteration. Some is hundreds of thousands of engineering hours. Some is big money.
RISC V is a new open source project. Who knows how close they will ever get.
Nothing says the ISA itself is a barrier to performance on par with popular existing processors though. The RISC-V BOOM implementation is supposed to be close to an ARM Cortex A9 in performance.
"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.
https://www.youtube.com/watch?v=HVPSlS2v1F0
The whole toolchain they are working with looks quite awesome tbh.
Commercially, the Freedom U500 platform seems to be really interesting:
https://dev.sifive.com/documentation/freedom-u500-platform-b...
You can take RISC-V ISA specification or ready Verilog/VHDL and produce working ASIC chip relatively easy, but it's not fast.
If you want fast general purpose chip in that competes toe-to-toe with AMD and INTEL, it will take huge amount of chip and physical design, simulation and verification. AMD has spent tens of millions to get new x86 ISA compatible architecture out. Doing the same for RISC-V without enough demand would be economic suicide.
I remember a wihle back when Google was shopping around for Intel replacements (likely a negotiation tactic), people were saying they should buy the POWER division from IBM (IIRC). That would have been really interesting...
Funny, I was speaking to some IBM engineers a few months ago and brought up the POWER chips and they kind of laughed and said something to effect that biggest use case for POWER was Google as a means of keeping Intel pricing in check.
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 boots on the ground.
I used it a few years ago to automatically build classroom computers for training classes. The trainer would pick a configuration, and a complete server and workstation environment would be installed.
You can also do KVM from a powered down state, brick the device, or validate that management engines are present.
Inevitably the complaint is, "Well if they have physical access you're screwed anyways." And I just don't understand how anyone can maintain that farce when the last year has shown that it's a genuine challenge even for the US FBI to unlock a mobile device without the owners say-so and it's getting harder all the time.
If you truly believe that physical access is a trump of any security then you can never trust your hardware anyways, as it is exceptionaly hard to prove it conforms to a spec.
For physical access, I though the case was "If anyone has access to your device while unlocked, or locked but not disk-encrypted, consider it permanently compromised. If anyone has access to it while disk-encrypted, consider replacing it if you're very concerned." The 'permanently' bit is for unknown firmware compromise, and this position seems pretty sane.
But trusted computing modules are something else altogether. Even non-physical access can compromise them. There's some evidence that they can be compromised around a fully-encrypted disk. And checking whether they're compromised is effectively impossible.
Yes, it might be possible to execute trusted code around the module, if it never hits the machine in a vulnerable form. But that's slow, non-interactive, and virtually nonexistent at present. Right now, trusted computing modules do compromise machines are roughly Ring -3, with no real recourse.
Difficulty? Yes. But the FBI is not the NSA, they don't specialize in such attacks. It's like asking your plumber to do heart surgery. So they commissioned it to else who does, and boom, they had access.
Strong cryptographic security shouldn't have a pricetag any lower than "we feed all the hydrogen in the universe to black holes to harvest enough energy for the computations".
And phone security is orthogonal to baked-in firmware signing keys. The only change you need is allowing the user to add their own signing keys maybe with the caveat that all data in the protected keystore gets destroyed in the process. Then you have freedom and secure boot in one package. The signing keys are the issue, not the ring -1 management code.
> If you truly believe that physical access is a trump of any security then you can never trust your hardware anyways, as it is exceptionaly hard to prove it conforms to a spec.
Here are some simple steps
1. compel a manufacturer to create a spy-firmware, signed with their signing key
2. get access to a device for a few minutes
3. patch firmware that exfiltrates the data once the device is unlocked by the user
4. return device to user / to where the user placed it
1. acquire device
2. a) compel manufacturer to create a firmware that bypasses "delete on unlock failure" feature
b) unsolder chips, apply silver needles to flash controllers so you can
read/restore internal key storage whenever it gets wiped
3. enumerate all N-digit pass codes until it is unlocked
Your argument is no one can be trusted to make them. But my argument is that if you believe that then you know you can't trust anyone to make anything one way or the other.
Surely rather than botch the whole thing (because we don't like the vendors) we should start to propose stronger and more consumer-centric versions of these?
A skeptical and cyncial part of me notes: given the tiny tiny number of users who can actually verify their machines are what they say they are, all "trusted computing" rebukes do is argue against a tech that actually does mitigate rwal attacks for the vast majority of uses.
https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...
This is currently the top-voted question with almost four thousand upvotes. AMD gave a noncommittal "we'll look into it" response, but now at least they're aware that a lot of people actually do care about things like this.
That'll build confidence that the others aren't compromised.
The costs could be reasonable (http://electronics.stackexchange.com/questions/7042/how-much...) under a kickstarter-style campaign.
I read about some new hard/software for secure boot, etc., but don't recall all the details now.
So, for a shorter approach, suppose I just buy a processor from AMD, a motherboard from ASUS, hard disk drives from Western Digital, etc., and plug it all together for myself. So, then I'm the manufacturer or OEM of my computer.
Q. 1. For what the OP is talking about, where do I have threats to privacy, control of my machine and its data, and security?
Q. 2. To use the machine I plugged together, do I have to get some keys from Microsoft?
Q. 3. Suppose I install operating systems from Microsoft, e.g., Windows 7 64 bit Professional, Windows 10, Windows Server or the database SQL Server. Then do I have to get keys from Microsoft?
Q. 4. Will the support processor and its software, whatever they are called, on their own without my knowledge or approval use the Internet to send/receive data from/to my computer, modify the data on my hard disks, etc.?
Thanks.
2. Depends on the motherboard and the BIOS written in the flash chip
3. No. They are already signed.
4. If somebody controls them and ask them to do so. All that's necesary is a LAN connection (or wifi, but only with Intel chips) and power. The HDD is completely irrelevant, as is the OS.
http://data.manualslib.com/pdf2/42/4150/414970-asus/m5a97_r2...
Just checking, the PDF does mention the Unified Extensible Firmware Interface (UEFI) but not ARC or PCH.
That ASUS manual does mention that the UEFI BIOS does offer automatic updating of the BIOS version; that feature, if enabled, does seem to raise security concerns.
Looking at the UEFI page of Wikipedia at
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In...
there is
> UEFI can support remote diagnostics and repair of computers, even with no operating system installed.[3]
which seems to raise some security concerns. Also it does appear that some people trying to install an operating system might encounter some mud wrestling. Maybe what I'm intending to do with Microsoft's Windows 7, 10, and Server will be easy enough.
Thanks.
"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://www.tomshardware.com/news/baikal-t1-mips-cpu-omnishie...
You can make an argument that it is still an improvement, because there are no obvious binary blobs required by the system. But in this case, I would recommend going for one of the many Chinese ARM cores -- at least you can buy them easily.
The early models implemented a proprietary VLIW architecture with enterprise-y features (like hardware-tagged pointers, probably borrowed-ish from Itanium) with a dynamic binary translation layer for x86 compatibility on top, not sure if they still do that or perhaps the other way around now.
This strikes me as the root problem here. How can one company be granted a monopoly on what is basically an instruction set? Particularly in the case of the instruction set our civilization runs on?
Since I can't understand how something like this could happen I don't understand why any replacement architecture wouldn't end up being controlled by a single entity.
Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.
> Is this an accurate description of what is happening? (I don't pay much attention to desktop systems: I spend most of my time concentrating on the ever-worsening mobile arena.) Do these "major distributions" come with a recent version of bash? As someone who develops software under the GPLv3 license, I would not want my software being distributed to these machines via this hack :/.
It's not entirely accurate. Effectively what most modern distributions do is that they have a "shim" which is signed by Microsoft. That shim then enrols the distribution's own UEFI keys on the laptop. So their kernel is signed with both their own key and Microsoft's key. This means that you can modify your code without "permission" from Microsoft. openSUSE, Fedora and Debian all employ this tactic so that our distributions can boot on newer laptops.
Do I wish this wasn't necessary and that everything ran core boot? Yes. Is there a better way of handling this problem? Not as far as I know.
I'm pretty sure that neither of those is the case, however. Once the system boots using the signed loader, it's really just Linux, and you're free to replace the kernel and any bit of userspace as usual.
Furthermore, I seriously doubt that anyone is selling machines with Linux preinstalled that have Secure Boot which cannot be turned off - simply because that would become known pretty fast, and even aside from licensing issues, would elicit a very hostile reaction from the community (and hence many potential buyers).
Shim contains keys from Canonical or someone (I'm not sure), and verifies that GRUB has been signed by Canonical before running it. Then when GRUB runs the kernel, it calls back into shim first to verify the kernel has also been signed (Actually that last step wasn't enabled yet last time I checked).
So basically, until Microsoft changes their keys, by signing shim they've given Canonical permission to sign things. But unless you disable secureboot, you can't run a custom kernel unless you convince Canonical or Microsoft to sign it.
I dislike the mandatory use of these features as much as the next nerd, but this is inaccurate FUD. Secure Boot is a code in flash that checks the signature of whatever you try to boot against some rather complicated policy. It's regular code and would work more or less the same on any platform that runs machine code off of ROM or flash.
There's something that Intel calls, IIRC, "Verified Boot" that tries to prevent someone with an in-system programmer or desoldering skills from changing the flash, but that has nothing to do with the Management Engine either.
And FOSS users don't need to purchase any license from anyone. They can use a tool like Linux Foundation's PreLoader or Red Hat's shim (open source but awkward to modify because you need the signed binary to boot on a stock system) to boot anything they like. No negotiations, no license, no communication with MS at all.
> I dislike the mandatory use of these features as much as the next nerd, but this is inaccurate FUD. Secure Boot is a code in flash that checks the signature of whatever you try to boot against some rather complicated policy. It's regular code and would work more or less the same on any platform that runs machine code off of ROM or flash.
"Regular code" doesn't mean it's not proprietary, and doesn't mean that it's not concerning for free software users.
> And FOSS users don't need to purchase any license from anyone. They can use a tool like Linux Foundation's PreLoader or Red Hat's shim (open source but awkward to modify because you need the signed binary to boot on a stock system) to boot anything they like. No negotiations, no license, no communication with MS at all.
Those preloaders are signed by Microsoft. While it is a good hack for distributions at the moment, it doesn't mean that Microsoft is no longer in the loop. They still have an incredibly worrying amount of control over what can run on modern hardware.
Which has essentially nothing to do with the article and isn't even Intel's fault in any meaningful sense.
That is the end-result, yes, but that wasn't the purpose: the purpose was to allow companies to keep track of their laptops--to remotely push out firmware updates, to inventory the hardware/asset list, etc. It was a convenience feature, essentially.
Of course, the end-result, as stated, is that you've got a complete black-box second processor that can do whatever it wants, even when your device is off.
Of course the government wants this capability to access anyone's system, so I assume nothing will be done. This has to be one of the worst things that has happened in the history of computing.
EDIT: Handy for CBP use, I imagine.
https://www.fsf.org/blogs/community/active-management-techno...
Canonical presentation: REcon 2014 - Intel Management Engine Secrets (Igor Skochinsky) https://www.youtube.com/watch?v=4kCICUPc9_8
Decoding ME firmware in BIOS updates until Skylake (2015): http://io.netgarage.org/me/
> 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.
I recently installed rEFInd from source by using a self-singed certificate (signed the binary using it and enrolled the key into the EFI using mokutil) and it worked. I certainly didn't have to pay MS. I do know that rEFInd provides a key of their own (using the distro's shim) that obviously has trust rooted at MS.
Not that I wouldn't like a world with no more blobs (or at least reproducible-build signed blobs). But I use a ton of software I don't have time to review. Why is solving this more important than, say, looking for RPC holes in docker?