Message-ID: <CAL_JsqLpKvw73ry+Dmy=uzOopQ4BgbH3qn7gsuj4+RGAD3UY4A@mail.gmail.com>
Date: Tue, 22 Apr 2025 06:55:31 -0500
From: Rob Herring <robh@...nel.org>
To: "Szczepanek, Bartosz" <bsz@...zon.de>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Saravana Kannan <saravanak@...gle.com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "Graf (AWS), Alexander" <graf@...zon.de>, 
	Schönherr, Jan H. <jschoenh@...zon.de>
Subject: Re: [PATCH] fdt: arch/arm64: Delete the rng-seed property after use

On Tue, Apr 15, 2025 at 3:52 AM Szczepanek, Bartosz <bsz@...zon.de> wrote:
>
> > From: Rob Herring <robh@...nel.org>
> > Sent: Monday, April 14, 2025 4:22 PM
> > To: Szczepanek, Bartosz
> >
> > On Mon, Apr 14, 2025 at 3:33 AM Bartosz Szczepanek <bsz@...zon.de> wrote:
> > >
> > > As a part of platform boot, device tree is being read to extract
> > > randonmess bits. The 'rng-seed' property is used for that purpose.
> > > After reading the value, the field was overridden with NOP instead of
> > > being deleted or zeroed. The problem is that NOPed fields are later not
> > > reused, and kexec code appended this property every time DTB is prepared:
> > >
> > >   /* add rng-seed */
> > >   if (rng_is_initialized()) {
> > >           void *rng_seed;
> > >           ret = fdt_setprop_placeholder(dtb, off, FDT_PROP_RNG_SEED,
> > >                           RNG_SEED_SIZE, &rng_seed);
> > >           if (ret)
> > >                   goto out;
> > >           get_random_bytes(rng_seed, RNG_SEED_SIZE);
> > >   }
> > > (source: arch/arm64/kernel/machine_kexec_file.c)
> > >
> > > Taken together, DTB grew at each kexec by 140 bytes ie. size of the
> > > newly added (and not overwritten) rng-seed property. ARM64 sets a hard
> > > limit on FDT size at 2MB, which means that after at most 14,979 kexecs
> > > DTB exceeded the limit causing catastrophic (but silent) failure in
> > > setup_machine_fdt().
> >
> > Just like 2MB should be enough for anyone, 14979 kexecs should be enough. ;)
>
> I'm actually glad it wasn't more than that, I'm afraid if it were 149790 I would
> be still scratching my head about the occasional crashes out of nowhere (:
>
> >
> >
> > > This commits addresses the issue as follows:
> > >  1. Call to fdt_nop_property is replaced with overwriting the rng-seed
> > >     value with zeros.
> > >  2. Zeroed rng-seed gets special treatment and is not accepted as valid
> > >     seed. Warning is emitted on zeroed value.
> >
> > How do you get a zeroed seed if you delete the property when zeroed?
> > Sure, any random bootloader could do that, but that has nothing to do
> > with kexec. And does it really hurt to add 0s to the random pool? A
> > warning is fine. In any case, none of this is specific to DT seeds. It
> > all belongs in the core if it is a problem.
>
> You're right that zeroed property should never get to early_init_dt_scan_chosen.
> If the outgoing kernel can't give us randomness, it removes the previously
> zeroed "rng-seed". So it's an extra check and we could perhaps do without it.
>
> As for whether it hurts to add zeros to random pool, I actually wanted to avoid
> any doubts about security by handling that case explicitly. We can make it a
> mere warning if you like but I thought that illusion of randomness is worse
> than lack of randomness from a security standpoint. If we bail out on zeros,
> we are sure that under no circumstances we get misguided by "rng-seed" that is
> there but doesn't bring us actual entropy.

My point is your reasoning is true for all other callers of
add_bootloader_randomness(), so shouldn't all of them be handled the
same way? What guarantee do we have that UEFI implementation doesn't
give us all zeros too? We know it can happen since we're also
implementing the bootloader in this case, but that's not much better
than not knowing. And there is the 'trust_bootloader' flag too. Do we
want to warn about the bootloader seed if trust_bootloader==false?
There's also the minor issue that in 1-in-a-gazillion times, the
random value is all 0s. Does that matter? IDK. Really, you should ask
the folks that implemented this feature in the first place.


> > >  3. Kexec_file code is modified to delete the zeroed property if it
> > >     can't fill it with valid seed.
> > >  4. Proper error handling is added for the case when DTB exceeds 2MB.
> > >
> > > The change was tested in QEMU arm64 environment. To do so, kernel
> > > containing the change was built and included in buildroot initramfs.
> > > Subsequently, kernel was started in QEMU. Using kexec_file, new kernel
> > > was loaded and kexec reboot was issued. DTB size was noted in this step.
> > > After new kernel has booted, another kexec_file was issued. DTB size
> > > was confirmed not to change.
> > >
> > > Signed-off-by: Bartosz Szczepanek <bsz@...zon.de>
> > > ---
> > >  arch/arm64/kernel/machine_kexec_file.c |  5 +++++
> > >  drivers/of/fdt.c                       | 18 +++++++++++++++---
> > >  drivers/of/kexec.c                     | 12 +++++++++++-
> > >  3 files changed, 31 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > index af1ca875c52c..af0e39f6c96d 100644
> > > --- a/arch/arm64/kernel/machine_kexec_file.c
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -170,6 +170,11 @@ int load_other_segments(struct kimage *image,
> > >         /* trim it */
> > >         fdt_pack(dtb);
> > >         dtb_len = fdt_totalsize(dtb);
> > > +       if (dtb_len > MAX_FDT_SIZE) {
> > > +               pr_err("DTB exceeds the maximum size: 0x%lx > 0x%x", dtb_len, MAX_FDT_SIZE);
> >
> > You can't check restrictions of the kexec'ed kernel in the current
> > kernel. That restriction could be removed at any point and might not
> > be a problem for the kexec'ed kernel.
>
> Fair point.
>
> What would you say then for making it a warning? That could be a middle ground
> that would 1) allow us to kexec into more capable kernel without restriction,
> but also 2) help avoid lengthy investigations about early_init_dt_scan_chosen
> failures. Keep in mind that the function is so early that early consoles are
> not plugged in, so from reader perspective it's "Bye!" from the outgoing kernel
> followed by eternal silence.

Well, I checked DTBs in the tree and the biggest is 178K, so we are a
lot further off from this being a problem than I thought. So I guess a
warning would be fine.

Rob

Powered by blists - more mailing lists