On Tue, May 31, 2011 at 9:17 AM, Andrew Lutomirski <[email protected]> wrote:
> On Tue, May 31, 2011 at 9:11 AM, Ingo Molnar <[email protected]> wrote:
>>
>> * Andrew Lutomirski <[email protected]> wrote:
>>
>>> > You could start with picking the more compatible alternative
>>> > instruction initially. I don't at all mind losing half a cycle of
>>> > performance in that case ... this code should be secure first.
>>>
>>> The more compatible one is mfence, which in some cases could (I
>>> think) be a lot more than half a cycle.
>>
>> I'd still suggest to do the mfence change now and remove the
>> alternatives patching for now - if it's more than half a cycle then
>> it sure will be implemented properly, right?
>
> I don't know. ?I just cut 5 ns off the thing a couple weeks ago and no
> one beat me to it :)
>
> I'll take a look at how hard the patching will be.
I don't think it'll be that hard to get the alternatives code to work
on the vdso, but there's an annoyance: the alt_instr descriptor
contains the absolute addresses of the old and new code. That means
that if we generate a shared object with alternatives, that shared
object will contain relocations, and I'd rather not teach the kernel
how to relocate the vdso image.
Would you be okay with changing the addresses to be relative, like
this: (sorry, whitespace damaged):
diff --git a/arch/x86/include/asm/alternative.h
b/arch/x86/include/asm/alternative.h
index bf535f9..de25be6 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -84,8 +84,8 @@ static inline int alternatives_text_reserved(void
*start, void *end)
"661:\n\t" oldinstr "\n662:\n" \
".section .altinstructions,\"a\"\n" \
_ASM_ALIGN "\n" \
- _ASM_PTR "661b\n" /* label
*/ \
- _ASM_PTR "663f\n" /* new
instruction */ \
+ _ASM_PTR "661b - .\n" /* label */ \
+ _ASM_PTR "663f - .\n" /* new instruction */ \
" .word " __stringify(feature) "\n" /* feature bit
*/ \
" .byte 662b-661b\n" /* sourcelen
*/ \
" .byte 664f-663f\n" /*
replacementlen */ \
This won't result in relocations.
(Obviously I'd have to change the asm version and the patching code to
match it.)
--Andy
On Tue, May 31, 2011 at 11:31 AM, Andrew Lutomirski <[email protected]> wrote:
> On Tue, May 31, 2011 at 9:17 AM, Andrew Lutomirski <[email protected]> wrote:
>> On Tue, May 31, 2011 at 9:11 AM, Ingo Molnar <[email protected]> wrote:
>>>
>>> * Andrew Lutomirski <[email protected]> wrote:
>>>
>>>> > You could start with picking the more compatible alternative
>>>> > instruction initially. I don't at all mind losing half a cycle of
>>>> > performance in that case ... this code should be secure first.
>>>>
>>>> The more compatible one is mfence, which in some cases could (I
>>>> think) be a lot more than half a cycle.
>>>
>>> I'd still suggest to do the mfence change now and remove the
>>> alternatives patching for now - if it's more than half a cycle then
>>> it sure will be implemented properly, right?
>>
>> I don't know. I just cut 5 ns off the thing a couple weeks ago and no
>> one beat me to it :)
>>
>> I'll take a look at how hard the patching will be.
>
> I don't think it'll be that hard to get the alternatives code to work
> on the vdso, but there's an annoyance: the alt_instr descriptor
> contains the absolute addresses of the old and new code. That means
> that if we generate a shared object with alternatives, that shared
> object will contain relocations, and I'd rather not teach the kernel
> how to relocate the vdso image.
Alternatives in the vdso won't work without special support, since it
is encapsulated as a binary blob in the kernel (so its
.altinstructions section won't get merged with the kernel's). You
will need to add code to parse the vdso's ELF headers and apply the
alternatives to the kernel's image of the vdso. It looks like the
32-bit vdso already has some code to parse and apply relocations to
the ELF headers so that could possibly be a starting point.
--
Brian Gerst