Live data from Hacker News

Uncorrectable freedom and security issues on x86 platforms (2016)

decentralize.today

11–20 of 141 posts

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#11

This needs more attention. Particularly now that AMD may actually look into cooperating with the community on this matter somewhat. I wouldn't get my hopes up yet though, as this was a Reddit AMA done during a time when AMD is keen to please the community. This matter must not go away for something to be done about it.

Are there any projects out there that throw the baby out with the bathwater and just restart computing from the ground up with freedom as a foundation? I'd love to participate something like that and I think it'd be a great way to respark 80's like hacker movement.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#12
post #6

The 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?

I suppose it's true for currently available chips that implement the RISC-V ISA.

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.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#13
I 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/hardware vendors to configure secure boot with a MS signing key? Even if I order a laptop with no OS installed?

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#14

This needs more attention. Particularly now that AMD may actually look into cooperating with the community on this matter somewhat. I wouldn't get my hopes up yet though, as this was a Reddit AMA done during a time when AMD is keen to please the community. This matter must not go away for something to be done about it.

Are there any projects out there that throw the baby out with the bathwater and just restart computing from the ground up with freedom as a foundation? I'd love to participate something like that and I think it'd be a great way to respark 80's like hacker movement.

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.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#16

I 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…

Is Microsoft mandating all OEMs/hardware vendors to configure secure boot with a MS signing key?

Basically yes; it's required to get the Windows sticker. I haven't heard that MS charges money to sign bootloaders, though.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#17
Is there evidence these have been used to harm anyone?

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?

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#18
>Both serve effectively the same purpose; to ensure that the physical owner of the machine never has full control of said machine.

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.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#19

... I confess I'm very frustrated reading about how trusted computing modules hurt the cause of FOSS but no alternatives to actually try and carry out cryptography to execute trusted code. 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…

> 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

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
This is assuming strong encryption keys. If it is only protected by an unlock code your steps look like this.

  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

As you can see hardware security does not save you when the strong keys are on the device and the user only enters a weak key. Similarly hardware security does not save you if a hostile entity got access to your hardware.

Re: Uncorrectable freedom and security issues on x86 platforms (2016)

#20

Earlier quoted context omitted.

Are there any projects out there that throw the baby out with the bathwater and just restart computing from the ground up with freedom as a foundation? I'd love to participate something like that and I think it'd be a great way to respark 80's like hacker movement.

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.

Their attempts will be just that. There's a SHA256 signature required to verify the ME code - no signature, no boot (or boot for 30 mins less commonly). They won't share the keys with just anyone.
Post reply on HN