From: Ard Biesheuvel <ardb@kernel.org>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel-dev@igalia.com, kernel@gpiccoli.net,
Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>,
Kees Cook <keescook@chromium.org>,
Matt Fleming <matt@codeblueprint.co.uk>,
Matthew Garrett <matthew.garrett@nebula.com>,
Tony Luck <tony.luck@intel.com>,
linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH 0/2] UEFI panic notification mechanism
Date: Tue, 28 Jun 2022 09:49:56 +0200 [thread overview]
Message-ID: <CAMj1kXFDqhvE3R4ckD32ftkb66CjHZcGPCF0OsX6bev2MmnorA@mail.gmail.com> (raw)
In-Reply-To: <d3dd4f45-1d50-2164-447b-d4f27ac6e133@igalia.com>
On Thu, 2 Jun 2022 at 19:40, Guilherme G. Piccoli <gpiccoli@igalia.com> wrote:
>
> Hi Ard, apologies for annoying!
>
No worries, just very busy :-)
> Just a friendly ping asking if you have any opinions about these patches.
>
Honestly, I'm not sure I see the value of this. You want to 'notify
the UEFI firmware' but the firmware doesn't really care about these
variables, only your bespoke tooling does. EFI pstore captures far
more data, so if you just wipe /sys/fs/pstore after each clean boot,
you already have all the data you need, no?
Also, I'm in the process of removing the public efivar_entry_xxx() API
- please look at the efi/next tree for a peek. This is related to your
point 3), i.e., the efivar layer is a disaster in terms of consistency
between different observers of the EFI variable store. Switching to
efivar_set_variable() [the new API] should fix that.
next prev parent reply other threads:[~2022-06-28 7:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 19:50 Guilherme G. Piccoli
2022-05-20 19:50 ` [PATCH 1/2] efi: Add a generic helper to convert strings to unicode Guilherme G. Piccoli
2022-05-20 19:50 ` [PATCH 2/2] efi-panic: Introduce the UEFI panic notification module Guilherme G. Piccoli
2022-06-02 17:39 ` [PATCH 0/2] UEFI panic notification mechanism Guilherme G. Piccoli
2022-06-28 7:49 ` Ard Biesheuvel [this message]
2022-06-28 18:10 ` Guilherme G. Piccoli
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=CAMj1kXFDqhvE3R4ckD32ftkb66CjHZcGPCF0OsX6bev2MmnorA@mail.gmail.com \
--to=ardb@kernel.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=gpiccoli@igalia.com \
--cc=keescook@chromium.org \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=matthew.garrett@nebula.com \
--cc=tony.luck@intel.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
all inboxes | Powered by JetHome®