linux-kernel - Re: [PATCH] Documentation/tracing: Mention that RESET_ATTACK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80930b34-3b31-46d7-8172-6c0cd2ee497f@redhat.com>
Date: Tue, 1 Oct 2024 10:56:54 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Ard Biesheuvel <ardb@...nel.org>, Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
 Linux trace kernel <linux-trace-kernel@...r.kernel.org>,
 Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Mike Rapoport <mike.rapoport@...il.com>, Kees Cook <keescook@...omium.org>,
 Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] Documentation/tracing: Mention that
 RESET_ATTACK_MITIGATION can clear memory

Hi,

On 1-Oct-24 8:17 AM, Ard Biesheuvel wrote:
> On Thu, 26 Sept 2024 at 19:02, Steven Rostedt <rostedt@...dmis.org> wrote:
>>
>> From: Steven Rostedt <rostedt@...dmis.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@...hat.com>
>> Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.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@...ce,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