linux-kernel - Re: [GIT pull] x86 vdso updates

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: <BANLkTimhK2d2C=U2umD_JqwiJD=jOf-kGA@mail.gmail.com>
Date:	Sat, 28 May 2011 21:41:25 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] x86 vdso updates

On Sat, May 28, 2011 at 11:35 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Andrew Lutomirski <luto@....edu> wrote:
>
>> On Fri, May 27, 2011 at 7:36 AM, Andrew Lutomirski <luto@....edu> wrote:
>> > 3. Add int 0xcc and use it from vgettimeofday.  It will SIGSEGV if
>> > called from a user address (so it has no risk of ever becoming ABI)
>> > and it will do gettimeofday if called from the right address.  (I like
>> > 0xcc better than 0x81 because then I don't have to wonder whether any
>> > syscall-like instructions start with 0x81.)  I'm not convinced that
>> > the existing syscall entries are usable, because syscall itself has a
>> > different calling convention and int 0x80 is a compat syscall.
>> >
>>
>> I started looking at what needs to be done and I wanted to get your
>> opinion before I wrote a bunch of code that you'd reject.  Here are
>> three ideas for how the int 0xcc / int 0x81 entry could work:
>>
>> *** Idea 1 ***
>>
>> Make it a real syscall but with extra constraints.  It would have the
>> same calling convention as the syscall instruction, but it would turn
>> into SIGKILL if the calling address isn't in the VSYSCALL page or if
>> the syscall number isn't __NR_clock_gettimeofday.  It would BUG() if
>> called from kernel mode.  There are two ways to implement this:
>>
>> 1. Have the interrupt entry check constraints, twiddle its stack frame
>> to look like a syscall instruction, and jump to the syscall entry.
>> This way there's little code duplication.  (Is it safe to sysret back
>> to userspace from an interrupt gate?  I don't see why not, but it
>> seems to violate the spirit of the thing.)
>
> Yeah, i think it should be safe. Lets try this? It looks like the
> simplest variant.

The code's in the thread "[PATCH 0/5] x86-64: Remove syscall
instructions at fixed addresses".

The interrupt handler ought to be reviewed especially carefully for
security since user code can call it at will.  It has two glaring
problems that I've found already, and I'll send a v2 out soon.

--Andy
--
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/