dickon wrote: ↑
Tue Mar 24, 2020 10:58 pm
Secure Boot is broadly worthless anyway, because of the problem mentioned above: it requires the *entire stack* to be secure: firmware, bootloader, kernel, *anything which may be executed as root* (or equivalent), and anything which can be influenced to execute anything as root.
 And anything running in kernel context, such as your anti-virus suite; google 'sophail' for much amusement.
yeah, thats how the roku2 was hacked, there was a bug in the UI that gave a root shell
PiGraham wrote: ↑
Wed Mar 25, 2020 8:47 am
I found this info on verified booting: https://blog.nviso.eu/2019/04/01/enabli ... erry-pi-3/
I can see the sense of it for closed-source OS binaries on controlled hardware, but how is it supposed to work for open source OS on uncontrolled hardware? Anyone can buy a RPi that is not, and should not be, locked down. They can build their own kernels and do what they like so none of this prevents anyone running Raspbian, or another OS, on a clean RPi board.
It works for DRM on particular devices where you want to deny root access and prevent custom kernels running, but that is contrary to the goals for Raspberry Pi, isn't it?
the idea is less about something thats configured on every single pi
and more about the creator of a certain product, re-selling pi's that are specially modified to only run their software
even if you can clone the software on the SD card, the specially modified pi is the limiting factor, and acts like a physical dongle/license key
PhatFil wrote: ↑
Wed Mar 25, 2020 2:38 pm
Greg Erskine wrote: ↑
Sat Mar 21, 2020 8:55 pm
First rule of security: Do not discuss your security strategy on a public forum.
second rule implement the simplest solution. potting the device in an epoxy is the general approach
but youll want to use an epoxy that is similar to the uSD epoxy, so any attempt to selectively melt it with acid, will also melt the uSD card itself!