From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] efivarfs: Expose RandomSeed variable but with limited permissions
Date: Sun, 25 Jun 2023 16:44:26 +0200 [thread overview]
Message-ID: <ZJhSysqUcxOqh37n@zx2c4.com> (raw)
In-Reply-To: <20230624180446.2048867-1-ardb@kernel.org>
On Sat, Jun 24, 2023 at 08:04:46PM +0200, Ard Biesheuvel wrote:
> The efivarfs pseudo-filesystems exposes all EFI variables as
> world-readable, and carries some logic to prevent accidental deletion
> from bricking a system, by setting the immutable flag on all variables
> whose purpose is unknown.
>
> When the RandomSeed support was added, we decided not to expose this
> variable via efivarfs at all, given that the kernel itself was intended
> to both produce and consume it directly, without involvement from user
> space. This removed the need to deal with the world-readable default
> permissions (which would be undesirable for the random seed that will be
> used on the next boot), as this would require special handling of the
> RandomSeed variable, given that we cannot restrict those permissions for
> all EFI variables without running the risk of breaking user space.
>
> Now that the producer side of this mechanism has been reverted [0], it
> is no longer possible to set the RandomSeed variable at all. Whether
> and how we will replace the in-kernel producer with something more
> robust is still under discussion, but in the mean time, let's relax the
> efivarfs restriction on any direct access of the variable, and instead,
> ensure that it is created as user read-write only, both when the EFI
> varstore is enumerated (at mount time) and when the file is created
> explicitly by user space.
>
> Also ensure that the file is not created with the immutable flag set so
> that user space can manipulate the file as usual.
Hm, I'm still not so sure we want to open the pandora's box of having to
deal with userspaces writing this. Maybe we can keep it in the kernel
but delay it until a little later in boot so it doesn't cause an
outright bootup hang? Or just bite the bullet and do it at shutdown? I
think I'd prefer just doing it in a delayed workqueue in late/post boot
though.
(On the topic of this patch, technically this only needs to be
write-only, not read-write, right?)
Jason
next prev parent reply other threads:[~2023-06-25 14:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-24 18:04 [PATCH] efivarfs: Expose RandomSeed variable but with limited permissions Ard Biesheuvel
2023-06-25 14:44 ` Jason A. Donenfeld [this message]
2023-06-25 19:21 ` Linus Torvalds
2023-06-25 19:58 ` Ard Biesheuvel
2023-06-26 13:50 ` Jason A. Donenfeld
2023-06-26 15:15 ` Sami Korkalainen
2023-06-26 15:23 ` Jason A. Donenfeld
2023-06-26 20:20 ` Sami Korkalainen
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=ZJhSysqUcxOqh37n@zx2c4.com \
--to=jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.