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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVN9WB8kK5uZ==22TZe2WMS+6KAjH7p2s6=1MNFaE5V3w@mail.gmail.com>
Date:	Thu, 26 Feb 2015 07:21:36 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET

On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andy Lutomirski <luto@...capital.net> wrote:
>
>> >> I added that in and applied this patch.
>> >
>> > So this is not just slightly buggy, it's fundamentally
>> > wrong as well as it removes the possibility of an RSP
>> > value optimization from the 64-bit path, see my
>> > previous mail.
>>
>> This is just trying to check that the function is
>> executing on the per-thread stack.  It was correct (and
>> fairly heavily tested by Tony) wither KERNEL_STACK_OFFSET
>> being nonzero, but we're checking the wrong page if
>> KERNEL_STACK_OFFSET becomes zero.
>>
>> I don't think I understand your objection to this bit.
>
> I object to the KERNEL_STACK_OFFSET removal patch you fixed
> here, not to the add-on fix in particular (which is correct
> in the context of that patch).
>

Aha. I misunderstood.

I would object, too, except that I think that a better improvement
would be to build the entire frame using pushes, including the "top of
stack" part, even on fast-path syscalls.  That would have
KERNEL_STACK_OFFSET=0.

Actually, I want an even bigger change.  kernel_stack seems entirely
pointless to me, since we could just as easily be using tss.sp0 (I
think), as long as there's no useful offset.  So maybe the right way
to handle this patch would be to first clean up the ia32entry code and
all the non-asm users to use tss.sp0, and then to figure out what to
do about the syscall64 path.

I'd be happy to defer this patch until the FIXUP_TOP_OF_STACK cleanups
later on, assuming it can be easily extricated, which I haven't
checked yet.  Thoughts?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ