On Sat, 30 Nov 2024 at 22:46, Mike Gilbert wrote:
>
> ms_abi is not a valid attribute on x32 (__x86_64__ && __ILP32__).
> This ABI should be unnecessary for utils anyway.
>
These utils are host tools, right? E.g., grub-install, update-grub,
etc running under the OS?
Why are those using headers t
On Wed, 3 Jul 2024 at 16:25, Jan Čermák wrote:
>
> Hi Ard
>
> On 28. 06. 24 19:28, Ard Biesheuvel wrote:
> > Given that you carry your own GRUB build, I would recommend reverting
> > to non-EFI stub boot for affected Atom systems, identified by DMI
> > data, which sh
On Thu, 27 Jun 2024 at 12:27, Jan Čermák wrote:
>
> Hi Ard,
>
> sorry, I feel a little ashamed for replying after such a long time but I
> wanted to do some due diligence first and didn't have time (or the Atom
> board around) until now.
>
> > Does your Kconfig have EFI_DISABLE_PCI_DMA enabled by
On Thu, 16 May 2024 at 14:24, Jan Čermák wrote:
>
> Hi Ard, everyone,
>
> On 23. 05. 23 17:31, Ard Biesheuvel wrote:
> > Switch the x86 based EFI platform builds to the generic EFI loader,
> > ...
>
> We use GRUB as the loader for the Home Assistant Operating Syste
On Sat, 27 Apr 2024 at 15:08, Glenn Washburn
wrote:
>
> From: Ard Biesheuvel
>
> The 'ground truth' stack protector cookie value is kept in a global
> variable, and loaded in every function prologue and epilogue to store
> it into resp. compare it with the stack slo
From: Ard Biesheuvel
The 'ground truth' stack protector cookie value is kept in a global
variable, and loaded in every function prologue and epilogue to store
it into resp. compare it with the stack slot holding the cookie.
If the comparison fails, the program aborts, and this m
On Mon, 1 Jan 2024 at 03:52, Glenn Washburn wrote:
>
> On Sun, 31 Dec 2023 11:56:18 +0100
> Ard Biesheuvel wrote:
>
> > Hi Glenn,
> >
> > On Thu, 28 Dec 2023 at 03:26, Glenn Washburn
> > wrote:
> > >
> > > On Sat, 23 Dec 2023 12:
Hi Glenn,
On Thu, 28 Dec 2023 at 03:26, Glenn Washburn
wrote:
>
> On Sat, 23 Dec 2023 12:45:35 +0100
> Ard Biesheuvel via Grub-devel wrote:
>
> > From: Ard Biesheuvel
> >
> > The 'ground truth' stack protector cookie value is kept in a global
> > v
From: Ard Biesheuvel
The 'ground truth' stack protector cookie value is kept in a global
variable, and loaded in every function prologue and epilogue to store
it into resp. compare it with the stack slot holding the cookie.
If the comparison fails, the program aborts, and this m
On Thu, 3 Aug 2023 at 15:24, Ard Biesheuvel wrote:
>
> The x86_64 Linux kernel can be booted in 32-bit mode, in which case the
> startup code creates a set of preliminary page tables that map the first
> 1GiB of physical memory 1:1, and enables paging. This is a prerequisite
this
ably needed to support other users of Linux protocol
>
> If somebody needs that thing they can add it later.
>
> For now Reviewed-by: Daniel Kiper ...
>
> Though...
>
> > Le lun. 21 août 2023, 20:12, Ard Biesheuvel a écrit :
> > On Thu, 3 Aug 2023 at 15:24, A
On Wed, 13 Sept 2023 at 13:42, Vladimir 'phcoder' Serbinenko
wrote:
>
>
>
> Le mer. 13 sept. 2023, 12:33, Ard Biesheuvel a écrit :
>>
>> On Wed, 13 Sept 2023 at 12:18, John Paul Adrian Glaubitz
>> wrote:
>> >
>> > Hi Oliver!
>>
On Wed, 13 Sept 2023 at 12:18, John Paul Adrian Glaubitz
wrote:
>
> Hi Oliver!
>
> On Wed, 2023-09-13 at 12:14 +0200, Oliver Steffen wrote:
> > On Wed, Sep 13, 2023 at 6:10 AM Pedro Miguel Justo wrote:
> > >
> > >
> > > I can confirm that, taking [1][2] and making [3] on top of it, my
> > > Mont
On Mon, 21 Aug 2023 at 20:10, Ard Biesheuvel wrote:
>
> On Thu, 3 Aug 2023 at 15:24, Ard Biesheuvel wrote:
> >
> > The x86_64 Linux kernel can be booted in 32-bit mode, in which case the
> > startup code creates a set of preliminary page tables that map the first
> &g
On Wed, 30 Aug 2023 at 21:07, Vladimir 'phcoder' Serbinenko
wrote:
>
>
>
> Le mer. 30 août 2023, 16:38, Daniel Kiper a écrit :
>>
>> On Wed, Aug 30, 2023 at 04:23:36PM +0200, Ard Biesheuvel wrote:
>> > On Wed, 30 Aug 2023 at 16:18, Daniel Kiper wrote:
On Wed, 30 Aug 2023 at 16:18, Daniel Kiper wrote:
>
> On Fri, Aug 25, 2023 at 05:50:58AM -0700, Oliver Steffen wrote:
> > Quoting Vladimir 'phcoder' Serbinenko (2023-08-15 18:14:11)
>
> [...]
>
> > I am not sure what the best way forward is now, but we at least have the
> > patches from Vladimir (
On Thu, 3 Aug 2023 at 15:24, Ard Biesheuvel wrote:
>
> The x86_64 Linux kernel can be booted in 32-bit mode, in which case the
> startup code creates a set of preliminary page tables that map the first
> 1GiB of physical memory 1:1, and enables paging. This is a prerequisite
On Tue, 15 Aug 2023 at 05:42, Vladimir 'phcoder' Serbinenko
wrote:
>>
>> .
>>
>> Ard thinks that a 64 bit alignment for EFI GUIDs is a mistake - see [1]
>> and [2]. Hence Linux uses `__aligned(__alignof__(u32))` for "efi_guid_t"
>> since 2019.
>
>
> My patch presents a reliability paradigm: accept
On Tue, 8 Aug 2023 at 17:34, Dimitri John Ledkov
wrote:
>
> On Mon, 7 Aug 2023, 13:23 Ard Biesheuvel, wrote:
> >
> > Recent mixed-mode Linux kernels (i.e., v4.0 or newer) can access EFI
> > runtime services at OS runtime even when the OS was not entered via the
>
builds and get full access to the EFI runtime services.
Cc: Daniel Kiper
Cc: Steve McIntyre
Cc: Julian Andres Klode
Signed-off-by: Ard Biesheuvel
---
grub-core/loader/efi/linux.c | 5 +
include/grub/efi/pe32.h | 6 ++
2 files changed, 11 insertions(+)
diff --git a/grub-core/loade
simplified-architecture.html
Cc: Daniel Kiper
Cc: Julian Andres Klode
Signed-off-by: Ard Biesheuvel
---
grub-core/loader/i386/linux.c | 12
include/grub/i386/linux.h | 15 +--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/grub-core/loader/i386/linux.c b/grub-c
On Mon, 10 Jul 2023 at 20:33, Glenn Washburn
wrote:
>
> Non-x86 EFI architectures were using a INITRD_MAX_ADDRESS_OFFSET defined
> by the aarch64 architecture. This seems to generally work, as in no one
> has complained about this. However, the code is misleading. Architectures
> should explicitly
lease review and test.
>
> Daniel
>
> Daniel Kiper (2):
> efi: Drop __grub_efi_api attribute from shim_lock->verify() function
> efi: Fallback to legacy mode if shim is loaded on x86 archs
>
For the series,
Reviewed-by: Ard Biesheuvel
> grub-core/kern/e
vention annotation to all prototypes)
> >
> > Signed-off-by: Daniel Kiper
> > Acked-by: Ard Biesheuvel
> > ---
> > include/grub/efi/api.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/grub/efi/api.h b/include/g
On Wed, 28 Jun 2023 at 15:29, Daniel Kiper wrote:
>
> The LoadImage() provided by the shim does not consult MOK when loading
> an image. So, simply signature verification fails when it should not.
> This means we cannot use Linux EFI stub to start the kernel when the
> shim is loaded. We have to f
On Wed, 28 Jun 2023 at 15:29, Daniel Kiper wrote:
>
> ... because (surprisingly) it uses System V AMD64 ABI on x86-64
> architecture...
>
> Fixes: 6a080b9cd (efi: Add calling convention annotation to all prototypes)
>
> Signed-off-by: Daniel Kiper
Acked-by: Ard Biesheuv
On Tue, 27 Jun 2023 at 21:19, Glenn Washburn
wrote:
>
> EFI status codes are of different classes depending on the first byte and
> all error status codes defined in appendix D of the main spec start from 1
> and have the high bit set. When printing as a uint, the decimal is a very
> large number
On Mon, 26 Jun 2023 at 16:14, Daniel Kiper wrote:
>
> On Mon, Jun 26, 2023 at 03:58:15PM +0200, Ard Biesheuvel wrote:
> > On Mon, 26 Jun 2023 at 15:56, Daniel Kiper wrote:
> > >
> > > On Mon, Jun 26, 2023 at 03:14:18PM +0200, Tobias Powalowski via
> > &g
On Mon, 26 Jun 2023 at 15:56, Daniel Kiper wrote:
>
> On Mon, Jun 26, 2023 at 03:14:18PM +0200, Tobias Powalowski via Grub-devel
> wrote:
> > Am Mo., 26. Juni 2023 um 14:28 Uhr schrieb Daniel Kiper
> > :
> > Hey,
> >
> > Thomas, good point. I completely missed that.
> >
> > Tobias
On Fri, 23 Jun 2023 at 16:18, Tobias Powalowski
wrote:
>
> Am Fr., 23. Juni 2023 um 16:02 Uhr schrieb Daniel Kiper :
>>
>> On Thu, Jun 22, 2023 at 11:40:47AM +0200, Tobias Powalowski via Grub-devel
>> wrote:
>> > Hi tackled it down to this commit:
>> > https://git.savannah.gnu.org/cgit/grub.git/c
On Fri, 23 Jun 2023 at 15:46, Tobias Powalowski
wrote:
>
>
>
> Am Fr., 23. Juni 2023 um 15:41 Uhr schrieb Ard Biesheuvel :
>>
>> On Thu, 22 Jun 2023 at 11:41, Tobias Powalowski
>> wrote:
>> >
>> > Hi tackled it down to this commit:
>> &
On Thu, 22 Jun 2023 at 11:41, Tobias Powalowski
wrote:
>
> Hi tackled it down to this commit:
> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6a080b9cde0be5d08b71daf17a806067e32fc13f
> starting with this commit shim verification fails for kernel hash with bad
> shim verification and makes
n that the device path in question is not installed on a
handle, I'm not even sure whether creating that memory mapped device
path serves any purpose tbh.
So this approach seems perfectly reasonable to me.
Reviewed-by: Ard Biesheuvel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
t the image but unload it and return
an error.
Signed-off-by: Ard Biesheuvel
---
grub-core/loader/efi/linux.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c
index 90ad1a7b82a76066..8211f7892ad391f1 100644
--- a
On Wed, 24 May 2023 at 19:15, Ard Biesheuvel wrote:
>
> The EFI spec mandates that the handle produced by the LoadImage boot
> service has a LoadedImage protocol instance installed on it, but for
> robustness, we should still deal with a NULL return value from the
> helper routi
t the image but unload it and return
an error.
Signed-off-by: Ard Biesheuvel
---
grub-core/loader/efi/linux.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c
index 90ad1a7b82a76066..b434c56ae67d665e 100644
--- a/grub-core/loade
On Tue, 23 May 2023 at 17:32, Ard Biesheuvel wrote:
>
> Switch the x86 based EFI platform builds to the generic EFI loader,
> which exposes the initrd via the LoadFile2 protocol instead of the
> x86-specific setup header. This will launch the Linux kernel via its EFI
> stub, whi
generate the correct instruction sequence for us.
So let's add the appropriate annotation to all the function prototypes.
This will allow us to drop the special call wrappers in a subsequent
patch.
Signed-off-by: Ard Biesheuvel
---
grub-core/efiemu/runtime/efiemu.c | 48 +-
grub-core/kern/ar
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 1 -
grub-core/kern/x86_64/efi/callwrap.S | 129
include
.
Signed-off-by: Ard Biesheuvel
---
grub-core/commands/acpi.c | 8 +--
grub-core/commands/efi/efitextmode.c | 8 ++-
grub-core/commands/efi/lsefi.c| 5 +-
grub-core/commands/efi/tpm.c | 21
grub-core/disk/efi/efidisk.c | 7 +--
grub-core/kern/arm/efi
alled
inadvertently.
Signed-off-by: Ard Biesheuvel
---
include/grub/efi/api.h | 24 ++--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index 4ae5e51c9013ceb3..7077d2265df9b20a 100644
--- a/include/grub/efi/api.h
kernels that lack EFI
stub or LoadFile2 support. This removes the need for additional
changes to support v5.8 or older kernels.
Cc: Daniel Kiper
Cc: Glenn Washburn
Ard Biesheuvel (5):
efi: Make EFI PXE protocol methods non-callable
efi: Add calling convention annotation to all prototypes
EFI
handover protocol, which has no basis in the UEFI specification, is not
implemented.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 2 +
grub-core/loader/efi/linux.c | 47 ++--
grub-core/loader/i386/linux.c | 8
include/grub/efi/efi.h| 2 +-
4
alled
inadvertently.
Signed-off-by: Ard Biesheuvel
---
include/grub/efi/api.h | 24 ++--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index 4ae5e51c9013ceb3..7077d2265df9b20a 100644
--- a/include/grub/efi/api.h
EFI
handover protocol, which has no basis in the UEFI specification, is not
implemented.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 2 +
grub-core/loader/efi/linux.c | 40 +++-
grub-core/loader/i386/linux.c | 8
include/grub/efi/efi.h| 2 +-
4
generate the correct instruction sequence for us.
So let's add the appropriate annotation to all the function prototypes.
This will allow us to drop the special call wrappers in a subsequent
patch.
Signed-off-by: Ard Biesheuvel
---
grub-core/kern/arm/efi/init.c | 2 +-
include/grub/efi/
or not;
- enable generic EFI for i386 as well
- wire up the existing x86 code as a fallback for kernels that lack EFI
stub or LoadFile2 support. This removes the need for additional
changes to support v5.8 or older kernels.
Cc: Daniel Kiper
Cc: Glenn Washburn
Ard Biesheuvel (5):
efi: Make
.
Signed-off-by: Ard Biesheuvel
---
grub-core/commands/acpi.c | 8 +--
grub-core/commands/efi/efitextmode.c | 8 ++-
grub-core/commands/efi/lsefi.c| 5 +-
grub-core/commands/efi/tpm.c | 21
grub-core/disk/efi/efidisk.c | 7 +--
grub-core/kern/arm/efi
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 1 -
grub-core/kern/x86_64/efi/callwrap.S | 129
include
On Sun, 14 May 2023 at 07:12, Glenn Washburn
wrote:
>
> On Thu, 11 May 2023 14:06:40 +0200
> Ard Biesheuvel wrote:
>
> > Switch the x86 based EFI platform builds to the generic EFI loader,
> > which exposes the initrd via the LoadFile2 protocol instead of the
> > x
On Fri, 12 May 2023 at 12:42, John Paul Adrian Glaubitz
wrote:
>
> Hello Ard!
>
> On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote:
> > > > Feel free to keep using it, but please stop demanding that our people
> > > > keep wasting their time on it.
On Fri, 12 May 2023 at 00:41, matoro
wrote:
>
> On 2023-05-11 18:09, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 20:59, matoro
> > wrote:
> >>
> >> On 2023-05-11 10:29, Ard Biesheuvel wrote:
> >> > On Thu, 11 May 2023 at 15:34, John Paul Adria
On Thu, 11 May 2023 at 20:59, matoro
wrote:
>
> On 2023-05-11 10:29, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
> > wrote:
> >>
> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> >> > On Thu,
On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
wrote:
>
> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> > wrote:
> > >
> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wro
On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
wrote:
>
> On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> > Itanium IA-64 support is obsolete, and implements its own flavor of EFI
> > boot that deviates from other architectures. Given that IA64 is unused
&g
On Thu, 11 May 2023 at 14:06, Ard Biesheuvel wrote:
>
> Switch the x86 based EFI platform builds to the generic EFI loader,
> which exposes the initrd via the LoadFile2 protocol instead of the
> x86-specific setup header. This will launch the Linux kernel via its EFI
> stub, whi
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 1 -
grub-core/kern/x86_64/efi/callwrap.S | 129
include
alled
inadvertently.
Signed-off-by: Ard Biesheuvel
---
include/grub/efi/api.h | 24 ++--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index b4c4646651cd53f5..da1a80ca3a94fe1c 100644
--- a/include/grub/efi/api.h
test whether our changes break the boot
for it or not;
- enable generic EFI for i386 as well
- wire up the existing x86 code as a fallback for kernels that lack EFI
stub or LoadFile2 support. This removes the need for additional
changes to support v5.8 or older kernels.
Ard Biesheuvel (6
d-off-by: Ard Biesheuvel
---
.travis.yml | 7 +-
Makefile.util.def | 1 -
configure.ac | 8 -
docs/grub-dev.texi| 2 +-
docs/grub.texi| 2 +-
gentpl.py | 6 +-
grub
.
Signed-off-by: Ard Biesheuvel
---
grub-core/commands/acpi.c| 8 +--
grub-core/commands/efi/efitextmode.c | 8 ++-
grub-core/commands/efi/lsefi.c | 5 +-
grub-core/commands/efi/tpm.c | 21
grub-core/disk/efi/efidisk.c | 7 +--
grub-core/kern/arm/efi/init.c
EFI
handover protocol, which has no basis in the UEFI specification, is not
implemented.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 5 +-
grub-core/loader/efi/linux.c | 51 ++--
grub-core/loader/i386/linux.c | 8 +++
include/grub/efi/efi.h| 2 +-
4
generate the correct instruction sequence for us.
So let's add the appropriate annotation to all the function prototypes.
This will allow us to drop the special call wrappers in a subsequent
patch.
Signed-off-by: Ard Biesheuvel
---
grub-core/kern/arm/efi/init.c | 2 +-
include/grub/efi/
On Wed, 10 May 2023 at 19:40, Ard Biesheuvel wrote:
>
> On Wed, 10 May 2023 at 15:15, Daniel Kiper wrote:
> >
> > On Wed, May 10, 2023 at 12:40:30PM +0200, Ard Biesheuvel wrote:
> > > On Tue, 9 May 2023 at 18:53, Ard Biesheuvel wrote:
> > > >
> > &
On Wed, 10 May 2023 at 15:15, Daniel Kiper wrote:
>
> On Wed, May 10, 2023 at 12:40:30PM +0200, Ard Biesheuvel wrote:
> > On Tue, 9 May 2023 at 18:53, Ard Biesheuvel wrote:
> > >
> > > Switch the x86_64 build to the generic EFI loader, which exposes the
> >
On Tue, 9 May 2023 at 18:53, Ard Biesheuvel wrote:
>
> Switch the x86_64 build to the generic EFI loader, which exposes the
> initrd via the LoadFile2 protocol instead of the x86-specific setup
> header. This will launch the Linux kernel via its EFI stub, which
> performs its own
.
Signed-off-by: Ard Biesheuvel
---
grub-core/commands/acpi.c| 8 +--
grub-core/commands/efi/efitextmode.c | 8 ++-
grub-core/commands/efi/lsefi.c | 5 +-
grub-core/commands/efi/tpm.c | 21
grub-core/disk/efi/efidisk.c | 7 +--
grub-core/kern/arm/efi/init.c
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 1 -
grub-core/kern/x86_64/efi/callwrap.S | 129
include
alled
inadvertently.
Signed-off-by: Ard Biesheuvel
---
include/grub/efi/api.h | 24 ++--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index b4c4646651cd53f5..da1a80ca3a94fe1c 100644
--- a/include/grub/efi/api.h
ExitBootServices() and performing the bare metal Linux boot.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 6 +-
grub-core/kern/efi/mm.c | 2 +-
grub-core/loader/efi/linux.c | 12
include/grub/efi/efi.h | 2 ++
4 files changed, 16 insertions(+), 6 deletions
cleanup first, so we no longer need to rely on the
MS to SysV calling convention translation code.
Ard Biesheuvel (5):
efi: Make EFI PXE protocol methods non-callable
efi: Add calling convention annotation to all prototypes
efi: Drop all uses of efi_call_XX wrappers
efi: Remove x86_64 call
generate the correct instruction sequence for us.
So let's add the appropriate annotation to all the function prototypes.
This will allow us to drop the special call wrappers in a subsequent
patch.
Signed-off-by: Ard Biesheuvel
---
grub-core/kern/arm/efi/init.c | 2 +-
include/grub/efi/
On Fri, 16 Dec 2022 at 18:55, Robbie Harwood wrote:
>
> Ard Biesheuvel writes:
>
> > As for supporing kernels from 2012: I don't see why upstream GRUB
> > should care about that. If your distro fork supports those today, you
> > will simply need to carry those
On Thu, 15 Dec 2022 at 15:29, Julian Andres Klode
wrote:
>
> On Wed, Dec 14, 2022 at 04:11:18PM +0100, Daniel Kiper wrote:
> > Adding a few folks who may be interested in this discussion too...
> >
> > On Wed, Dec 14, 2022 at 02:21:49PM +0100, Julian Andres Klode wrote:
> > > Hi,
> > >
> > > so I
On Wed, 7 Dec 2022 at 11:36, Xiaotian Wu wrote:
>
> 在 2022-12-07星期三的 09:06 +0100，Ard Biesheuvel写道：
> > On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu
> > wrote:
> > >
> > > 在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> > > > GRUB currently r
On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu wrote:
>
> 在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> > GRUB currently relies on the magic number in the image header of ARM
> > and
> > arm64 EFI kernel images to decide whether or not the image in
> > que
On Thu, 1 Dec 2022 at 15:30, Daniel Kiper wrote:
>
> On Tue, Nov 29, 2022 at 06:56:16PM +0100, Ard Biesheuvel wrote:
> > GRUB currently relies on the magic number in the image header of ARM and
> > arm64 EFI kernel images to decide whether or not the image in question
> &
t here.
Cc: Huacai Chen
Cc: Atish Patra
Cc: Heinrich Schuchardt
Cc: Daniel Kiper
Cc: Leif Lindholm
Signed-off-by: Ard Biesheuvel
---
arch/loongarch/kernel/head.S| 3 ++-
arch/x86/boot/header.S | 3 ++-
drivers/firmware/efi/libstub/zboot-header.S | 3 ++-
in
sting images
already exist, so for those architectures, we have to consider both
anyway.
Cc: Huacai Chen
Cc: Atish Patra
Cc: Heinrich Schuchardt
Cc: Daniel Kiper
Cc: Leif Lindholm
Ard Biesheuvel (2):
efi: libstub: Always enable initrd command line loader and bump
version
efi: Put
In preparation for setting a cross-architecture baseline for EFI boot
support, remove the Kconfig option that permits the command line initrd
loader to be disabled. Also, bump the minor version so that any image
built with the new version can be identified as supporting this.
Signed-off-by: Ard
On Thu, 10 Nov 2022 at 00:27, Daniel Kiper wrote:
>
> On Wed, Nov 09, 2022 at 04:01:27PM +0100, Heinrich Schuchardt wrote:
> > On 11/9/22 15:16, Ard Biesheuvel wrote:
> > > GRUB currently relies on the magic number in the image header of ARM and
> > > arm64 EFI kern
bit ARM already uses the same location in the header for a
different purpose, but the ARM support is already widely implemented and
the EFI zboot decompressor is not available on ARM anyway, so we just
disregard it here.
Cc: Huacai Chen
Cc: Atish Patra
Cc: Heinrich Schuchardt
Cc: Daniel
On Wed, 9 Nov 2022 at 13:50, Ard Biesheuvel wrote:
>
> On Wed, 9 Nov 2022 at 13:38, Leif Lindholm wrote:
> >
> > On Wed, Nov 09, 2022 at 13:10:29 +0100, Ard Biesheuvel wrote:
> > > > > > The drawback to that is that not all EFI executables are destined
&
On Wed, 9 Nov 2022 at 13:38, Leif Lindholm wrote:
>
> On Wed, Nov 09, 2022 at 13:10:29 +0100, Ard Biesheuvel wrote:
> > > > > The drawback to that is that not all EFI executables are destined for
> > > > > the Linux loader. So while trying to boot them
On Wed, 9 Nov 2022 at 13:01, Leif Lindholm wrote:
>
> On Wed, Nov 09, 2022 at 12:33:58 +0100, Ard Biesheuvel wrote:
> > > > Can we get rid of these header definitions entirely?
> > > >
> > > > The only GRUB code that seems to care about the fields that a
On Wed, 9 Nov 2022 at 12:21, Leif Lindholm wrote:
>
> On Tue, Nov 08, 2022 at 17:36:51 +0100, Ard Biesheuvel wrote:
> > > I can agree that hdr_offset makes more sense but
> > > Documentation/riscv/boot-image-header.rst names this member as res3.
> > > So, I would
On Wed, 9 Nov 2022 at 09:13, Atish Kumar Patra wrote:
>
>
>
> On Tue, Nov 8, 2022 at 8:37 AM Ard Biesheuvel wrote:
>>
>> On Tue, 8 Nov 2022 at 16:59, Daniel Kiper wrote:
>> >
>> > On Fri, Nov 04, 2022 at 04:26:06PM -0700, Atish Patra wrote:
>> >
On Tue, 8 Nov 2022 at 16:59, Daniel Kiper wrote:
>
> On Fri, Nov 04, 2022 at 04:26:06PM -0700, Atish Patra wrote:
> > Update the RISC-V Linux kernel image headers as per the current header.
> >
> > Reference:
> > /Documentation/riscv/boot-image-header.rst
> >
> > 474efecb65dc: ("riscv: modify the
On Fri, 21 Oct 2022 at 14:51, Daniel Kiper wrote:
>
> On Tue, Oct 18, 2022 at 09:05:01PM +0200, Ard Biesheuvel wrote:
> > This implements the LoadFile2 initrd loading protocol, which is
> > essentially a callback interface into the bootloader to load the initrd
> > dat
F image version),
and defer loading the initrd contents until the point where the kernel
invokes the LoadFile2 protocol.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
Tested-by: Ilias Apalodimas
Reviewed-by: Ilias Apalodimas
---
grub-core/commands/efi/lsefi.c | 1 +
grub-co
ved into a struct grub_pe_image_header,
which we will use later to access COFF header fields of arbitrary
images (and which may therefore appear at different offsets)
Signed-off-by: Ard Biesheuvel
---
grub-core/kern/efi/efi.c | 8 ++--
include/grub/efi/pe32.h | 16
2 files c
cates to the network core that EFI network
devices should not be closed when grub_net_fini_hw() is called.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Daniel Kiper
---
grub-core/net/drivers/efi/efinet.c | 10 +-
grub-core/net/net.c
ignore it entirely.
The only remaining reason to deal with the devicetree is if we are
using the 'devicetree' command to load one from disk, so tweak the
logic in grub_fdt_install() to take that into account.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
Reviewed-by: Da
grub_arch_efi_linux_check_image() is
preceded by a load of the image header, let's move the load into that
function, and rename it to grub_arch_efi_linux_load_image_header()/
Signed-off-by: Ard Biesheuvel
---
grub-core/loader/arm64/linux.c| 12 +-
grub-core/loader/arm64/xen_boot.c
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/
e
Cc: Ilias Apalodimas
Ard Biesheuvel (6):
efi: move MS-DOS stub out of generic PE header definition
linux/arm: unify ARM/arm64 vs Xen PE/COFF header handling
linux/arm: account for COFF headers appearing at unexpected offsets
efi/efinet: Don't close connections at fini_hw() time
On Mon, 10 Oct 2022 at 16:58, Daniel Kiper wrote:
>
> On Fri, Oct 07, 2022 at 01:50:27AM -0700, Atish Patra wrote:
> > This series unifies the linux loader for ARM64 & RISC-V. The linux loader
> > for ARM64 is pretty much arch independent. Thus, this series just moves
> > it to the common director
On Thu, 15 Sept 2022 at 14:21, Leif Lindholm wrote:
>
> On Thu, Sep 08, 2022 at 15:30:12 +0200, Ard Biesheuvel wrote:
> > The PE/COFF spec permits the COFF signature and file header to appear
> > anywhere in the file, and the actual offset is recorded in 4 byte
> > littl
Xen has its own version of the image header, to account for the
additional PE/COFF header fields. Since we are adding references to
those in the shared EFI loader code, update the common definitions
and drop the Xen specific one which no longer has a purpose.
Signed-off-by: Ard Biesheuvel
F image version),
and defer loading the initrd contents until the point where the kernel
invokes the LoadFile2 protocol.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
Tested-by: Ilias Apalodimas
Reviewed-by: Ilias Apalodimas
---
grub-core/commands/efi/lsefi.c | 1 +
grub-co
1 - 100 of 172 matches
Mail list logo
