Messages in this thread | | | Date | Sun, 29 May 2011 22:01:31 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback with int 0xcc |
| |
* Andrew Lutomirski <luto@mit.edu> wrote:
> On Sun, May 29, 2011 at 3:49 PM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Andrew Lutomirski <luto@mit.edu> 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
| |