Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221116161642.1670235-1-Jason@zx2c4.com> <Y3UlCjbhXwZG0dEH@gardel-login>
In-Reply-To: <Y3UlCjbhXwZG0dEH@gardel-login>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Wed, 16 Nov 2022 19:57:28 +0100
Message-ID: <CAHmME9o=kDEWxOZ3cjJRaypgn5C9D-G7gzfnF-A2BzNB1ESwig@mail.gmail.com>
Subject: Re: [PATCH RFC v1 0/6] Use EFI variables for random seed
To:     lennart@poettering.net
Cc:     linux-efi@vger.kernel.org, linux-crypto@vger.kernel.org,
        Ard Biesheuvel <ardb@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Nov 16, 2022 at 6:59 PM Lennart Poettering
<lennart@poettering.net> wrote:
>
> On Mi, 16.11.22 17:16, Jason A. Donenfeld (Jason@zx2c4.com) wrote:
>
> > Commit messages are rather sparse at the moment. I'll fill those out for
> > the next non-RFC patchset if this idea isn't immediately demolished.
> >
> > The biggest consideration is wear leveling on the EFI variable flash
> > chips. However, EFI *already* winds up writing to non-volatile memory on
> > every single boot anyway, so maybe it's not actually a big deal?
>
> So as mentioned elsewhere: This might (probably more than) double the
> wear on the flash chips, since firmware is unlikely to batch these
> writes with the monotonic counter write.
>
> I have no idea how realistic these issues are, there's a lot of
> handwaving involved, but to sidestep the issue I put sd-boot's seed in
> a file on disk (which should not have issues that much with wear)
> instead of efi vars.

Therein lies the rub indeed. Does anybody who knows something about
the hardware and historical hardware know for certain that this would
be a bad idea, or does it really not matter at all? Would be useful to
have some definitive advice here.

Jason