From: Matt Fleming
The PE/COFF specification states that the SizeOfImage field must be a
multiple of the SectionAlignment field. Add checks to verify this when
loading an image in PeCoffLoaderGetPeHeader().
This issue was reported by Linn because he discovered that the Linux
kernel's EFI
> queue (but anyone please feel free to do it while I'm offline).
Is there any chance that we could wire up support in OVMF? What work is
required to support it?
--
Matt Fleming, Intel Open Source Technology Center
ations. For toolchains that rely on GenFw for the ELF to PE/COFF
> conversion, this is not required.
Cool! I'd quite like to test this patch out but I'm not sure I've got
all of the required patch dependencies in my tree.
Could you shove everything into some public git repo so I
h a pointer
> above 4G, but I wouldn't be surprised to find a path that causes a
> double free or similar error.
Guys, the original thread starts here,
http://article.gmane.org/gmane.linux.kernel.efi/4424
Basically, reading into a buffer above 0xffff using
EFI_FILE_PROTOCOL causes Man
he memory layout of BIOS or bzImage.efi is at play. Can
> somebody please advice me as to what could be wrong?
Does any other change make your bzImage.efi work? It sounds more like
timing issue than something related to t
avoiding the problem of having to drop everything to fix patches you
wrote weeks/months ago.
Has anyone ever looked at setting up something like this before?
--
Matt Fleming, Intel Open Source Technology Center
-
f boxes that pull the latest changes and build
them, mailing anyone mentioned in the commit log if the build fails
would be sufficient. You wouldn't even need any kind of build master
until you reached a critical mass of machines.
--
Matt Fleming, In
On Wed, 26 Mar, at 11:23:10PM, Laszlo Ersek wrote:
> I think we need a memory map documentation for OVMF (a text file).
> Otherwise it's very hard to reason about our special ranges.
>
> Matt Fleming reported a bug today on IRC:
[...]
> Testing:
> - regression tes
ike this value is only used if
there's something wrong with the e820 map, or it's missing. Deleting it
should be fine.
> Thanks for the review Matt!
No problem!
--
Matt Fleming, Intel Open Source Technology Center
--
On Fri, 2012-10-26 at 10:35 -0700, Jordan Justen wrote:
> This file is from the efilinux project where it resides
> under the path loaders/bzimage/bzimage.h.
>
> Signed-off-by: Jordan Justen
> Cc: Matt Fleming
> ---
> OvmfPkg/Include/IndustryStandard/
On Fri, 2012-10-26 at 10:35 -0700, Jordan Justen wrote:
> This code is based on efilinux's bzimage support.
> git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
>
> Signed-off-by: Jordan Justen
> Cc: Matt Fleming
> ---
> OvmfPkg/Library/LoadLinuxLib/Ia
t; > +
> > +mov eax, [esp + 12]
> > +mov eax, [eax + 264h]
>
> Is this really the interface?? Matt?
Yeah that's dereferencing the handover_offset field in the boot_params,
which is going to be the sanest way
On Fri, 2013-02-08 at 16:17 -0800, Jordan Justen wrote:
> I guess efilinux now needs an update for boot protocol 2.12.
Yes, it does.
> Matt,
>
> Should we just both drop SETUP_VERSION from our bzimage.h files?
Yep.
--
Matt Fleming, Intel Open Source Techn
rebuild the OVMF.id BIOS?
>
> I appreciate any suggestions,
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
>
--
Matt Fleming, Intel Open Source Technology Center
--
ere some Apple machines in that list,
though I don't have the details but Matthew should.
So we map these regions unconditionally and in their original state,
otherwise the firmware will generate fatal page faults when trying to
access those memory regions.
--
[ Adding Matthew for reals this time ]
On Wed, 07 Aug, at 09:19:08PM, Matt Fleming wrote:
> [ Readding Matthew Garrett to the Cc list, seeing as we both got removed
> for some unknown reason ]
>
> On Wed, 07 Aug, at 10:23:56AM, Andrew Fish wrote:
>
> > OK so I think I
gs from within a Linux environment.
> PS Also maybe it would be possible to key this work around behavior on
> the EFI/UEFI version. So for example no work-around after UEFI v2.3.1?
That would really depend on who has seen this bug and on which
platforms. Is there a particular reason that
On Thu, 08 Aug, at 06:46:02AM, Andrew Fish wrote:
>
> On Aug 8, 2013, at 3:17 AM, Matt Fleming wrote:
>
> > On Wed, 07 Aug, at 02:10:28PM, Andrew Fish wrote:
> >> Well the issue I see is I don't think OS X or Windows are doing this.
> >> So I'm guessin
lp. That way we'd
only need to reserve remaining regions in efi_reserve_boot_services().
This scheme would rely on nothing writing into the crash kernel area
before we've extracted the BGRT data, however.
--
Matt Fleming, Intel Open Source Technology Center
-
From: Matt Fleming
LoadLinux() is looking at the wrong field for the kernel's EFI handover
protocol flags. It's not currently possible for JumpToUefiKernel() to
ever be called (even accidentally) because BIT2 and BIT3 of
Bp->hdr.load_flags are never set in modern kernels, whi
EMORY_RO.
I suspect you don't see this issue on aarch64 because you call
SetVirtualAddressMap() so early in boot.
I'll try and find some time to dig into this issue this coming week, but
if anyone wants to beat me to it, feel free ;-)
The first quest
ons.
I wonder whether this will have a noticeable effect on boot time.
--
Matt Fleming, Intel Open Source Technology Center
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provid
f the
firmware writes to a read-only runtime region or executes an NX region.
I'd just like to do a bit of performance analysis on it first.
--
Matt Fleming, Intel Open Source Technology Center
--
Don't Limit Your
23 matches
Mail list logo
