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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <561E895E.7050905@list.ru>
Date:	Wed, 14 Oct 2015 19:57:02 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Cyrill Gorcunov <gorcunov@...il.com>,
	Andy Lutomirski <luto@...nel.org>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit
 signal context

14.10.2015 19:40, Cyrill Gorcunov пишет:
> On Mon, Oct 12, 2015 at 06:04:07PM -0700, Andy Lutomirski wrote:
> ...
>>
>> For the benefit of new 64-bit software that uses segmentation (new
>> versions of DOSEMU might), the new behavior can be detected with a
>> new ucontext flag UC_SIGCONTEXT_SS.
>>
>> To avoid compilation issues, __pad0 is left as an alias for ss in
>> ucontext.
>>
>> The nitty-gritty details are documented in the header file.
>>
>> Cc: Stas Sergeev <stsp@...t.ru>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Cyrill Gorcunov <gorcunov@...il.com>
>> Cc: Pavel Emelyanov <xemul@...allels.com>
>> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> 
> Andy, so for old criu versions (prior the 1.5.1 which is Mar 2015,
> in next versions we already write proper ss into the images)
> we've been providing __pad = 0, which is ss in a new meaning,
> and the kernel will overwrite it with @user-ds after this series,
> correct? This should work for us. Stas, mind to refresh my memory,
> which ss value doesmu setups here?
Nothing.
Older dosemus didn't care about touching __pad0, so
whatever kernel saves there, is still there, even when
dosemu needs another value.
The problem starts to happen IIRC when dosemu invalidates
the LDT entry that was previously saved by the kernel as an SS.
IIRC this was causing the SIGSEGV right from sigreturn().
It is actually a bit annoying to have such bad code in kernel
only for the sake of the older dosemu.
--
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/