lkml.org 
[lkml]   [2011]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-05-29 22:03    [W:0.068 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site