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: <20110529194922.GC13539@elte.hu>
Date:	Sun, 29 May 2011 21:49:22 +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:

> > 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?

> > A not-so-nit: i'd not limit this message to unhandled signals 
> > alone. An attacker could install a SIGSEGV handler, send a 
> > SIGSEGV and attempt the exploit right then - he'll get a free 
> > attempt with no logging performed, right?.
> 
> I think if an exploit can call sigaction, then we've already lost. 

Yes, indeed. In theory an app could be catching SIGSEGV and we could 
have an exploit there. But that's pretty theoretical ...

> But I can still make the change.

If you did it to not repeat the message then i think the 
printk_ratelimit() is more than enough. force_sig() will be able to 
sort out repeat signals just fine.

> >> +     local_irq_disable();
> >> +     return;
> >> +}
> >
> > Nit: no need for a 'return;' at the end of a void function.
> 
> :)
> 
> That pointless "return" statement was to hide the fact that the
> local_irq_enable wasn't correctly matched.

indeed. I noticed the do_exit() local_irq_enable() assymetry which is 
harmless (we never return), but missed the force_sig() one that isn't 
so harmless.

> I'm changing this code a fair bit in preparation for the extra 
> bonus patch to defang vsyscalls even more by trapping all of them.

ok.

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/