On 2018-03-22 13:11, [ext] Claudius Heine wrote: > > > On 03/22/2018 11:24 AM, Andreas Reichel wrote: >> Hi, >> >> I would like to discuss the following idea: >> >> Assume a system, where efibootguard (ebg) is installed. The system >> contains two config partitions and ebg expects exactly two. >> >> Now assume, the user did something wrong and destroyed both root file >> systems then efibootguard will boot the kernel, which then panics and >> the user has no access anymore. > > I would only be necessary if the currently loaded root file system gets > corrupted after it was acknowledged by bg_setenv -c. > >> >> If however, the user generates an alternative boot medium with ebg as >> well, the config partitions on the device are also detected and ebg from >> the alternative boot medium detects more than two environments and >> refuses to boot as well. >> >> This is expected behavior due to security reasons: If internal ebg would >> boot and a user would add a stick with a contaminated environment, then >> the internal ebg could boot this environment if the number of >> environments would not be fixed to the expected one. >> >> The only solution at the moment is to use a boot medium with an >> alternative boot loader. >> >> A nicer idea however could be to add a new configure option to >> configure efibootguard with a fixed internal environment. This way, it >> might be easier for a user to generate a recovery stick. >> >> Like ./configure --with-failsafe-env >> >> Kernel could then just be sought on the efibootguard partition. >> >> Opinions? > > IMO it would be nice to have some sort of recovery mechansims that > allows the maintenance technican to just plug an usb stick into the > device and then the newest firmware is deployed to a possible broken > system. > > As Andreas stated, this usb stick would currently need to use a > different bootloader and this makes the project setup more difficult. It > would be nice IMO if efibootguard would also support this somehow as well.
Indeed. Andreas and I discussed this offline yesterday. The idea that came out of this: - have two types of environments, normal and rescue - make sure bootloader first checks for environments on the same medium it is loaded from (are there means to ensure that?) - evaluate the type of that first environment - when scanning for further environments, only stay on the bootloader medium if that type was "rescue" - if there is no environment on the bootloader medium, assume "normal type" That would ensure: - a normal installation of efibootguard would not evaluate rescue envs - a rescue installation, e.g. on a stick, would only evaluate rescue envs on the very same medium Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/b3c2f314-b67b-9692-3156-45fd56bc3109%40siemens.com. For more options, visit https://groups.google.com/d/optout.
