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: <CA+55aFx8UQGS_anYJrSkkzeM+vx97-2sAUTTE6ZxDJNUKTkD0Q@mail.gmail.com>
Date:	Tue, 6 May 2014 14:48:50 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
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:34 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> 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.

That might be the way to go, yes.

And in addition to the CS value you should probably check that TF and
RF are clear in eflags, and possibly other things too that the sysret
doesn't get right compared to iret.

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

Yeah, it's disgusting. I think it is worth fixing to get better
numbers (it *would* be very interesting to hear whether this plus the
kernel 'retq' thing actually makes real device interrupt overhead
lower), but I'd be very wary of using it in production.

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

I don't think it's necessarily worth actually merging, but maybe a
couple of improvements makes it go from "disgusting and unmergeable"
to just "disgusting". The "avoid iret for return to kernel mode" thing
might be more easily merged (but needs similar CS content checks to
make sure we're ok with BIOS/EFI execution environments)

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