Re: [PATCH] Documentation/tracing: Mention that RESET_ATTACK_MITIGATION can clear memory

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 1-Oct-24 8:17 AM, Ard Biesheuvel wrote:
> On Thu, 26 Sept 2024 at 19:02, Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> From: Steven Rostedt <rostedt@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.biesheuvel@linaro.org/
>>
>> Reported-by: Hans de Goede <hdegoede@redhat.com>
>> Signed-off-by: Steven Rostedt (Google) <rostedt@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