linux-kernel - Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

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:	Thu, 15 Oct 2015 00:37:58 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Brian Gerst <brgerst@...il.com>, X86 ML <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit
 signal context

14.10.2015 21:52, Andy Lutomirski пишет:
> On Wed, Oct 14, 2015 at 11:34 AM, Stas Sergeev <stsp@...t.ru> wrote:
>> 14.10.2015 21:06, Andy Lutomirski пишет:
>>>> Also it doesn't seem to be saying what happens if CS is 32-bit
>>>> and SS is invalid (the flag is not set).
>>> A new signal will be delivered.  sigreturn doesn't modify its behavior
>>> in this case -- it does the default thing, which is to honor the SS in
>>> the saved context.
>> Hmm, no, it didn't do this in the past for sure.
>> It simply ignored SS, no matter to what mode it returns.
>>
> What I mean is: it has the behavior it would have normally on a new
> kernel, which is to honor the saved SS.  I'll try to improve the
> comment.
>
>>>   So it will actually try to use that saved SS
>>> value, which will fail, causing SIGSEGV.
>> So it seems this logic assumes that when dosemu returns to 32bit,
>> the previous SS is always still valid, am I right with the understanding?
>> I.e. the one that kernel have saved on a signal delivery (because
>> old dosemu does not overwrite it).
>> If it is so, I'd say this assumption is very risky and will likely
>> not hold. But maybe I am missing the point.
>>
> That's the assumption.  If I understand correctly, though, old DOSEMU
> never actually returns to 32-bit using sigreturn in the first place,
> since old kernels gave no control over SS.  Doesn't old DOSEMU always
> return to the 64-bit IRET trampoline?
Ah, so the old progs simply never return to 32bit, so you
implement the "Right Thing" (tm) for them, thanks. So the whole
point of UC_STRICT_RESTORE_SS flag is not for the software to
control it, but just for the kernel itself, so that it knows from
whether 32 or 64 bit the signal came. This is probably quite
undocumented in both the comments and the patch description,
and I was confused because the approaches we discussed before,
were targeted on the flag that is written by user-space. If this my
understanding is correct and the flag is just an indication rather
than a requested action, perhaps the name should be different,
e.g. UC_SIG_FROM_32BIT or the like?
Anyway, this is minor. :)
I'll try to test the patch within a few days, thanks for you time!
--
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/