linux-kernel - Re: [RFC/INCOMPLETE 00/13] x86: Rewrite exit-to-userspace code

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]

Date:	Wed, 17 Jun 2015 08:16:41 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Brian Gerst <brgerst@...il.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	X86 ML <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [RFC/INCOMPLETE 00/13] x86: Rewrite exit-to-userspace code

On Jun 17, 2015 2:49 AM, "Ingo Molnar" <mingo@...nel.org> wrote:
>
>
> * Andy Lutomirski <luto@...nel.org> wrote:
>

>
> > I tried to clean it up incrementally, but I decided it was too hard. Instead,
> > this series just replaces the code.  It seems to work.
>
> Any known bugs beyond UML build breakage?

One minor one: the 64-bit and compat syscall asm changes should be
folded together.  I was overly optimistic about bisectability -- the
intermediate step doesn't build.  I haven't tested well enough to be
really comfortable with it, though.

There's another minor error in my description: the 32-bit code is not
a prerequisite for the exception_enter removal, so v2 will remove a
whole bunch of exception_enter calls.  This considerably improves the
quality of the debugging checks.

>
> > Context tracking in particular works very differently now.  The low-level entry
> > code checks that we're in CONTEXT_USER and switches to CONTEXT_KERNEL.  The exit
> > code does the reverse.  There is no need to track what CONTEXT_XYZ state we came
> > from, because we already know.  Similarly, SCHEDULE_USER is gone, since we can
> > reschedule if needed by simply calling schedule() from C code.
> >
> > The main things that are missing are that I haven't done the 32-bit parts
> > (anyone want to help?) and therefore I haven't deleted the old C code.  I also
> > think this may break UML for trivial reasons.
> >
> > Because I haven't converted the 32-bit code yet, all of the now-unnecessary
> > unnecessary calls to exception_enter are still present in traps.c.
> >
> > IRQ context tracking is still duplicated.  We should probably clean it up by
> > changing the core code to supply something like
> > irq_enter_we_are_already_in_context_kernel.
> >
> > Thoughts?
>
> So assuming you fix the UML build I'm inclined to go for it, even in this
> incomplete form, to increase testing coverage.
>
> Doing that will also decrease ongoing merge friction between your work and other
> entry code cleanups ...

Sounds good to me.  I'm not convinced this is 4.2 material, though.
Would it go in a separate branch for now?

On a related note, do you have any idea what work_notifysig_v86 in
entry_32.S is for?  It seems unnecessary and wrong to me.  Unnecessary
because we have return_to_32bit.  Wrong because I don't see how we can
reliably enter vm86 mode if we have exit work enabled -- one of the
giant turds in vm86_32.c literally jumps from C code to
resume_userspace on vm86 entry, and resume_userspace promptly checks
for work and might land in work_notifysig_v86 before we ever make it
to v8086/user mode.

I think it may actually be impossible to use vm86 under ptrace.  ISTR
I had some trouble when trying to strace my test case...

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