PhilE wrote: ↑Thu Jun 04, 2020 3:13 pm
As I understand, "upstream" are wanting to discourage people from using device names to identify partitions, preferring volume labels and UUIDs instead. That is why there is no way to force a particular mmcblk index (e.g. mmcblk0) to be used on a specific MMC interface. In the downstream rpi-* trees we include a patch that sets the index based on aliases found in the DTB. Try using a PARTUUID or PARTLABEL instead.
I was under the impression it was more the Linux
distributions driving this. They like UUIDs/labels since those more reliably stay with a device even through changes. As such if hardware or drivers change, the UUIDs would remain and still survive no matter what users do.
Mostly this is a user-support issue.
For me the problem is most often
filesystem UUIDs/labels are what are being pushed. These quite reliably track the filesystem, but this becomes troublesome if you're working with VMs. If the a malicious owner of a VM manages to discover the UUIDs used by the host machine, they
could potentially cause what is supposed to be a VM to get loaded on bare hardware. At which point your VM machine is completely compromised.
This is a difficult attack to pull off (128 bits is a lot to guess), but not impossible.
swahren wrote: ↑Mon Jul 06, 2020 8:38 pm
Here are the upcoming Raspberry Pi specific features for Mainline Linux 5.8:
- proper USB support for Raspberry Pi 4 boards without separate VL805 EEPROM
Other items which showed up by 5.6 included ACPI support for most of the drivers used. Suddenly the Tianocore implementation becomes viable.
Question which arises is, how far does the boot firmware go to deal with the VL805 firmware issue? Is it reliable enough to get U-Boot operational with USB booting? Does it last long enough for U-Boot to load GRUB and GRUB to load a kernel?