Once UEFI is done, would secure boot be of any use ?
Is there a good way for an installer like ROCK to do secure boot?
There may be a way to use Microsoft’s keys as a shim – but this seems to defeat the entire point of secure boot.
Also, there seems to be a fundamental conflict w/ secure boot and an appliance like Roon OS (assuming I’m not missing something): I want to be able to upgrade the kernel without touching the bootloader. If I can’t do that, I can’t have an unbrickable system (2 OS copies stored at once).
I feel like I’m missing something.
Any secure boot + firmware experts out there?
Not an expert, but using a shim is exactly how all the Linux distros do it. The shim is signed by Microsoft and is checked on boot, then loads grub (the actual Linux boot loader) which is signed by the distribution, and after this the kernel boots normally.
Distributions can have their shim signed on the Microsoft Sysdev portal:
It’s implemented in a package, shim-signed on Debian-based distros:
Description-en: Secure Boot chain-loading bootloader (Microsoft-signed binary)
This package provides a minimalist boot loader which allows verifying
signatures of other UEFI binaries against either the Secure Boot DB/DBX or
against a built-in signature database. Its purpose is to allow a small,
infrequently-changing binary to be signed by the UEFI CA, while allowing
an OS distributor to revision their main bootloader independently of the CA.
This package contains the version of the bootloader binary signed by the
Microsoft UEFI CA.
In distros it is possible to upgrade the kernel, of course. There is also code for doing the necessary things when self-compiling.
Personally, I find Secure Boot utterly pointless for personal machines and I turn it off. It’s just another point of failure (and it did happen to me once that the secure boot failed due to some signing issue after an update). On ROCK, IMHO even more pointless.
If there are untrusted people or outright intruders in my home who have physical access to my machines, I have bigger problems than them booting a different OS on the NUC.
One argument for making ROCK capable to secure boot might be to simplify installation if it works either way. (And I don’t know if all NUC implementations allow turning off secure boot in the boot settings). However, it anyway requires interaction with the secure boot settings on installation.
The whole process as per Ubuntu docs:
There seems to have been a fiasco in 2020 where problems found in GRUB2 led to blacklists, requiring updates to bootloaders. Ugh.
I love this forum.
I think that Roon doesn’t really have a responsibility to guard us against malicious types rooting our machines when they have succeeded in physical intrusions to our home. It’s a music server. So this feels to me (given the premise above) that the only reason to worry about secure boot is (a) to help ease install for those who don’t know want to/can’t readily navigate BIOS, which in turn lowers the bar to ROCK ownership, or (b) make ROCK / MOCK more accessible to some putatitve machines which cannot disable secure boot. If I’m right on the above use cases (and the inapplicability of it to create security other than in the case of physical access), I’d personally skip it (sounds like it could add complexity down the road, and I’m not sure about those benefits actual benefit), but I’ll be the first to admit I’m hardly very experienced in these areas so I could be misconstruing what Ive read here and the basic reading. I’m honestly not trying to provoke, but just to make sure i understand. If I’m off base, pls let me know.
But for the customer types that don’t know how to change BIOS settings/update the NUC Firmware and install ROCK - the NUC/ROCK direction isn’t for them and they should buy a Nucleus.
The thing I’m scared of is:
- forced blacklists for new NUCs in the future
- having to resign a bootloader in an update.
The update procedure is built to have a static UEFI bootloader that never changes. This bootload can be smart about switching between one of potentially two installed operating systems. This allows for bad updates to go out (including kernels) without bricking the unit. After a few reboots/failures, the bootloader will return back to the previously working build. We’ve had builds where NVMe driver incompatibilities broke the boot on a very small % of SSD’s with buggy firmware. This new system will avoid that, but it is critical we never are forced to change the bootloader.
Indeed the only thing that secure boot does is preventing the boot of unapproved OSes. If bad actors have physical access, then obviously it can do even this only if it’s impossible to disable secure boot in the UEFI, so to be effective one also needs to lock down the UEFI settings menu with a password or whatever.
All in all IMHO a massive headache, in addition for the reasons stated by @danny, and utterly not worth it if one isn’t running a server room or laptops with critical data (if at all).
Possibly with the exceptions you and I stated above (possible existence of devices that require secure boot, possible simplification for some user groups)
And to add, even if one goes to all these lengths with secure boot to prevent the NUC booting a different OS, it still does not protect against the much simpler approach of the intruder bringing their own laptop that runs whatever they want and plugging into one’s home network.
I’d suggest that, like with so many other Roon things, if someone wants this kind of control they should not be running Roon OS but another OS with Roon Server on top.
Secure Boot was made to prevent you from getting a bootloader virus (or some other non-authorized code running in the bootloader w/ full access).
Imagine you are running Windows, get a virus, and that virus manipulates your bootloader to reinstall itself on boot. then even if you use a virus cleaner to remove all traces of the virus, you’ll reboot and the virus will come back. This was a common attack vector decades ago.
True, that’s one other reason that can be ignored The other ones I mentioned are also reasons - for which use cases exist, just not here.
I think the main reason was Microsoft trying to lock out other OSes from PC hardware, at a time where they still hadn’t understood the importance of free unix-like OSes
I looked into this when playing around with HQP embedded as I wanted to dual-boot on a machine with a Windows secure boot install. My advice is stay away but I’ll give a much more compelling reason at the end. First the “proper” way to secure boot…
You’d have to publish certificates and those would need to be installed on the machines, by users, for the certs to be authenticated. This would allow you to update the bootloader and the cert would auth the new stuff. But, this would break any machine which could not, or if a user could not, install the certs themselves. You could do this for Nucleus very straightforward and it would supply an additional level of security? Maybe? But trying to explain the additional steps of user supplied machines just doesn’t appear to provide a great deal of benefit only hassle.
Stay away from the “shim” thing. As you said, it provides zero benefit from a security aspect. Additionally, it’s a giant hack that really only benefits dual-boot situations so you don’t have to turn off secure boot to boot the “other os”. And, giant hacks like this would cause me to loose respect for you <just kidding">"
OK, so now the big reason to just ignore it and you already said it… It’s an “appliance”. Encrypted Windows using secure boot prevents the machine from booting without the matching certs locked to the machine. This prevents someone from sidebooting an OS to silently steal my data or modify the OS in any way. That’s great for an enterprise. Big giant hassle for a personal appliance. Especially if anyone plans to move the OS drive between machines. For an “always on” machine it provides no benefit. If users need this, and I can’t imagine why they would*, there are ways they can hack this up themselves but they would need to do it anytime the boot structure changed.
*OK, I said “can’t imagine” but that isn’t 100% true. If a user is dual-boot’ing from a secure to a non-secure os it’s a giant hassle as you have to go disable secure boot to boot the other os. Then you have to re-enable secure to to boot the secure os. It’s actually easier to undo the secure boot on the “secure” os than try to hack-in a solution to the non-secure OS for this one scenario. My solution? Run the non-secure OS in a VM and be done with it.
I feel like we had this conversation already, last month?. LOL. But, completely agree that the extra “security” really only brings hassle for the RoonOS use case with very little, if any, upside.