Bug 11030

In addition to preventing reading the DB from the VFAT system partition when Secure Boot is active, please consider supporting a DB that is embedded inside the UEFI combo app. That DB can remain active.

submitted to meta-intel:
https://lists.yoctoproject.org/pipermail/meta-intel/2017-February/004625.html

(In reply to comment #1)
> In addition to preventing reading the DB from the VFAT system partition when
> Secure Boot is active, please consider supporting a DB that is embedded
> inside the UEFI combo app. That DB can remain active.

I don't remember whether this was discussed. I thought it had been implemented, but current refkit code still deploys rmc.db separately.

Populating /boot with additional files is problematic for system update, because we only have support in place for updating the combo app, but not for additional files. So the rmc.db isn't going to get updated on devices.

We probably need a new feature request (either for embedding rmc.db or for supporting in in system update), depending on how we want to handle this.

(In reply to comment #3)
> (In reply to comment #1)
> > In addition to preventing reading the DB from the VFAT system partition when
> > Secure Boot is active, please consider supporting a DB that is embedded
> > inside the UEFI combo app. That DB can remain active.
> 
> I don't remember whether this was discussed. I thought it had been
> implemented, but current refkit code still deploys rmc.db separately.
> 

The patch was sent out (see Comment #2) but Saul did not merge it. The reasons are probably obsolete by now so the patch can probably rebased.

Saul, what do you think?

The existing patch is still applicable to meta-intel but it has not been applied. Also, a tool/script is available to update uefi combo app elements.

Re-assign to meta-intel.

https://lists.yoctoproject.org/pipermail/meta-intel/2017-February/004625.html

This patch had been proposed, but had some discussion that Todor can maybe add additional info to here.

This patch assumes that rmb.db will be always build into the systemd-boot STUB. If we are not going to support standalone rmb.db files on the EFI partition, then this should be safe to merge. Otherwise we need to have a mechanism to differentiate between running in secureboot mode when rmc.db can be read only from the .rmc section of systemd-boot and non-secureboot mode when it can be read from both the .rmc section of systemd-boot and the EFI partition.

(In reply to comment #8)
> This patch assumes that rmb.db will be always build into the systemd-boot

That's not exactly true. The patched stub checks whether ".rmc" section is there
or not and behaves accordingly. With this patch applied, it's still possible to run UEFI combo app without the .rmc section built in.

> STUB. If we are not going to support standalone rmb.db files on the EFI
> partition, then this should be safe to merge. Otherwise we need to have a
> mechanism to differentiate between running in secureboot mode when rmc.db
> can be read only from the .rmc section of systemd-boot and non-secureboot
> mode when it can be read from both the .rmc section of systemd-boot and the
> EFI partition.

IMO, it's much better to always keep .rmc built in the uefi combo app. That's where all other boot artifacts are kept too.

One of the reasons the patch was not put on hold was the concern about rmc.db updateability on the target. I wrote a script to address the use case where UEFI-combo app is used + rmc.db (or some other section, e.g., .cmdline) needs to be changed but never pushed it for a review. Let me attach it here if it helps.

The script could be installed in rmc-tools package.

Created attachment 4128 [details]
script: change EFI blob sections

Attached the script mentioned in comment #9

Work on RMC has been discontinued and it is no longer supported.