Julian Andres Klode (1):
efi: Provide wrappers for load_image, start_image, unload_image
Mate Kukri (4):
efi/sb: Add support for the shim loader protocol
efi/sb: Add API for retrieving shim loader image handles
loader/efi/chainloader: Use shim loader image handle where available
loader/e
On Wed, Mar 19, 2025 at 07:32:37PM -0500, Andrew Hamilton wrote:
> Hello,
>
> Looks good to me, thanks!
>
> Reviewed-by: Andrew Hamilton
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/lis
On Thu, Mar 20, 2025 at 06:28:00PM -0500, Andrew Hamilton wrote:
> A regression was introduced recently as a part of the series of
> filesystem related patches to address some CVEs found in GRUB.
>
> This issue may cause either an infinite loop at startup when
> accessing certain valid NTFS file sy
A regression was introduced recently as a part of the series of
filesystem related patches to address some CVEs found in GRUB.
This issue may cause either an infinite loop at startup when
accessing certain valid NTFS file systems, or may cause a crash
due to a NULL pointer deference on systems whe
Will do! I’ll do this later today after work. I was attempting to chase
down some additional ntfs test failures (around hard links on an ntfs file
system) even with the fix mentioned but maybe to expedite the main issue
people are having I’ll put that on my queue for after this first fix.
Thanks!
On Mon, Mar 24, 2025 at 10:35:13AM -0400, Stefan Berger wrote:
>
>
> On 3/24/25 10:29 AM, Vladimir 'phcoder' Serbinenko wrote:
> > Is there a risk here of missing the failures? It's common that no one
> > looks at the output unless it causes a failed build on some CI/CD Le
>
> Good point. Maybe
Le ven. 4 avr. 2025, 00:25, khaliid caliy a écrit :
> Well i apologies the error message were somehow bad on my previous
> patch, and needed some improvement.
>
> diff --git a/grub-core/loader/efi/chainloader.c
> b/grub-core/loader/efi/chainloader.c
> index 869307bf3..4fd46dfda 100644
> --- a/gru
Apologies for my mistake, you are correct. The error message was
originated from the firmware, and i am not blaming grub. But the thing
is could you tell me what does "cannot load image" mean?
Well technically speaking, if you have a better error message than
mine then please tell me or improve it
On Thu, Apr 03, 2025 at 02:04:11PM -0700, Patrick Colp via Grub-devel wrote:
> Update linux_kernel_params to match the latest upstream (v6.13.77)
s/77/7/
> version of boot_params. Refactor most things out into structs, as the
> Linux kernel does.
>
> "edid_info" should be a struct with "unsigned
Sending this for preliminary review, this was originally developed downstream
for the Qubes OS project and I was requested to send the patch upstream. This
has been tested pretty well on Qubes OS R4.3, I haven't tested it in a more
"vanilla" environment yet as I cannot for the life of me get GRUB f
Enable GRUB to parse the Xen command line for parameters, and expose
those parameters to the GRUB config file (or rescue shell) as
environment variables.
---
grub-core/Makefile.core.def | 4 +-
grub-core/kern/i386/xen/pvh.c | 16 +++
grub-core/kern/main.c | 12 ++
grub-core/kern/xen/
Call results in a nicer stacktrace. And 2 cycles is nothing in the context
of them being executed only once
Le ven. 4 avr. 2025, 16:45, khaliid caliy a écrit :
> Just simple suggestion, i still don't know the reason behind it. So
> please if isn't ideal, i apologies
>
> My suggestion is since th
Just simple suggestion, i still don't know the reason behind it. So
please if isn't ideal, i apologies
My suggestion is since the `grub_main` doesn't return to the low level
assembly code, why didn't get used `jmp` instruction instead of
`call`. I think in this context jmp is slightly better than
13 matches
Mail list logo
