From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26090 invoked from network); 7 Dec 2021 18:57:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Dec 2021 18:57:38 -0000 Received: (qmail 24500 invoked by uid 550); 7 Dec 2021 18:57:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24478 invoked from network); 7 Dec 2021 18:57:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=T6SYGH10GCiZHed4zQKCALps7AmV6MDS73Mux+s7yxU=; b=X0XpHt0UX8gmM4YisgaxGt1WSlDPf1pZGRiPYxl+yc4obTZdnjtkXkDGDWOfdf0VIP /KGBfpmT7jSNDSQGKvsaGLQI/wNV8WH/RNxdSYumNPStQuRDsOSbfceDZvM9KijuOoZS Atnbv/sSQfZULuubdUZDCqJE/FE6sI2z/G7vW4W3dv3m1RW9Ok6ptc0Fe3OvhPppRspM pAzVo9GXDx05CUUvuisDAsvAKFdHH84+fr45y98t3JFUt+r/k+eL4Q0aHgwrpuskyYup JPKNX18Vhkw0rYLNIRMF/njzZn6ddbqvkc707kcDXD38LvMkamDpr/j+Jj9LdabiezPP vG0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=T6SYGH10GCiZHed4zQKCALps7AmV6MDS73Mux+s7yxU=; b=MrSrryVEGEG3yI3zCqFv/vCiqlITMG9M7EBRhDS25cdbAnHlQE/iitSzILy9LaECGb M7DnX4tDeKxFhemYIJb29Srjln574Hbtkx7woLYu8ZqmF75+osdEh4abmwHNB2V80C1e CIz1aAohNrHNQ9z/AnqPg2+fOUi4h68kmg7JhuuOEHxghHg4qMn9fuvUW5umZWtaDHeQ hSNKWqoE/9pLJRkECVRTUzp5W43ckOBafu+djVoejpZQVlAZwGNPzVGeWpD2jxkEAGY8 QF0HMInYuu248IlVA9VHFvS9LIpSbOyQjjsoSqgi6t2im7mfpx7eUcrdrSQRzvSa0iX1 AuTA== X-Gm-Message-State: AOAM531yQGfmDjFm0WIS85v2e1DkK+RPx1b7JzEozuZZIYDCqi7mvFEn C+81eJT5oI/zK4s93VjECBDrTndTlbUwDbHUhUihurE7 X-Google-Smtp-Source: ABdhPJw0699OXuHwMHl+u2sPyGUq6DiuWpVng7oNqLAuzANsaGj3kk6cAJOlWWZTM9ymgiDMAxFLkfUycoWuRjjkp5s= X-Received: by 2002:a17:90b:3a89:: with SMTP id om9mr1183905pjb.29.1638903443039; Tue, 07 Dec 2021 10:57:23 -0800 (PST) MIME-Version: 1.0 References: <20211206234358.2174444-1-stijn@linux-ipv6.be> <87tufljlmv.fsf@oldenburg.str.redhat.com> <20211207005940.GK7074@brightrain.aerifal.cx> <20211207013930.GM7074@brightrain.aerifal.cx> <20211207132509.GO7074@brightrain.aerifal.cx> <20211207183933.GA8506@voyager> In-Reply-To: <20211207183933.GA8506@voyager> From: David Edelsohn Date: Tue, 7 Dec 2021 13:57:11 -0500 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [PATCH] ppc64: check for AltiVec in setjmp/longjmp On Tue, Dec 7, 2021 at 1:39 PM Markus Wichmann wrote: > > On Tue, Dec 07, 2021 at 08:25:09AM -0500, Rich Felker wrote: > > On Mon, Dec 06, 2021 at 08:44:47PM -0500, David Edelsohn wrote: > > > It should work, but it's slightly preferred to use $+4 because one > > > explicitly wants the address of the next instruction and labels of the > > > > In this case we don't want the address of the next instruction. We > > want the address of the constant __hwcap-. > > > > Rich > > According to at least one source I found at some point (and can't seem > to find right away), "bcl 20,31,+4" is the one special form of the > instruction that is most likely to circumvent the shadow stack. I have > seen "bcl 20,31,label" in the wild, even in cases where the label didn't > directly follow the instruction, so maybe it works, maybe it doesn't. > > That said, architecturally it will work either way. We are only talking > about an implementation detail, and both IBM's and Freescale's/NXP's > documentation is very cagey about revealing any of those. The > instruction is specified to exist and do the right thing (namely to > branch with linking unconditionally) all the way back to the first > PowerPC implementations from the early nineties, but whether such a > thing as a branch predictor even exists, or if it uses shadow stacks to > predict the "blr" target, is entirely unspecified. > > So yeah, you might want to restructure the code to move the hwcap offset > somewhere else. Only "$+4" is documented. As you wote, it probably would be best to place the offset somewhere else. It also is not good practice to have arbitrary bit patterns of data that potentially are not valid instructions in the instruction stream. Thanks, David