Re: [PATCH v3 5/8] linux/arm: account for COFF headers appearing at unexpected offsets

2022-09-04 Thread Ard Biesheuvel
On Fri, 2 Sept 2022 at 12:02, Heinrich Schuchardt
 wrote:
>
> On 8/18/22 16:51, Ard Biesheuvel wrote:
> > The way we load the Linux and PE/COFF image headers depends on a fixed
> > placement of the COFF header at offset 0x40 into the file. This is a
> > reasonable default, given that this is where Linux emits it today.
> > However, in order to comply with the PE/COFF spec, which allows this
> > header to appear anywhere in the file, let's ensure that we read the
> > header from where it actually appears in the file if it is not located
> > at offset 0x40.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >   grub-core/loader/arm64/linux.c | 15 +++
> >   1 file changed, 15 insertions(+)
> >
> > diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
> > index 7c0f17cf933d..56ba8d0a6ea3 100644
> > --- a/grub-core/loader/arm64/linux.c
> > +++ b/grub-core/loader/arm64/linux.c
> > @@ -63,6 +63,21 @@ grub_arch_efi_linux_load_image_header (grub_file_t file,
> > grub_dprintf ("linux", "UEFI stub kernel:\n");
> > grub_dprintf ("linux", "PE/COFF header @ %08x\n", lh->hdr_offset);
> >
> > +  /*
> > +   * The PE/COFF spec permits the COFF header to appear anywhere in the 
> > file, so
> > +   * we need to double check whether it was where we expected it, and if 
> > not, we
> > +   * must load it from the correct offset into the coff_image_header field 
> > of
> > +   * struct linux_arch_kernel_header.
> > +   */
> > +  if ((grub_uint8_t *) lh + lh->hdr_offset != (grub_uint8_t *) 
> > &lh->coff_image_header)
> > +{
> > +  grub_file_seek (file, lh->hdr_offset);
> > +
> > +  if (grub_file_read (file, &lh->coff_image_header, sizeof(struct 
> > grub_coff_image_header))
> > + != sizeof(struct grub_coff_image_header))
> > +   return grub_error(GRUB_ERR_FILE_READ_ERROR, "failed to read COFF 
> > image header");
> > +}
>
> Why do we use multiple reads? We need the whole binary for booting.

We need multiple reads because the PE/COFF header describes the
mapping from file offsets to memory offsets - even if Linux kernels
generally use a 1:1 mapping between the location of a PE/COFF section
in the file and in memory, the PE/COFF spec does not require this at
all.

So reading the whole file into memory might require multiple
memcpy/memmove calls to rearrange the copied file in memory so it
matches the section layout as the header describes it.

Therefore, reading just the header is a reasonable thing to do here.
And note that the second read only happens when the header layout
deviates from the expected default.

> Reading the complete file into memory once should be good enough. But
> that seems to be more a question of overall design.
>
> In grub_efi_modules_addr() the same logic is needed.

Not really. grub_efi_modules_addr() is only used to load GRUB's own
PE/COFF image, and its layout is known a priori. So having this logic
there is essentially dead code.

> It is not ARM
> specific. Please, move it to a common code module.
>

That makes sense - I'll move it to an appropriate common source file.


> > return GRUB_ERR_NONE;
> >   }
> >
>

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v4 1/2] lsefi: fixed memory leaks

2022-09-04 Thread Glenn Washburn
On Thu,  1 Sep 2022 09:28:53 +0200
Renaud Métrich  wrote:

> Signed-off-by: Renaud Métrich 
> ---
>  grub-core/commands/efi/lsefi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/grub-core/commands/efi/lsefi.c b/grub-core/commands/efi/lsefi.c
> index f46ba3b49..241be79f9 100644
> --- a/grub-core/commands/efi/lsefi.c
> +++ b/grub-core/commands/efi/lsefi.c
> @@ -136,8 +136,12 @@ grub_cmd_lsefi (grub_command_t cmd __attribute__ 
> ((unused)),
>(unsigned) protocols[j]->data4[7]);
>   }
>  
> +  if (protocols)
> + grub_efi_free_pool (protocols);

This has the same issue that Daniel mentioned on a prior version of
this series, namely that GRUB has no function named
grub_efi_free_pool(). I think it would be a good idea to add one
though. In the future, I recommend rebasing your patches onto the GRUB
master branch before submitting patches to the list. It appears as
though you're still using a branch with Redhat specific patches on it.

Glenn

>  }
>  
> +  grub_free (handles);
> +
>return 0;
>  }
>  

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel