Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback withint 0xcc
From: Ingo Molnar
Date: Sun May 29 2011 - 16:01:50 EST
* Andrew Lutomirski <luto@xxxxxxx> wrote:
> On Sun, May 29, 2011 at 3:49 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Andrew Lutomirski <luto@xxxxxxx> wrote:
> >
> >> > Ok, i suspect you marked it 0xCC because that's the INT3 instruction
> >> > - not very useful for exploits?
> >>
> >> Exactly.
> >>
> >> The comments in irq_vectors.h make it sound like vectors 0x81..0xed
> >> are used for device interrupts but AFAICT it's only 0x20..0x39 that
> >> are used, so the precise choice of vector doesn't matter that much.
> >
> > No, we use almost all of the vector space for device interrupts. Why
> > do you think only 0x20..0x39 is used?
>
> Possibility my inability to understand all the IRQ mapping code in
> just half an hour of trying.
Hey, you managed to find all the scattered pieces in just half an
hour, i'm impressed ;-)
> In arch/x86/kernel/irq.c, arch_probe_nr_irqs returns
> NR_IRQS_LEGACY, which I think means that the genirq code allocates
> will only expect IRQs on that many vectors.
>
> If I'm wrong then my patch could be bad: if something tries to use
> vector 0xcc for a device interrupt, then the vsyscall emulation
> code will eat that interrupt.
I saw the used_vector trick you did and it looked safe to me: we set
up these gates very early on, when there's no device interrupts yet.
If you want to be really sure you could do a BUG_ON(test_bit())
before setting it.
> (0xcc is barely below the maximum. INVALIDATE_TLB_VECTOR_START
> could be as low as 0xcf.)
Yeah - 0xcc could be fine even if it's in the middle - we are able to
skip over used ones.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/