Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UEFI Secure Boot on the Raspberry Pi

linux.it

Post reply on HN
Print view View original

51–60 of 61 posts

Re: UEFI Secure Boot on the Raspberry Pi

#51

Post by AlotOfReading »

dingledork69 wrote: post #44
joezydeco wrote: post #27

Earlier quoted context omitted.

That kind of defeats how secure boot works.

No. You'd still lose access to the encryption keys so the data would still be safe. But it would allow you to start over without throwing the entire device in the trash and buying a new one.

Secure boot doesn't require disk encryption of any sort, that's simply a common additional feature that the RPi happens to support. Being able to change the public keys without a verified key update inherently violates the ARM security model here.

Re: UEFI Secure Boot on the Raspberry Pi

#52

Post by pklack »

cma wrote: post #39
gjsman-1000 wrote: post #20

Earlier quoted context omitted.

E-fuses enforce Secure Boot. Secure Boot, which cannot be disabled, are used to ensure that no exploit, no virus, no modification, can last beyond a reboot. If I want to put my device back into a guaranteed-secure state (at least for the moment), a reboot will always do the trick. I don't need to reinstall the operating system every time I'm uncertain. This is especially important for things like smartphones. Yes, yo…

A main purpose of the investment into it for iPhone is to protect their os and drm media interests, not the user. The incentive on laptops is more aligned with users for now, since you can turn it off.

Or actually make use of it as a security feature, instead of just scoffing at it and disabling it, by enrolling your own key.

Re: UEFI Secure Boot on the Raspberry Pi

#53

Post by worldsavior »

anaganisk wrote: post #42
worldsavior wrote: post #41

Earlier quoted context omitted.

Why would someone tamper a RPI? Usually most people don't really store anything important on a RPI, other than services like searx or whatever. It's not a powerful device for hosting databases, it's not really used for storage, only for small things like a Kodi server and even that lags.

There are several industry grade devices based on raspberry pi platform, LOL. Not just media servers. Some people also deploy them outdoors to stuff like weather, ADS-B etc. Some make it into cubesats. Don't just underestimate its use cases.

It has many use cases, but they don't really need extreme security. Secure boot is not really needed for something that's always running (a server).

Re: UEFI Secure Boot on the Raspberry Pi

#55

Post by dingledork69 »

AlotOfReading wrote: post #51
dingledork69 wrote: post #44

Earlier quoted context omitted.

No. You'd still lose access to the encryption keys so the data would still be safe. But it would allow you to start over without throwing the entire device in the trash and buying a new one.

Secure boot doesn't require disk encryption of any sort, that's simply a common additional feature that the RPi happens to support. Being able to change the public keys without a verified key update inherently violates the ARM security model here.

That's only relevant for device manufacturers who want to prevent the device owners from controller their hardware. This is evil and not a use case worth supporting.

Normal users care about secure boot because it protects their disk encryption.

Re: UEFI Secure Boot on the Raspberry Pi

#57

Post by 1827163 »

josephcsible wrote: post #16
adql wrote: post #9

Earlier quoted context omitted.

Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?

Yep. I wish OTP memory, eFuses, etc. were all illegal due to unnecessarily creating e-waste. In places where OTP is actually required for some technical reason, it should have to be on an easily replaceable socketed chip with no other functionality.

Yes, in a properly designed system, programming of fuses should be under strict hardware control, i.e. the power supply for blowing the fuses has to be supplied to a specific pin on the chip, and that the voltage is not applied by default.

I'm really disappointed that Raspberry Pi didn't implement hardware protection of the efuses, using the method I described above, or one similar to it. So a jumper would have to be installed, in order to supply power for blowing the fuses.

Many Allwinner SoCs have a separate VPP pin, without power supplied to this pin, it's not possible to blow the fuses. I wish the rest of the industry did that.

Notably AMD Ryzen CPUs can have their efuses blown in the field, if the Platform Security Processor is compromised: https://www.servethehome.com/lenovo-vendor-locking-ryzen-cpu...

It's just another way malware could compromise your hardware, this time physically disabling it. I'm sure malware authors might end up putting this to use somehow. And that's why the hardware should have this feature disabled by default. It should not be possible to damage hardware through software, period. There must be hardware protection against this, in a well designed system. Anything else is negligence, in my opinion. In the event of malware causing CPUs to be bricked, AMD should be held liable for the costs of replacing the processors, as they should have had foreknowledge of this occurring, when they designed the processors?

Ampere Altra ARM processors have a separate pin for efuse power, you can find that in their datasheet below on page 55, and they explicitly state to pull it to ground if you do not want to use it: https://d1o0i0v5q5lp8h.cloudfront.net/ampere/live/assets/doc...

Sadly there are no desktop-class Ampere CPUs yet. But that might change in the future.

Re: UEFI Secure Boot on the Raspberry Pi

#58

Post by 1827163 »

userbinator wrote: post #47
dingledork69 wrote: post #44

Earlier quoted context omitted.

No. You'd still lose access to the encryption keys so the data would still be safe. But it would allow you to start over without throwing the entire device in the trash and buying a new one.

This is similar to how MCU read protection usually works --- once you set it, you can't (easily, at least --- but still possible with the right equipment or $$$) read out the firmware, but you can still do a "full erase" which clears the device to an entirely clean blank state.

Many STM32 MCUs don't even allow this, you have to physically replace the device if it's set to full protection, as it cannot be reversed. Yes, built in self-destruct.

See page 5 of the following document, it is the Level 2 protection that's irreversible: https://www.st.com/resource/en/product_training/STM32F7_Secu...

The PIC32 MCUs I use always allow you to reverse the protection, after erasing the device.

Re: UEFI Secure Boot on the Raspberry Pi

#59

Post by anaganisk »

worldsavior wrote: post #53
anaganisk wrote: post #42

Earlier quoted context omitted.

There are several industry grade devices based on raspberry pi platform, LOL. Not just media servers. Some people also deploy them outdoors to stuff like weather, ADS-B etc. Some make it into cubesats. Don't just underestimate its use cases.

It has many use cases, but they don't really need extreme security. Secure boot is not really needed for something that's always running (a server).

I think the final user or implementor must be a judge of that not us.

Re: UEFI Secure Boot on the Raspberry Pi

#60

Post by joezydeco »

dingledork69 wrote: post #55
AlotOfReading wrote: post #51

Earlier quoted context omitted.

Secure boot doesn't require disk encryption of any sort, that's simply a common additional feature that the RPi happens to support. Being able to change the public keys without a verified key update inherently violates the ARM security model here.

That's only relevant for device manufacturers who want to prevent the device owners from controller their hardware. This is evil and not a use case worth supporting. Normal users care about secure boot because it protects their disk encryption.

I'm the IoT node design space and this is what we use. There is no sales or use case to repurpose the device one it's at the end of life, and we don't want people to do as such.

The point of secure boot is to make sure it's only our firmware running, and only our firmware connecting to our backend with the appropriate keys. Anything else is a security nuisance at best and an company killing problem at worst.

We're willing to sacrifice the SoC in those cases. Your mileage may vary.

Post reply on HN