On Wed, Sep 16, 2015 at 03:38:45PM +0200, Ard Biesheuvel wrote:
> That is a can of worms I'd rather keep closed, if you don't mind ...
Same here.
> But in general, since we are already violating the PE/COFF spec by
> relocating each runtime image once, then invoke its entry point, then
> fire an
On 16 September 2015 at 15:37, James Bottomley wrote:
> On Wed, 2015-09-16 at 13:25 +0200, Ard Biesheuvel wrote:
>> On 16 September 2015 at 12:08, Borislav Petkov wrote:
>> > On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
>> >> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
>> >> >
>
On 16 September 2015 at 15:28, Borislav Petkov wrote:
> On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote:
>> ... so even if we wanted to, it would be intractible to find each
>> cross-section relative reference and do the fixup.
>
> Hmm, maybe we should go and patch EFI code segments
On Wed, 2015-09-16 at 13:25 +0200, Ard Biesheuvel wrote:
> On 16 September 2015 at 12:08, Borislav Petkov wrote:
> > On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> >> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >> >
> >> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE en
On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote:
> ... so even if we wanted to, it would be intractible to find each
> cross-section relative reference and do the fixup.
Hmm, maybe we should go and patch EFI code segments and fixup all
relative references after mapping. I mean, if y
On 16 September 2015 at 12:08, Borislav Petkov wrote:
> On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
>> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
>> >
>> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it
>> > doesn't
>> > boot without your patch.
>>
>> Awe
On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >
> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> > boot without your patch.
>
> Awesome. Could you test the following patch instead?
>
> ---
>
> Fro
Hi,
On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >
> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> > boot without your patch.
>
> Awesome. Could you test the following patch instead?
>
> ---
Ye
On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
>
> Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> boot without your patch.
Awesome. Could you test the following patch instead?
---
>From 24d324b781a3b688dcc265995949a9cf4e8af687 Mon Sep 17 00:00:00 2001
From: Matt Fl
On 9 September 2015 at 11:58, Matt Fleming wrote:
> On Wed, 09 Sep, at 09:37:21AM, Ard Biesheuvel wrote:
>> On 8 September 2015 at 22:37, Matt Fleming wrote:
>> >
>> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> > index 691b333e0038..a2af35f6093a 100644
>> > --- a/ar
On Wed, 09 Sep, at 09:37:21AM, Ard Biesheuvel wrote:
> On 8 September 2015 at 22:37, Matt Fleming wrote:
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 691b333e0038..a2af35f6093a 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/
On 8 September 2015 at 22:37, Matt Fleming wrote:
> On Tue, 08 Sep, at 03:21:17PM, Ard Biesheuvel wrote:
>>
>> I noticed that the 64-bit version of efi_map_region() preserves the
>> relative alignment with respect to a 2 MB boundary for /each/ region.
>> Since the regions are mapped in reverse ord
Hi Matt,
On Tue, Sep 08, 2015 at 09:41:47PM +0100, Matt Fleming wrote:
> On Mon, 07 Sep, at 12:07:52PM, joeyli wrote:
> >
> > This patch works to me on Intel S1200V3RPS to fix issue:
> > DMI: Intel Corporation (uefidk.com) Intel Server Board S1200V3RPS UEFI
> > Development Kit/ROMLEY, BIOS 2.0
>
On Mon, 07 Sep, at 12:07:52PM, joeyli wrote:
>
> This patch works to me on Intel S1200V3RPS to fix issue:
> DMI: Intel Corporation (uefidk.com) Intel Server Board S1200V3RPS UEFI
> Development Kit/ROMLEY, BIOS 2.0
>
> Tested-by: Lee, Chun-Yi
When you say "fix issue", do you mean that your mach
On Tue, 08 Sep, at 03:21:17PM, Ard Biesheuvel wrote:
>
> I noticed that the 64-bit version of efi_map_region() preserves the
> relative alignment with respect to a 2 MB boundary for /each/ region.
> Since the regions are mapped in reverse order, it is highly unlikely
> that each region starts at t
On 8 September 2015 at 15:16, Matt Fleming wrote:
> On Fri, 04 Sep, at 08:53:36PM, Ard Biesheuvel wrote:
>> On 4 September 2015 at 20:23, Matt Fleming wrote:
>> > On Fri, 04 Sep, at 03:24:21PM, Ard Biesheuvel wrote:
>> >>
>> >> Since the UEFI spec does not mandate an enumeration order for
>> >> G
On Fri, 04 Sep, at 08:53:36PM, Ard Biesheuvel wrote:
> On 4 September 2015 at 20:23, Matt Fleming wrote:
> > On Fri, 04 Sep, at 03:24:21PM, Ard Biesheuvel wrote:
> >>
> >> Since the UEFI spec does not mandate an enumeration order for
> >> GetMemoryMap(), it seems to me that you still need to sort
Hi,
On Fri, Sep 04, 2015 at 02:14:07PM +0100, Matt Fleming wrote:
> From: Matt Fleming
>
> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
> signals that the firmware PE/COFF loader supports splitting code and
> data sections of PE/COFF images into separate EFI memory map entr
On 4 September 2015 at 20:53, Ard Biesheuvel wrote:
> On 4 September 2015 at 20:23, Matt Fleming wrote:
>> On Fri, 04 Sep, at 03:24:21PM, Ard Biesheuvel wrote:
>>>
>>> Since the UEFI spec does not mandate an enumeration order for
>>> GetMemoryMap(), it seems to me that you still need to sort its
On 4 September 2015 at 20:23, Matt Fleming wrote:
> On Fri, 04 Sep, at 03:24:21PM, Ard Biesheuvel wrote:
>>
>> Since the UEFI spec does not mandate an enumeration order for
>> GetMemoryMap(), it seems to me that you still need to sort its output
>> before laying out the VA space. Since you need to
On Fri, 04 Sep, at 03:24:21PM, Ard Biesheuvel wrote:
>
> Since the UEFI spec does not mandate an enumeration order for
> GetMemoryMap(), it seems to me that you still need to sort its output
> before laying out the VA space. Since you need to sort it anyway, why
> not simply sort it in reverse ord
On 4 September 2015 at 15:14, Matt Fleming wrote:
> From: Matt Fleming
>
> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
> signals that the firmware PE/COFF loader supports splitting code and
> data sections of PE/COFF images into separate EFI memory map entries.
> This allows
From: Matt Fleming
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
signals that the firmware PE/COFF loader supports splitting code and
data sections of PE/COFF images into separate EFI memory map entries.
This allows the kernel to map those regions with strict memory
protection
23 matches
Mail list logo
