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] [day] [month] [year] [list]
Message-ID: <CAMj1kXHeEjBXnfz5bx2QYX4g6o1DpFN1b6xCTey2wUcqrmMuDg@mail.gmail.com>
Date: Tue, 1 Oct 2024 15:32:50 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Hans de Goede <hdegoede@...hat.com>, 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

On Tue, 1 Oct 2024 at 14:52, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 1 Oct 2024 11:35:53 +0200
> Ard Biesheuvel <ardb@...nel.org> wrote:
>
> > All I am asking for is a line in the documentation that says that
> > clobbered trace buffers could occur at any time, regardless of whether
> > CONFIG_RESET_ATTACK_MITIGATION is enabled or not. That way, we have
> > something to refer to when people start filing bugs against the EFI
> > component when this breaks.
>
> How about if I change the comment to this?
>
>         Note, saving the trace buffer across reboots does require that the system
>         is set up to not wipe memory. For instance, CONFIG_RESET_ATTACK_MITIGATION
>         can force a memory reset on boot which will clear any trace that was stored.
>         This is just one of many ways that can clear memory. Make sure your system
>         keeps the content of memory across reboots before relying on this option.
>
> Would that be better?
>

Yes, that looks much better. Thanks.

Acked-by: Ard Biesheuvel <ardb@...nel.org>

> I want to stress that this doesn't work for every setup. It just so happens
> to work for mine and others. I do not want people thinking that it's a bug
> if it doesn't work for them.

Exactly. I can see how this feature is very useful if it happens to
work on your system firmware, but it should be documented as not being
covered by the 'no user visible regressions' policy.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ