Hi, On 1-Oct-24 8:17 AM, Ard Biesheuvel wrote: > On Thu, 26 Sept 2024 at 19:02, Steven Rostedt <rost...@goodmis.org> wrote: >> >> From: Steven Rostedt <rost...@goodmis.org> >> >> At the 2024 Linux Plumbers Conference, I was talking with Hans de Goede >> about the persistent buffer to display traces from previous boots. He >> mentioned that UEFI can clear memory. In my own tests I have not seen >> this. He later informed me that it requires the config option: >> >> CONFIG_RESET_ATTACK_MITIGATION >> >> It appears that setting this will allow the memory to be cleared on boot >> up, which will definitely clear out the trace of the previous boot. >> >> Add this information under the trace_instance in kernel-parameters.txt >> to let people know that this can cause issues. >> >> Link: >> https://lore.kernel.org/all/20170825155019.6740-2-ard.biesheu...@linaro.org/ >> >> Reported-by: Hans de Goede <hdego...@redhat.com> >> Signed-off-by: Steven Rostedt (Google) <rost...@goodmis.org> >> --- >> Documentation/admin-guide/kernel-parameters.txt | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt >> b/Documentation/admin-guide/kernel-parameters.txt >> index bb48ae24ae69..f9b79294f84a 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -6850,6 +6850,9 @@ >> >> reserve_mem=12M:4096:trace >> trace_instance=boot_map^traceoff^traceprintk@trace,sched,irq >> >> + Note, CONFIG_RESET_ATTACK_MITIGATION can force a >> memory reset on boot which >> + will clear any trace that was stored. >> + > > CONFIG_RESET_ATTACK_MITIGATION can force a wipe of system RAM at warm > reboot on systems that have a TPM enabled, but disabling it does not > prevent it. Also, there are many other reasons why the trace buffer > region may be wiped and/or reused for other purposes, so singling out > CONFIG_RESET_ATTACK_MITIGATION like this is not that useful imo.
Since the userspace parts to clear the CONFIG_RESET_ATTACK_MITIGATION related EFI variable after cleaning cryptographic keys from RAM has never materialized CONFIG_RESET_ATTACK_MITIGATION is pretty much guaranteed to clear any traces on any modern machine (and at least in Fedora's kernel config it is disabled because of this). I agree that there are more ways the RAM might get cleared, but since this will clear the RAM almost 100% of the time it is worth documenting this IMHO. I get the feeling you (Ard) see documenting this as some sorta bug report against CONFIG_RESET_ATTACK_MITIGATION, that is not the intention. Quite the opposite the documentation is there to let the user know that CONFIG_RESET_ATTACK_MITIGATION works as advertised and that it will (almost) always clear the RAM on reboot and thus conflicts with keeping traces over reboot. Regards, Hans
