From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753977AbbJNSeX (ORCPT ); Wed, 14 Oct 2015 14:34:23 -0400 Received: from smtp33.i.mail.ru ([94.100.177.93]:51127 "EHLO smtp33.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753682AbbJNSeW (ORCPT ); Wed, 14 Oct 2015 14:34:22 -0400 Subject: Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context To: Andy Lutomirski References: <6e14e2f7ce1c38fc1996bd4d5d3d9dc70b8bd94d.1444697927.git.luto@kernel.org> <561D1C53.8080302@list.ru> <561E93A9.3030500@list.ru> Cc: Denys Vlasenko , Pavel Emelyanov , Borislav Petkov , "linux-kernel@vger.kernel.org" , Cyrill Gorcunov , Brian Gerst , X86 ML , Linus Torvalds From: Stas Sergeev X-Enigmail-Draft-Status: N1110 Message-ID: <561EA021.9060901@list.ru> Date: Wed, 14 Oct 2015 21:34:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. >>>> - with siglongjmp() >>> >>> siglongjmp is a glibc thing. It should work the same way it always >>> did. If it internally does a syscall (sigprocmask or whatever), that >>> will override SS. >> IMHO this side-effect needs to be documented somewhere. >> I was scared about using it because I thought SS could be left bad. >> Why I think it IS the kernel's problem is because in an ideal world >> the sighandler should not run with LDT SS at all, so there will be no >> fear about a bad SS after siglongjmp(). > > I agree, but that ship sailed quite a few years ago :( Please, once again you are claiming there were no solutions proposed in that area. :( If you didn't repeatedly ignore the SA_hyz solution, there will be the chance to do exactly that. But whatever.