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;
Date:   Mon, 28 Nov 2022 02:12:38 +0100
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Matthew Garrett <mjg59@srcf.ucam.org>
Cc:     linux-efi@vger.kernel.org, linux-crypto@vger.kernel.org,
        patches@lists.linux.dev, linux-kernel@vger.kernel.org,
        ardb@kernel.org
Subject: Re: [PATCH v3 2/5] efi: stub: use random seed from EFI variable
Message-ID: <Y4QLBnoJGUoqwo4p@zx2c4.com>
References: <20221122020404.3476063-1-Jason@zx2c4.com>
 <20221122020404.3476063-3-Jason@zx2c4.com>
 <20221127211244.GB32253@srcf.ucam.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20221127211244.GB32253@srcf.ucam.org>
Precedence: bulk

Hi,

On Sun, Nov 27, 2022 at 09:12:44PM +0000, Matthew Garrett wrote:
> On Tue, Nov 22, 2022 at 03:04:01AM +0100, Jason A. Donenfeld wrote:
> 
> > +		 * We delete the seed here, and /hope/ that this causes EFI to
> > +		 * also zero out its representation on disk. This is somewhat
> 
> Several implementations I've worked with simply append a deletion marker 
> or append a new variable value until the variable store fills up 
> entirely, at which point a garbage collection event is either run or 
> scheduled for the next reboot. The spec doesn't define how this is 
> handled so unfortunately I don't think there's any way to get a pony 
> here.

Yea this is a bummer. During my first attempt at this, I actually
overwrote the whole thing with zeros and then deleted it. But Ard
pointed out that this doesn't make a difference anyway. But, as it turns
out, that's more or less the same thing that happens with seed files on
SSDs (nobody calls fstrim after overwriting a seed file). So at the very
least, it's no worse?

Jason