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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110529200131.GA23390@elte.hu>
Date:	Sun, 29 May 2011 22:01:31 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] x86-64: Replace vsyscall gettimeofday fallback with
 int 0xcc


* Andrew Lutomirski <luto@....edu> wrote:

> On Sun, May 29, 2011 at 3:49 PM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Andrew Lutomirski <luto@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/