linux-kernel - Re: [ABOMINATION] x86: Fast interrupt return to userspace

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: <CALCETrVHj1rd=ma-dW8C9RNyQNj3smRAyevWJSQXmvgshbQb6w@mail.gmail.com>
Date:	Tue, 6 May 2014 14:34:06 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Gleb Natapov <gleb@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [ABOMINATION] x86: Fast interrupt return to userspace

On Tue, May 6, 2014 at 2:25 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, May 6, 2014 at 2:00 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> I'll do profiles and test the kernel compile too, but the raw timings
>> are certainly promising. The "sysret" hack is pretty disgusting, and
>> it's broken too. sysret doesn't do some things iret does (like TF flag
>> etc), so it's not complete, but it's clearly good enough to run tests
>> on. It will definitely break ptrace() and friends.
>
> It clearly breaks other things too, and there seems to be bugs in
> there. I got this, for example:
>
> WARNING: CPU: 2 PID: 1174 at kernel/smp.c:230
> smp_call_function_single+0x81/0xa0()
> CPU: 2 PID: 1174 Comm: gdbus Tainted: G        W
> 3.15.0-rc4-00260-g38583f095c5a-dirty #2
> Call Trace:
>   dump_stack+0x45/0x56
>   warn_slowpath_common+0x73/0x90
>   warn_slowpath_null+0x15/0x20
>   smp_call_function_single+0x81/0xa0
>   smp_call_function_many+0x21c/0x260
>   flush_tlb_page+0x6d/0xb0
>   ptep_clear_flush+0x2c/0x40
>   do_wp_page+0x208/0x6e0
>   handle_mm_fault+0x79c/0x1060
>   __do_page_fault+0x15e/0x510
>   do_page_fault+0xc/0x10
>   page_fault+0x22/0x30
>   retint_swapgs+0x6/0x10
>
> which is because interrupts are disabled in that
> install_sysret_trampoline() path that touches user space. It's
> possibly sufficient to just move the "cli" to below the call to it. I
> eventually ended up with a hung machine, possibly related to this,
> possibly something else.

I don't think that's enough to fix this -- interrupts may not have
been on in the first place, I think.  I wonder if __put_user_inatomic
would work here.

Also, sysexit might be better than sysret.  And I categorically refuse
to add any new feature that requires vsyscall=native, so this would
have to use the vdso instead.  Plus it's awful.

>
> Whatever. I got enough profile data to say that it seems to have cut
> 'iret' overhead by at least two thirds. So it may not *work*, but from
> a "hey look, some random numbers" standpoint it is worth playing with.
>

:)

Is there actual interest in turning something like this into a real
patch?  It would almost certainly have to default off and no one sane
would ever use it except for special-purpose machines.

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