Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback with int 0xcc

[Ingo Molnar <mingo@elte.hu>]

* 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