On 1/6/23 10:55, Laszlo Ersek wrote:
> On 1/4/23 12:11, Gerd Hoffmann wrote:
>
>> The versions are not that ancient. The problem is more that upstream
>> grub is really slow on integrating patches so every distro does carry
>> a huge pile of downstream patches. And they seem to re-introduce the
On 1/4/23 12:11, Gerd Hoffmann wrote:
> The versions are not that ancient. The problem is more that upstream
> grub is really slow on integrating patches so every distro does carry
> a huge pile of downstream patches. And they seem to re-introduce the
> bug ...
See also: commit d20b06a3afdf
Hi,
> Hopefully sometime in the next few weeks we can prepare a comprehensive set
> of patches and changes needed in edk2 to implement this strict environment.
> One of the relevant changes to this discussion and patch series is we
> switched the configuration from PCD to hob
>
> Am 05.01.2023 um 12:44 schrieb Ard Biesheuvel :
>
> On Thu, 5 Jan 2023 at 12:19, Gerd Hoffmann wrote:
>>
>> Hi,
>>
What number would you expect? I'd hope that we get to <100 realistically.
I'm happy to hear about alternatives to this approach. I'm very confident
Hi,
> Tried booting grub.efi directly and via shim.efi, on Fedora 37 GA.
>
> In both cases I get a pagefault on linux kernel boot (before any other
> message is printed), which I guess happens because the loader places the
> linux kernel efi stub in EfiLoaderData memory.
When compiling ovmf
Hi,
> > That sounds neat, especially as we can print a big'n'fat warning in that
> > case, so the problem gets attention without actually breaking users.
> >
>
> That, and a sleep(5)
>
> > Looking at the efi calls it looks like edk2 doesn't track the owner of
> > an allocation (say by image
On Thu, 5 Jan 2023 at 12:19, Gerd Hoffmann wrote:
>
> Hi,
>
> > > What number would you expect? I'd hope that we get to <100 realistically.
> > >
> > > I'm happy to hear about alternatives to this approach. I'm very confident
> > > that forcing NX on always is going to have the opposite effect
Hi,
> > What number would you expect? I'd hope that we get to <100 realistically.
> >
> > I'm happy to hear about alternatives to this approach. I'm very confident
> > that forcing NX on always is going to have the opposite effect of what we
> > want: Everyone who ships AAVMF binaries will
On Thu, 5 Jan 2023 at 09:43, Alexander Graf wrote:
>
>
>
> > Am 05.01.2023 um 09:11 schrieb Gerd Hoffmann :
> >
> > Hi,
> >
> >> To clarify, I mean something like the patch below, but with an additional
> >> callback notification similar to the Emu one in LoadImage(), so that we can
> >> make
> Am 05.01.2023 um 09:11 schrieb Gerd Hoffmann :
>
> Hi,
>
>> To clarify, I mean something like the patch below, but with an additional
>> callback notification similar to the Emu one in LoadImage(), so that we can
>> make sure we only enable the quirk when we load a known-bad grub binary.
Hi,
> To clarify, I mean something like the patch below, but with an additional
> callback notification similar to the Emu one in LoadImage(), so that we can
> make sure we only enable the quirk when we load a known-bad grub binary.
> That way we still force distros to ship fixed versions of
On 04.01.23 14:13, Alexander Graf wrote:
On 04.01.23 10:35, Ard Biesheuvel wrote:
On Tue, 3 Jan 2023 at 23:47, dann frazier
wrote:
On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:
Hey Ard,
On 03.01.23 10:59, Ard Biesheuvel wrote:
On Thu, 29 Dec 2022 at 19:00, dann frazier
On 04.01.23 10:35, Ard Biesheuvel wrote:
On Tue, 3 Jan 2023 at 23:47, dann frazier wrote:
On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:
Hey Ard,
On 03.01.23 10:59, Ard Biesheuvel wrote:
On Thu, 29 Dec 2022 at 19:00, dann frazier wrote:
On Mon, Nov 28, 2022 at
On Wed, Jan 04, 2023 at 01:04:41PM +0100, Ard Biesheuvel wrote:
> On Wed, 4 Jan 2023 at 12:11, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> >
> > Can this also be flipped at runtime?
>
> Currently, it is fixed or patchable, which
On Wed, 4 Jan 2023 at 12:11, Gerd Hoffmann wrote:
>
> Hi,
>
> > > > > You can override PCDs on the build command line, so I suggest you use
> > > > > that for building these images as long as it is needed.
> > > > >
> > > > > E.g,, append this to the build.sh command line
> > > > >
> > > > >
Hi,
> > > > You can override PCDs on the build command line, so I suggest you use
> > > > that for building these images as long as it is needed.
> > > >
> > > > E.g,, append this to the build.sh command line
> > > >
> > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> > > >
> > >
On Tue, 3 Jan 2023 at 23:47, dann frazier wrote:
>
> On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:
> > Hey Ard,
> >
> > On 03.01.23 10:59, Ard Biesheuvel wrote:
> > > On Thu, 29 Dec 2022 at 19:00, dann frazier
> > > wrote:
> > > > On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd
On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:
> Hey Ard,
>
> On 03.01.23 10:59, Ard Biesheuvel wrote:
> > On Thu, 29 Dec 2022 at 19:00, dann frazier
> > wrote:
> > > On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:
> > > > On Mon, Sep 26, 2022 at 10:24:58AM
Hey Ard,
On 03.01.23 10:59, Ard Biesheuvel wrote:
On Thu, 29 Dec 2022 at 19:00, dann frazier wrote:
On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:
On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
When the memory protections were implemented and enabled on
On Thu, 29 Dec 2022 at 19:00, dann frazier wrote:
>
> On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:
> > On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
> > > When the memory protections were implemented and enabled on ArmVirtQemu
> > > 5+ years ago, we had to work
On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:
> On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
> > When the memory protections were implemented and enabled on ArmVirtQemu
> > 5+ years ago, we had to work around the fact that GRUB at the time
> > expected
On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
> When the memory protections were implemented and enabled on ArmVirtQemu
> 5+ years ago, we had to work around the fact that GRUB at the time
> expected EFI_LOADER_DATA to be executable, as that is the memory type it
> allocates when
On 2022-09-26 01:24, Ard Biesheuvel wrote:
When the memory protections were implemented and enabled on ArmVirtQemu
5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the memory type it
allocates when loading its modules.
This
When the memory protections were implemented and enabled on ArmVirtQemu
5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the memory type it
allocates when loading its modules.
This has been fixed in GRUB in August 2017, so by
24 matches
Mail list logo
