phcoder wrote: > But consider a scenario when attacker can't overwrite the existing > harddrive but can plug new one. Then the attacker can prepare a > harddrive having a partition with the same UUID as our boot partition. > Then he plugs it and depnding on factors like order of interfaces, > devices, phase of the moon, ... GRUB can load attacker's modules. While > it's ok to use UUID on personal desktop system when attacker can't plug > his devices it shouldn't be the default.
That is a valid point. Would you prefer to use hardware path to device or what you had in mind then? Because this is something that we can left for expert people. Most common problem is that user plugs in new drive to system and bios/hardware order gets changed or something like that, and that renders system unbootable. UUID is perfect solution for that case. Possibilites are there, but basically they are limited to something like: (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0) I do not know if those all would be valid, but I hope you get the idea. Alternative would be that you integrate some module to core that validates your system that there is no extra devices or such. Thanks, Vesa Jääskeläinen _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
