[RFC] efibootguard faile-safe mode

[Andreas Reichel]

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.

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?

Cheers,
Andreas

--
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas...@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

[Claudius Heine]

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.

Cheers,
Claudius

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de

[Jan Kiszka]

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

[Andreas Reichel]

Just as info - working on it.