This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: rseq notes from Cauldron
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: nd <nd at arm dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 25 Sep 2019 09:34:14 +0000
- Subject: Re: rseq notes from Cauldron
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vTcYyaiy1LypMJe+6pikZ4Ue2eC6JqKzoRyznlYvY6s=; b=EQqv2Q5AiyNsts4jdV3IYZ/xX9ItCLlpVShWDHP4dD0IFG+YsAPzybFInekkb4xbrc/VdCwxpECW3eeXvhHmFiNrc4bu2XldVjpm+ABCk4SWud1tLdkSxy97GK/ekifrNp6dObq3KhUroZ2TYujmdhGg/s2j2hOvZhytDUAZYS9ujvJREQuJdK+KnZADvP5PbPxNksQ6GYnEEXRBVxz/8YnO+UWl47Fi4uOLbJpCNwhJio1spO++m5+zvnhKUq5TtIfMXMvZFVHL6PHMYmyJ2o6mdaVdMpTwibA8pQu/3OHw0SCJh2lxibEm2obMnQrzmYE/MngN9dOIP6j9MZ2rIA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Essjsc/f7QRy68I+945VLQbYi4yg0ZSsGsgbbox/CBkZCAVrByj6TAtImmzvetzo6c7vzxyv0AU1DHJpwel1L9ylyxD9NX0TMGimtaDCzsPZFG8DSbQNxCEbqo57forerpbwlaHRO1h8rS6S7JIZAF3LIlufJWIu6osVdbamaT67SPIXQjfVDAYAwxjq5PzOAau5twk10mLy3HODhkcMmmiXl4wCfERSU41Qtp6aGNoE7KcgyiUWHyjMeOSUlzTwSo1rCWXWgo0sNoePoEvXrvmDSNLYLPFBQyvgrVlJ+9QmkkneO32Fk9SXttW2h0H1Apng+fYDVOal8TnJoVCaQw==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <87ef07csex.fsf@mid.deneb.enyo.de> <1285381727.4142.1569252874259.JavaMail.zimbra@efficios.com> <871rw79g7c.fsf@mid.deneb.enyo.de>
On 23/09/2019 16:37, Florian Weimer wrote:
> * Mathieu Desnoyers:
>>> We need a comment somehwere in NPTL about the reliance of the rseq
>>> area on implicit deregistration. This is currently not a problem
>>> because it lives on the stack (as static TLS), and the stack outlives
>>> the thread. But if we ever change the TCB allocation, additional
>>> steps may be required. It is NOT sufficient to block signals because
>>> the kernel may write to the rseq area even without signals. This
>>> should go into the rseq patch as well.
>>
>> This adds a hard requirement on using the IE TLS model AFAIU. Another
>> action item on my end.
>
> Yes, but given that glibc already has initial-exec TLS, the rest has
> to be initial-exec, too, I think. At least in the current
> implementation in the loader.
i think dynamic tls cannot be used for rseq anyway
because rseq wants to be signal safe and lazy alloc
of dynamic tls is not as-safe in glibc.
which means a library that provides the rseq abi
cannot be dynamically loaded.