From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12486 Path: news.gmane.org!.POSTED!not-for-mail From: Nicholas Wilson Newsgroups: gmane.linux.lib.musl.general Subject: TLS storage offsets for TLS_ABOVE_TP Date: Fri, 9 Feb 2018 18:07:25 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1518199551 17811 195.159.176.226 (9 Feb 2018 18:05:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 18:05:51 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12502-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 09 19:05:47 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ekD3N-00043P-KW for gllmg-musl@m.gmane.org; Fri, 09 Feb 2018 19:05:41 +0100 Original-Received: (qmail 19811 invoked by uid 550); 9 Feb 2018 18:07:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19770 invoked from network); 9 Feb 2018 18:07:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realvnc.onmicrosoft.com; s=selector1-realvnc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zyu2uNBoFdnd49cY8WDO92UXnYMtUZetKJPuPfBWGTw=; b=o3FrcmKx1qZyH5u8/O2qMTJXQXwtV/abFHtI3iRBBtFevwP5PVVnAHgdA1qifS1fEKYPkBhho4I3na35wk1EZUJEoeFXI/EvquVo2+AwKAgZYsebq7sxjm2GwsLJbSsqBYshk+hsJMUgj4p5q4g9NM6plkLis/JuyhWk8B5dqG0= Thread-Topic: TLS storage offsets for TLS_ABOVE_TP Thread-Index: AQHToc3LpwLt+qc8e0mibWaiCHzqSg== Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nicholas.wilson@realvnc.com; x-originating-ip: [2a02:390:a001:192:d6be:d9ff:fe9c:1892] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0502MB2917;6:5N+vIqWUh6SjmuZ4jnSkQbXdzC9DDtU+3uA/Ey2rWkjFRj9VZ6LKl1p7AOiEc3ybVnzeOsS9P0SsHGVD4IAPOkapuj+HhuMDnlpJ0lbvJ3XzvCiClkh+WxztRnZs2YxLFLbhYWX89e2iJt1TEX6M4y06WXHxpqFrbgtJ7744eSzDNaKA/VFyOftsV+fFI5YqcwpxLuYdAGZ5lGZ2Ir21Q7YnU92PH3vuD5515g7N1Y7TdgqULFDWPuFO/SDMxFAVzG4ukcxFztJ2M6Tl+6azRuCwk0I9yOHP+2vISOF9TBDU39rzQt4dgn7923Rmo2vp+s+uoO5N3QwSsAe1p639pi56I5X86wV9VK943Za5FjVwMSeBq9+8ygrN4sYct1u1;5:/ED5qAkzJSmJ0TXFM5OIvtMP1iY8eQwIWcJ6hroMpme0/N9L5roGrQiOFZbxys0ZaKFttQ1dsP4kpsk6ZkP1DWIxbgnSwx2i29s7Zfp1KTzMo7S/5EUY5SqHC5HWHuSfH1WsZflt0LglfQVVBQSZvCHK0jfwSBlA5ph7D/4Xqmw=;24:Kdo7M+EsU8/HrT37r+0SeiA3QMWvNdWbWo2hTw6F2ZL5IsianNWOkhlgpfHR9kLgJhC7p+VDd2oMH3co+Q3eR8vgm/mmCoz/Y7p9hpHfdsI=;7:wXzlXchxVkkai1h5rvmD/ebSo9pJKy0vNpJJEBw1QtgT3i7VUVPmcMDOZOYt74tzod9woe4L i/EjBEKuCSUWY9+szNtbjTYHKYWPl7DN/r+TGv52QHFxbpMu/YOKQPRTJfKrcBcTMxanU6H4mwtlN2MIRe27b1Lpb0MvAr0Y6z x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8dbbe3b5-49a7-4a9a-c9f6-08d56fe7f97b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020);SRVR:DB6PR0502MB2917; x-ms-traffictypediagnostic: DB6PR0502MB2917: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(6041288)(20161123562045)(2016111802025)(20161123560045)(20161123564045)(20161123558120)(6043046)(6072148)(201708071742011);SRVR:DB6PR0502MB2917;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0502MB2917; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(366004)(346002)(39840400004)(396003)(39380400002)(54094003)(189003)(199004)(8936002)(68736007)(7736002)(3280700002)(6116002)(3660700001)(2906002)(2351001)(106356001)(102836004)(1730700003)(8676002)(74316002)(81156014)(316002)(305945005)(186003)(7696005)(81166006)(6436002)(6506007)(59450400001)(5660300001)(53936002)(55016002)(14454004)(5640700003)(5250100002)(25786009)(478600001)(33656002)(99286004)(9686003)(105586002)(97736004)(2501003)(86362001)(6916009)(2900100001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0502MB2917;H:DB6PR0502MB3016.eurprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: realvnc.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nKe2jB0U5BC4X72NTdpmuwNhU2fTHM/Oom0LgRjwJay911TZXlUpT8dHnxolF+wIV4kgW+1JZB1pe8cCDbzHzg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-MS-Exchange-CrossTenant-Network-Message-Id: 8dbbe3b5-49a7-4a9a-c9f6-08d56fe7f97b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 18:07:25.5467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9ad766d3-c6a5-4458-8c58-244e7c118728 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0502MB2917 X-OriginatorOrg: realvnc.com Xref: news.gmane.org gmane.linux.lib.musl.general:12486 Archived-At: Hi, I have a question about the support for TLS_ABOVE_TP ("TLS variant I"). In archs like ARM, we have a matched pair of functions TP_ADJ and __pthread= _self, which adjust a pthread* to the thread-register and back again. For A= RM, there's an additional offset of 8 (and 16 for AArch64), which is part o= f the ABI to ensure a) the TP points to the DTV, and b) the main module's T= LS block is at a known offset from the TP. However, the ARM adjustment code uses "TP =3D pthread* + sizeof(pthread) - = 8". That's correct for the arch ABI, in that the linker requires that the t= hread storage be located 8 bytes above the TP, and Musl does indeed store t= he TLS block there right after the struct pthread. But what's odd is that you have the pthread->dtv_copy member right at the e= nd of the pthread struct. So the thread pointer is pointing not to pthread-= >dtv_copy, but actually to pthread->canary_at_end. Is my mental compiler going wrong? I don't have an ARM machine to actually = execute the code on, but I've just been staring at it for an hour and can't= work it out. One thing I have noticed is that in all the four TLS models (general dynami= c, local dynamic, initial exec, local exec), the DTV isn't actually derefer= enced directly by compiler-generated code. The whole thing about having the= DTV available to the compiler in a known location in fact is not used! So = maybe that's how you get away with. For the sake of "correctness" and conformance though, I wonder if there sho= uld be a final "void *dtv_pad" member at the end of struct pthread, so that= the DTV block at the end of the struct pthread has the right size for the = platform. I'd be happy to hear I'm wrong! (Maybe a diagram in the source code would h= elp comprehension, to show how the memory is laid out, including the alignm= ent bits and pieces. The FreeBSD libc source code has a helpful bit of ASCI= I art that draws the layout of the various bits of data and the alignment b= locks between them.) All the best, Nick=