From: Steven Rostedt <rostedt@goodmis.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux trace kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Mike Rapoport <mike.rapoport@gmail.com>,
Kees Cook <keescook@chromium.org>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH] Documentation/tracing: Mention that RESET_ATTACK_MITIGATION can clear memory
Date: Tue, 1 Oct 2024 08:53:26 -0400 [thread overview]
Message-ID: <20241001085326.5841a9ce@gandalf.local.home> (raw)
In-Reply-To: <CAMj1kXGz2isSBBkm1R7DiinNt5nxELRTvrD4XXN9v_TRQrNr-A@mail.gmail.com>
On Tue, 1 Oct 2024 11:35:53 +0200
Ard Biesheuvel <ardb@kernel.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?
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.
-- Steve
next prev parent reply other threads:[~2024-10-01 12:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-26 17:01 [PATCH] Documentation/tracing: Mention that RESET_ATTACK_MITIGATION can clear memory Steven Rostedt
2024-09-26 17:54 ` Hans de Goede
2024-09-30 17:14 ` Steven Rostedt
2024-09-30 17:20 ` Jonathan Corbet
2024-09-30 17:24 ` Steven Rostedt
2024-10-01 6:17 ` Ard Biesheuvel
2024-10-01 8:56 ` Hans de Goede
2024-10-01 9:35 ` Ard Biesheuvel
2024-10-01 12:53 ` Steven Rostedt [this message]
2024-10-01 13:32 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241001085326.5841a9ce@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=ardb@kernel.org \
--cc=corbet@lwn.net \
--cc=hdegoede@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mike.rapoport@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).