Note that the mitigation can cause some issues, see https://bugzilla.redhat.com/show_bug.cgi?id=1532058 

To get the mitigation working, we would need:
 - boot config enabled in kernel
 - some user space enablement of the kernel feature (toggling the UEFI variable) when booting and when shutting down the system.

Userspace components are flaky - what guarantees that the userspace
component will really do its job on shutdown?

I see a link to a systemdoofus service file which writes 0..-something
into that MemoryOverwriteRequestControl variable. I wonder if this can
be made more robust by doing this in the kernel.

Also, this solution is only for EFI boxes.

(In reply to Borislav Petkov from comment #2)
> Userspace components are flaky - what guarantees that the userspace
> component will really do its job on shutdown?

How can we ensure system being rebooted is in a "clean" state. I'm not sure kernel can ensure this, without any input from userside.

> I see a link to a systemdoofus service file which writes 0..-something
> into that MemoryOverwriteRequestControl variable. I wonder if this can
> be made more robust by doing this in the kernel.

See above.

> Also, this solution is only for EFI boxes.

Vulnerability in question is for UEFI boxes (which is the standard for any new intel hardware since a few years now).

(In reply to Frederic Crozat from comment #3)
> How can we ensure system being rebooted is in a "clean" state. I'm not
> sure kernel can ensure this, without any input from userside.

Maybe I'm missing something but I think it would be much more reliable
if, when shutting the machine down, the kernel would do that 0 write
into the EFI variable and not userspace, or?

> Vulnerability in question is for UEFI boxes (which is the standard for any
> new intel hardware since a few years now).

Ah, I guess "in some firmware implementations" means EFI. Ok.

Thx.

(In reply to Borislav Petkov from comment #4)
> (In reply to Frederic Crozat from comment #3)
> > How can we ensure system being rebooted is in a "clean" state. I'm not
> > sure kernel can ensure this, without any input from userside.
> 
> Maybe I'm missing something but I think it would be much more reliable
> if, when shutting the machine down, the kernel would do that 0 write
> into the EFI variable and not userspace, or?

It could (remember, I'm not a specialist here).

As mentioned in the original patch for the mitigation https://lkml.org/lkml/2017/8/4/606 :

"If a machine is reset while secrets are present in RAM, it may be
possible for code executed after the reboot to extract those secrets
from untouched memory. The Trusted Computing Group specified a mechanism
for requesting that the firmware clear all RAM on reset before booting
another OS. This is done by setting the MemoryOverwriteRequestControl
variable at startup. If userspace can ensure that all secrets are
removed as part of a controlled shutdown, it can reset this variable to
0 before triggering a hardware reboot."

We only need the mitigation when secrets are still "around" in memory..

"If userspace can ensure that all secrets are removed as part of a
controlled shutdown..."

I'm sceptical userspace can ensure in all cases that its memory has
been purged properly. Especially since memory pages are cached a
gazillion ways in the kernel. So I guess all application memory needs
to be anonymous pages which really get freed and scrubbed before reuse
immediately.

Lemme add mm guys to CC who can correct me here.

(In reply to Borislav Petkov from comment #6)
> "If userspace can ensure that all secrets are removed as part of a
> controlled shutdown..."
> 
> I'm sceptical userspace can ensure in all cases that its memory has
> been purged properly. Especially since memory pages are cached a
> gazillion ways in the kernel. So I guess all application memory needs
> to be anonymous pages which really get freed and scrubbed before reuse
> immediately.

Userspace should always get zeroed or data filled data. If not then it is a bug no matter the initial state of the system. It is a plain memory leak and fixed as discovered. There is no guarantee of course because of bugs but fundamentally no uninitialized memory should ever leak to the userspace.

Ok, so then this doesn't qualify as a kernel bug, right?

AFAICT, all this needs a proper documentation somewhere that userspace should
set the EFI variable properly...

Ok, this doesn't move and doesn't look like a kernel issue, bouncing back to sec team until we figure it out.

I am affected by the reboot issue described in the linked bug on the Redhat bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1532058) and was able to resolve it by adding the systemd unit file linked in that bug report.

Since this causes issues with some hardware is it possible to either (a) revert this change in the kernel or (b) ship actual userspace support for this option?

Seems like we have some progress here. Boris could you please give your opinion about the mitigation [0]?

[0] https://gist.github.com/ValdikSS/86352b03ec3ed3c8713b78c7e20dc222

I guess, but its Kconfig text says:

"This should only be enabled when userland is configured to
clear the MemoryOverwriteRequest flag on clean shutdown after secrets
have been evicted, since otherwise it will trigger even on clean
reboots."

so I guess that systemd service file should check whether we have CONFIG_RESET_ATTACK_MITIGATION enabled in the underlying kernel or however systemd checks for required kernel features before running a service.

Re-assigning back to the security team as this issue is not specific to systemd AFAICS.