Follow

Every boot story since BIOS is hot garbage. ARM, UEFI, even RISC-V boot up is dumb as hell

1. Identify the boot storage medium
2. Copy the first sector to RAM
3. Stash any useful information in registers, like the SATA port/device number/etc
4. Jump to the boot sector

How to boot like a normal-ass adult in 4 simple steps

"But where should I put my SoC's boot up code to initialize shit and read the boot device?"

In a ROM chip mapped to address 0 and unmapped when jumping to the boot sector, you dumb dumb

"But how do I identify the boot up device?"

Use a magic number for bootable devices, provide a UI for the user to select/configure the boot media from, hell, use a dip switch to choose between eMMC and microSD, like I care

@ultem @sir Trying to remember if I've ever used a firmware application other than the firmware setup. I'm pretty sure I've only ever used the firmware setup, and even then only because the firmware has too many features and I need to tell it not to be stupid.

@sir If you don't mind I am going to formalize this all into a 1-2 page specification.

@sir Okay, took a little longer than expected to get it up on the server. I ended up having to complicate the "stash useful information in registers" step somewhat because there is no universal fixed set of useful values or register names. I made an in-memory data structure for information like host controller addresses and memory maps and "which boot device." Also I gave the boot block a fixed length of 4K so you can fit enough code. Thoughts?

alm.website/misc/specs/xsfi

@alexbuzzbee can you post your draft in the form of an email to ~sircmpwn/public-inbox@lists.sr.ht, for easier reviewing?

@sir There are tables and stuff that really don't render well in plain text. I've tried my hardest to keep my HTML as simple as possible. Do you want me to send an HTML email or try to bludgeon it into plain?

@alexbuzzbee bludgeon it into plain would be great. It's not a big deal if some of the formatting is lost, it's just a better medium for discussion.

@sir I get that. Working on getting it somewhat readable...

@sir Okay there's a little ragged alignment in the tables but it's pretty much okay.

@sir What would be the best method for tamper-resistance then?

@pyrolagus @sir All tamper-prevention systems also take control away from the user. Tamper-detection can be done with less problems, but still requires care to avoid unethical consequences.

@alexbuzzbee @pyrolagus tamper protection is bullshit. You can't defend against physical access, it's a fool's errand

@sir @alexbuzzbee I dunno, it seemed to work well when the FBI ordered Apple to unlock an iPhone. And even now it seems they can only break into iPhones 5C and older. Saying that it's impossible to defend against physical access seems pretty arrogant to me as this is as much a physics and electronic engineering question as a software engineering question.

@pyrolagus @alexbuzzbee that's just disk encryption, which works just fine with my approach too.

@sir @alexbuzzbee That doesn't protect you from bootup stage malware, which could just extract any passwords and keys necessary for decryption. But of course, I guess you could always just consider your laptop compromised if it leaves your sight and scrap it for a new one.

@pyrolagus @alexbuzzbee nothing protects you from that. Defending from physical access is a fool's errand.

@alexbuzzbee @sir They CAN take control away from the user, but that obviously depends on how they are used. You could say the same thing about encryption algorithms.

@pyrolagus @sir Not all of them completely take control away (e.g. many UEFI Secure Boot implementations allow loading custom keys), but it's essentially impossible to leave the user in full control and still provide effective tamper-prevention.

iPhones have very effective tamper-prevention, but how hard is it to install Linux on one if you decide you want to?

@alexbuzzbee @sir The usbarmory[1] allows you to "burn" a private key for secure boot into the hardware. The user has full control, but it's an irreversible process that prevents tampering. One could argue that this process takes control away from the user because they can't change the private key afterwards, but that would be a dumb argument, since the user chose to do so in the first place.

Now, granted. You will have to either keep the private key safe somewhere (which can be near impossible depending on your threat model) or you set up a system that you're confident is secure and satisfactorily configured and destroy the key. Neither is very user friendly, of course, but IMO the important thing is having the possibility to make your system tamper proof.

Apple doesn't Linux on the iPhone, so users can't install Linux on their iPhones. If you want security and convenience, the iPhone is a fantastic choice, but if you want the freedom to install whatever you wish, then it's obviously not.

[1] github.com/inversepath/usbarmo

@pyrolagus @sir User-friendliness is an important part of user control. If you have to go through a complicated process to burn in a Secure Boot key, you're less likely to try to install your own operating system.

RE: iPhones: This is exactly the ethical concern with tamper-prevention; if I own the hardware, shouldn't I be able to do what I want with it? Why do I need the vendor's approval to use a device that I own in the way I want?

@alexbuzzbee @sir > User-friendliness is an important part of user control.

I think that's a memo the open source community has yet to get. At least up till now, it's always been about providing users with all the tools necessary to do whatever they want, even if you have to be a wizard to use those tools.

> This is exactly the ethical concern with tamper-prevention;

It's a tool that can be used for good and bad. We have those since the beginning of humankind. In this case, the bad isn't disastrous enough to advocate burying this tool. And the good is actually really useful enough. Like, can save lives useful.

@sir Any opinion about stuff like OpenFirmware aka (almost specified as) IEEE 1275 ?

@sir I wasn't aware ARM and RISC-V had architectural boot protocol standards?

@alexbuzzbee they don't, and this is the reason for it being crap

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!