From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-91299-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 53401 invoked by alias); 29 Mar 2018 20:20:32 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 53232 invoked by uid 89); 29 Mar 2018 20:20:31 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=H*F:U*fw, subsequently
X-HELO: albireo.enyo.de
From: Florian Weimer <fw@deneb.enyo.de>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Joseph Myers <joseph@codesourcery.com>,  "Carlos O'Donell" <carlos@redhat.com>,  "Tsimbalist\, Igor V" <igor.v.tsimbalist@intel.com>,  GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] x86: Add __sigsetjmp_cancel and __setjmp_cancel
References: <CAMe9rOoB0t6CffwX-wgbBGNtaGgD923WoWmrtCjiXLc5pm=Z9g@mail.gmail.com>
	<alpine.DEB.2.20.1803151634160.26519@digraph.polyomino.org.uk>
	<CAMe9rOpLdFLbUE4NCH8L0C8CPMKtcMOepwhSr3PdpfnTgqHBqA@mail.gmail.com>
	<87efkkxwah.fsf@mid.deneb.enyo.de>
	<CAMe9rOo6XFKmaPhL2rg4VZQ_tp3bm1ioCD7m2X=r-vmu6G=jOg@mail.gmail.com>
	<CAMe9rOqaF+eVmQ=THJUro5=gw=PRn7FjQghXUVRC85zFKKGLRw@mail.gmail.com>
	<871sg2wzsv.fsf@mid.deneb.enyo.de>
	<CAMe9rOo9YonsZXhZOyL49VG3KojV_83+dskr6BpuMTBgpNuX3w@mail.gmail.com>
	<87bmf6vfbp.fsf@mid.deneb.enyo.de>
	<CAMe9rOoiD5NH-p5JqFvxkXnGh79bZShuab9k7DqhyT6qKYFPuw@mail.gmail.com>
	<87605eve34.fsf@mid.deneb.enyo.de>
	<CAMe9rOr6GV4B=uK-0gvwL3TS4gbUV-H=ooX=kR0ETJHAkX6uTQ@mail.gmail.com>
	<87zi2qtz7s.fsf@mid.deneb.enyo.de>
	<CAMe9rOq3RDki6qS6GUuEKn2jrXuJzbpZGXRKh_KKBcQaU3pGJw@mail.gmail.com>
Date: Thu, 29 Mar 2018 20:20:00 -0000
In-Reply-To: <CAMe9rOq3RDki6qS6GUuEKn2jrXuJzbpZGXRKh_KKBcQaU3pGJw@mail.gmail.com>
	(H. J. Lu's message of "Thu, 29 Mar 2018 13:17:54 -0700")
Message-ID: <87vadetz09.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2018-03/txt/msg00606.txt.bz2

* H. J. Lu:

> On Thu, Mar 29, 2018 at 1:15 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * H. J. Lu:
>>
>>> You need to make a choice.  You either don't introduce a new symbol
>>> version or don't save shadow stack for thread cancellation.  You
>>> can't have both.
>>
>> I don't understand.  We have room to save the shadow stack pointer in
>> the existing struct.
>
> No, we don't have room in struct pthread_unwind_buf:
>
> Note: There is an unused pointer space in pthread_unwind_buf_data.  But
> it isn't suitable for saving and restoring shadow stack register since
> x32 is a 64-bit process with 32-bit software pointer and kernel may
> place x32 shadow stack above 4GB.  We need to save and restore 64-bit
> shadow stack register for x32.

We have for void * fields.  They are subsequently overwritten by
__pthread_register_cancel.  But __sigsetjmp can write to them first
without causing any harm.  We just need a private __longjmp_cancel
that doesn't restore the shadow stack pointer.