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: <CAMj1kXF1=2wLgM8HP6BvUxdZLK4EdnaORLUTjoDJSZP-hhDJwA@mail.gmail.com>
Date: Tue, 1 Oct 2024 08:17:37 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: 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>, Hans de Goede <hdegoede@...hat.com>, 
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] Documentation/tracing: Mention that RESET_ATTACK_MITIGATION
 can clear memory

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.

As I indicated when this feature was under review, it should be made
very clear that any kernel side changes that affect the system's
behavior in this regard should not be considered regressions. So
instead of mentioning CONFIG_RESET_ATTACK_MITIGATION here, perhaps it
would be better to document that system firmware generally makes no
guarantees about preserving memory contents, and so this feature may
break without warning.

Note that on UEFI systems, there is a so-called 'capsule' interface
which does allow the OS to preserve an arbitrary buffer across a warm
reboot. However, whether it works on all systems is anybody's guess.