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
On 25 September 2015 at 23:01, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
>> From: Ard Biesheuvel
>>
>> The new Properties Table feature introduced in UEFIv2.5 may split
>> memory regions that cover PE/COFF memory images
* Matt Fleming wrote:
> From: Ard Biesheuvel
>
> The new Properties Table feature introduced in UEFIv2.5 may split
> memory regions that cover PE/COFF memory images into separate code
> and data regions. Since these regions only differ in
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
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
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.
> *
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
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
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
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
10 matches
Mail list logo