linux-kernel - Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

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, 13 Aug 2015 12:49:20 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

On Aug 13, 2015 12:05 PM, "Stas Sergeev" <stsp@...t.ru> wrote:
>
> 13.08.2015 21:41, Andy Lutomirski пишет:
>
>> Stas: I think uc_flags is okay.  We don't currently read it during
>> sigreturn, but I see no reason that we can't start reading it.
>
> Andy, we definitely have some communication discontinuity here. :)
> The point is not sigreturn. If we are talking about the flags that
> will in the future control also TLS, how would you limit it to sigreturn()?
> It should control the restoring of FS _on signal delivery_, not only
> on sigreturn()! So how uc_flags can be used for this at all?

Ah, you want it restored on signal delivery.  What would it be
restored to?  ISTM that can be done easily enough in user code, so
maybe we should leave it to user code.

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