Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*

Andrew Lutomirski
2014-04-24T22:45:13Z

On Thu, Apr 24, 2014 at 3:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/24/2014 03:31 PM, Andrew Lutomirski wrote:
>>
>> I was imagining just randomizing a couple of high bits so the whole
>> espfix area moves as a unit.
>>
>>> We could XOR with a random constant with no penalty at all. Only
>>> problem is that this happens early, so the entropy system is not yet
>>> available. Fine if we have RDRAND, but...
>>
>> How many people have SMAP and not RDRAND? I think this is a complete
>> nonissue for non-SMAP systems.
>>
>
> Most likely none, unless some "clever" virtualizer turns off RDRAND out
> of spite.
>
>>>> Peter, is this idea completely nuts? The only exceptions that can
>>>> happen there are NMI, MCE, #DB, #SS, and #GP. The first four use IST,
>>>> so they won't double-fault.
>>>
>>> It is completely nuts, but sometimes completely nuts is actually useful.
>>> It is more complexity, to be sure, but it doesn't seem completely out
>>> of the realm of reason, and avoids having to unwind the ministack except
>>> in the normally-fatal #DF handler. #DFs are documented as not
>>> recoverable, but we might be able to do something here.
>>>
>>> The only real disadvantage I see is the need for more bookkeeping
>>> metadata. Basically the bitmask in espfix_64.c now needs to turn into
>>> an array, plus we need a second percpu variable. Given that if
>>> CONFIG_NR_CPUS=8192 the array has 128 entries I think we can survive that.
>>
>> Doing something in #DF needs percpu data? What am I missing?
>
> You need the second percpu variable in the espfix setup code so you have
> both the write address and the target rsp (read address).
>

Duh. :)

--Andy