Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200201233304.18322-1-ardb@kernel.org> <20200202093442.GB72728@gmail.com>
In-Reply-To: <20200202093442.GB72728@gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sun, 2 Feb 2020 10:50:39 +0100
Message-ID: <CAKv+Gu9V7hHFaFZmz=U_PP82wxP+J2rqVUasuOpvm-Jjg96OdA@mail.gmail.com>
Subject: Re: [PATCH] efi/x86: fix boot regression on systems with invalid
 memmap entries
To:     Ingo Molnar <mingo@kernel.org>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        linux-efi <linux-efi@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        =?UTF-8?Q?J=C3=B6rg_Otte?= <jrg.otte@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, 2 Feb 2020 at 10:34, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > In efi_clean_memmap(), we do a pass over the EFI memory map to remove
> > bogus entries that may be returned on certain systems.
> >
> > Commit 1db91035d01aa8bf ("efi: Add tracking for dynamically allocated
> > memmaps") refactored this code to pass the input to efi_memmap_install(=
)
> > via a temporary struct on the stack, which is populated using an
> > initializer which inadvertently defines the value of its size field
> > in terms of its desc_size field, which value cannot be relied upon yet
> > in the initializer itself.
> >
> > Fix this by using efi.memmap.desc_size instead, which is where we get
> > the value for desc_size from in the first place.
> >
> > Tested-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/x86/platform/efi/efi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 59f7f6d60cf6..ae923ee8e2b4 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -308,7 +308,7 @@ static void __init efi_clean_memmap(void)
> >                       .phys_map =3D efi.memmap.phys_map,
> >                       .desc_version =3D efi.memmap.desc_version,
> >                       .desc_size =3D efi.memmap.desc_size,
> > -                     .size =3D data.desc_size * (efi.memmap.nr_map - n=
_removal),
> > +                     .size =3D efi.memmap.desc_size * (efi.memmap.nr_m=
ap - n_removal),
> >                       .flags =3D 0,
> >               };
>
> Applied, and I also added:
>
>     Reported-by: J=C3=B6rg Otte <jrg.otte@gmail.com>
>     Tested-by: J=C3=B6rg Otte <jrg.otte@gmail.com>
>
> I presumptively added the J=C3=B6rg's Tested-by tag: won't send the commi=
t to
> Linus if he still has trouble booting the laptop.
>
> I'm still amazed GCC doesn't warn about this pattern - why?
>

Not sure - it seems it just gets confused, given that the below

int foo(void)
{
        struct {
                int i;
                int j;
        } data =3D { .j =3D 0, .i =3D data.j };

        return data.i;
}

does give me

/tmp/foo.c: In function =E2=80=98foo=E2=80=99:
/tmp/foo.c:7:30: warning: =E2=80=98data.j=E2=80=99 is used uninitialized in=
 this
function [-Wuninitialized]
  } data =3D { .j =3D 0, .i =3D data.j };
                          ~~~~^~
while the warnings go away when I reorder i and j in the struct definition.

> BTW., could we please also organize such assignments vertically as well:
>
>                         .phys_map       =3D efi.memmap.phys_map,
>                         .desc_version   =3D efi.memmap.desc_version,
>                         .desc_size      =3D efi.memmap.desc_size,
>                         .size           =3D efi.memmap.desc_size * (efi.m=
emmap.nr_map - n_removal),
>                         .flags          =3D 0,
>
> (See the patch below.)
>

Sure, I'll incorporate that.

> Had we done that earlier the weird pattern would have stuck out a lot
> more:
>
>                         .phys_map       =3D efi.memmap.phys_map,
>                         .desc_version   =3D efi.memmap.desc_version,
>                         .desc_size      =3D efi.memmap.desc_size,
>                         .size           =3D data.desc_size * (efi.memmap.=
nr_map - n_removal),
>                         .flags          =3D 0,
>
> BTW., is there a reason "struct efi_memory_map" doesn't embedd a "struct
> efi_memory_map_data"? Or is efi_memory_map firmware ABI?
>
> If they shared the structure then copying would be easier.
>

It's not firmware ABI, and even the memory map itself is not firmware
ABI apart from the early call to SetVirtualAddressMap where the
firmware consumes a memory map provided by the kernel.

I'll put this on my list of things to look at. FYI I am current doing
another pass of improvements aimed at unifying the boot flow between
architectures even more, and adding support for UEFI spec changes that
permit firmware implementations to omit certain runtime services. So
expect another couple of PRs over the coming six weeks or so