On Wed, 2015-09-30 at 09:43 -0700, Andy Lutomirski wrote:
> On Wed, Sep 30, 2015 at 2:30 AM, Ard Biesheuvel
> wrote:
> > On 29 September 2015 at 23:58, Laszlo Ersek wrote:
> >> On 09/28/15 08:41, Matthew Garrett wrote:
> >>> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
> >>>
> >>>
On Wed, Sep 30, 2015 at 2:30 AM, Ard Biesheuvel
wrote:
> On 29 September 2015 at 23:58, Laszlo Ersek wrote:
>> On 09/28/15 08:41, Matthew Garrett wrote:
>>> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>>>
So the question is, what does Windows do?
>>>
>>> It's pretty trivial
On 29 September 2015 at 23:58, Laszlo Ersek wrote:
> On 09/28/15 08:41, Matthew Garrett wrote:
>> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>>
>>> So the question is, what does Windows do?
>>
>> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
>> arguments to
On 09/27/2015 11:16 PM, Ingo Molnar wrote:
>
> So the question is, what does Windows do?
>
> PC firmware is a hostile environment for Linux, to be compatible the best we
> can
> do is to mimic the environment that the firmware is tested under - i.e. try
> to use
> the firmware in the way Wind
On 09/28/15 08:41, Matthew Garrett wrote:
> On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
>
>> So the question is, what does Windows do?
>
> It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
> arguments to the qemu debug port. Unfortunately I'm about to drop
> mostl
On Tue, 29 Sep, at 12:41:23PM, Ard Biesheuvel wrote:
>
> OK, fair enough. I agree that setting the flag for 32-bit would be
> semantically correct. I will leave it to Matt to comment whether it is
> reasonable in terms of changes to other parts of the code.
It should be pretty minimal. Let me tak
On Tue, 29 Sep, at 11:12:30AM, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
> > > except that I don't think
> > > the condition on 64-bit makes any sense:
> > >
> > > + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
> > >
> > > I can see us being nervous wrt. backported
On 29 September 2015 at 11:12, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>> > except that I don't think
>> > the condition on 64-bit makes any sense:
>> >
>> > + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
>> >
>> > I can see us being nervous wrt. backported patches
* Ard Biesheuvel wrote:
> > except that I don't think
> > the condition on 64-bit makes any sense:
> >
> > + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
> >
> > I can see us being nervous wrt. backported patches, but is there any strong
> > reason
> > to not follow this
On 28 September 2015 at 09:22, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>> On 27 September 2015 at 08:03, Ingo Molnar wrote:
>> >
>> > * Matt Fleming wrote:
>> >
>> [...]
>> >> [...] The actual virtual addresses we pick are exactly the same with the
>> >> two
>> >> patches.
>> >
>> > S
* Ard Biesheuvel wrote:
> On 27 September 2015 at 08:03, Ingo Molnar wrote:
> >
> > * Matt Fleming wrote:
> >
> [...]
> >> [...] The actual virtual addresses we pick are exactly the same with the
> >> two
> >> patches.
> >
> > So I'm NAK-ing this for now:
> >
> > - The code is it reads today
On Mon, Sep 28, 2015 at 08:16:46AM +0200, Ingo Molnar wrote:
> So the question is, what does Windows do?
It's pretty trivial to hack OVMF to dump the SetVirtualAddressMap()
arguments to the qemu debug port. Unfortunately I'm about to drop mostly
offline for a week, otherwise I'd give it a go...
On 27 September 2015 at 08:03, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
[...]
>> [...] The actual virtual addresses we pick are exactly the same with the two
>> patches.
>
> So I'm NAK-ing this for now:
>
> - The code is it reads today pretends to be an 'allocator'. It is _NOT_ an
>all
* Matthew Garrett wrote:
> On Sun, Sep 27, 2015 at 09:30:48AM -0700, Andy Lutomirski wrote:
> > On Sep 26, 2015 1:19 PM, "H. Peter Anvin" wrote:
> > >
> > > Sadly a lot of firmware is known to fail in that configuration :( That
> > > was very much our guest choice.
> > >
> >
> > Why can't we
On Sun, Sep 27, 2015 at 09:30:48AM -0700, Andy Lutomirski wrote:
> On Sep 26, 2015 1:19 PM, "H. Peter Anvin" wrote:
> >
> > Sadly a lot of firmware is known to fail in that configuration :( That was
> > very much our guest choice.
> >
>
> Why can't we map everything completely 1:1 (VA = PA) and
On Sep 26, 2015 1:19 PM, "H. Peter Anvin" wrote:
>
> Sadly a lot of firmware is known to fail in that configuration :( That was
> very much our guest choice.
>
Why can't we map everything completely 1:1 (VA = PA) and call the
setVA thing but pass it literally the identity.
Firmwares that need
* Matt Fleming wrote:
> > So could we make the whole code obviously bottom-up? Such as first
> > calculating
> > the size of virtual memory needed, then allocating a _single_, obviously
> > continuous mapping, and then doing a very clear in-order mapping within
> > that
> > window? That wou
* Andy Lutomirski wrote:
> On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar wrote:
> >
> > So this commit worries me.
> >
> > This bug is a good find, and the fix is obviously needed and urgent, but
> > I'm not
> > sure about the implementation at all. (I've Cc:-ed a few more x86 low level
> > ge
Sadly a lot of firmware is known to fail in that configuration :( That was
very much our guest choice.
I don't actually think it is all that infeasible to keep relative offsets
consistent for the regions we have to map. PMD_SIZE is not a very large chunk
so it could be a problem.
On September
> On 26 sep. 2015, at 12:57, Matt Fleming wrote:
>
>> On Sat, 26 Sep, at 12:49:26PM, H. Peter Anvin wrote:
>>
>> It is still a hack unless all relative offsets are preserved. That
>> is actually simpler, even: no sorting necessary.
>
> Unless I'm missing something, preserving relative offsets
On Sat, 26 Sep, at 12:49:26PM, H. Peter Anvin wrote:
>
> It is still a hack unless all relative offsets are preserved. That
> is actually simpler, even: no sorting necessary.
Unless I'm missing something, preserving relative offsets is exactly
what we do today, modulo PMD_SIZE gaps.
--
Matt Fle
On Sat, 26 Sep, at 10:20:22AM, H. Peter Anvin wrote:
>
> I think it "works" because the affected BIOSes don't put spaces
> between the chunks. I have discussed this with Matt.
Right, that's very true. Though note that the current mapping
algorithm will handle a gap <= PMD_SIZE, it's just anything
It is still a hack unless all relative offsets are preserved. That is actually
simpler, even: no sorting necessary.
On September 26, 2015 11:15:57 AM PDT, Ard Biesheuvel
wrote:
>On 26 September 2015 at 10:20, H. Peter Anvin wrote:
>> I think it "works" because the affected BIOSes don't put sp
On 26 September 2015 at 10:20, H. Peter Anvin wrote:
> I think it "works" because the affected BIOSes don't put spaces between the
> chunks. I have discussed this with Matt.
>
Forgive the ASCII art but perhaps an illustration might help:
before the 2.5 feature, PE/COFF runtime images were rema
I think it "works" because the affected BIOSes don't put spaces between the
chunks. I have discussed this with Matt.
On September 26, 2015 10:01:14 AM PDT, Andy Lutomirski
wrote:
>On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar wrote:
>>
>> So this commit worries me.
>>
>> This bug is a good fi
On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar wrote:
>
> So this commit worries me.
>
> This bug is a good find, and the fix is obviously needed and urgent, but I'm
> not
> sure about the implementation at all. (I've Cc:-ed a few more x86 low level
> gents.)
>
> * Matt Fleming wrote:
>> +
On Sat, 26 Sep, at 07:56:43AM, Ingo Molnar wrote:
>
> So this commit worries me.
>
> This bug is a good find, and the fix is obviously needed and urgent, but I'm
> not
> sure about the implementation at all. (I've Cc:-ed a few more x86 low level
> gents.)
Thanks, the more the merrier.
> * M
On 25 September 2015 at 22:56, Ingo Molnar wrote:
>
> So this commit worries me.
>
> This bug is a good find, and the fix is obviously needed and urgent, but I'm
> not
> sure about the implementation at all. (I've Cc:-ed a few more x86 low level
> gents.)
>
> * Matt Fleming wrote:
>
>> /*
>> +
So this commit worries me.
This bug is a good find, and the fix is obviously needed and urgent, but I'm
not
sure about the implementation at all. (I've Cc:-ed a few more x86 low level
gents.)
* Matt Fleming wrote:
> /*
> + * Iterate the EFI memory map in reverse order because the regions
>
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
30 matches
Mail list logo
