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 26170 invoked from network); 7 Dec 2021 18:57:57 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Dec 2021 18:57:57 -0000 Received: (qmail 26251 invoked by uid 550); 7 Dec 2021 18:57:55 -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 26225 invoked from network); 7 Dec 2021 18:57:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1638903463; bh=/R6BeVD+H9UQYhv8k/Qxd5UVnPp/opAsOKNKTkfsFuQ=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=JZUk2Hp6A7MPRt7DfJ50F4rDJMvDM8KkjJoMv9Zu2EFzKD+ra0gnXSDnd5Ry6e71b 4ID5eJPNhD6s6nWlc5AppUeWj8GiQ6kihbz8jnAKD/eF8NgurzCH5z1rS7jVItq0G8 0aUlbr5//xRZ4KB3UcAmxQg3XyK79TVR8QN9kYjA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 7 Dec 2021 19:57:43 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20211207185743.GB8506@voyager> References: <20211206234358.2174444-1-stijn@linux-ipv6.be> <87tufljlmv.fsf@oldenburg.str.redhat.com> <20211207005940.GK7074@brightrain.aerifal.cx> <20211207013930.GM7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:HiZ0RUkNk1BXXyV/NSE1MA63iORTyAWtigdPJmYJGmLuKfJlhSl p+xwwVqordchMoswqeOn61pSMTI9FMtyJaK5dGiFr6kHcdq/5q+w2EAxi3A4mOQNlsnMCQP YkFEge75ryfsfO7nMdpaGYwkhEppeMC7DMksf+5OoqT7mmpGHSaBEn8NSOG45MrOQcp2ocI gTnCyoh0UyQW+A/dECZMA== X-UI-Out-Filterresults: notjunk:1;V03:K0:BJRNcw/gnos=:p8yNgdLfmGOTGbcbWubxKk arlsmPbK2TpxGzGp/aPevpc1sLGscmCFjX2JBsbHXB84RNwyG1HeTXmrsa3aUDUS06uwBfvRN XLRsbihTbOXcRN5+W7UjhO+4W4jMRijZrmVPEWuooykix02aK9X1+lNMZ85dauZU8UqyBye/g Un+q+oXtbxK/64S6DXncJs0TJMMqyjjZKsdg1pJxdyYVJ/u4cEe+gsHiVdetbTuHhGb4zYDEf xyA7kLBdqTz5s7vcyCQq1q+G9AAJE1NPRYCIPasGNZpQg1ISClk8AN//irRX5qFztjGK3cMtH slDHcpM726nqXEH5WRm6Pz7D25oilSM1tf/Yayp4rOMDbbiivKBCG53t4hQ8AZovtWGDXGACD a5kYzU/jiqilR2s9MlfiQWsQcUTMUpdPMwluBeMCXrKiXlWv7zhCKFBjLkVsN0hObRzeqkCm7 4Flj6vv9s8s9P+yCxYe8pu1j3QuS8AKUTw1cwP2pLYfr/3iZmBQw6Pzlg2wX2Ks1zwkl+pLT+ jHK+LvL3mf7U8KXaZvIPyAcrcWwLdNh8cfvO0WTRNTxycmDigNzf4vMV7UDQSQoCRlV+6MsMa j1jT5FhXBtJhlW6XkXLx3DD9RppOtJp31jm6veM0Ck9QooDqH6KDJ0GmLxDEiozKgokr4XTZI IQ9yX1CuDkRn9b7apNPG/zI7+DNuwLst3YE0xVwhK4MtPTgYeD+RIUKMY6KKvRIAmLGT6LDHi 3MI0UcKtY7JkwrB4vMxTZ1rDUUODbs+6nJSPR1KC2miFyXFGQ+vmyCGkpf0jTVWAyu+XyzBpk CIYs8sUwWCPsms7o1ZT42fvRa/VzrvtTVYCPKxxF7LZTgjJGE83e9p34QkCkPcG+RFx46aBa7 2foKgTd7RckGskRpVtamfXAw7MHrHr5tkZnML56ALnvtsf7aJ9DZWQRpgB/nSAdYT3VHX37NT bJr7g7UVbJaXl9mwyYGu5S5zwgWYb5QbOk3gLjS7bgZxmIZEOSPLFfvpvIlpR0aqiHZhpNTQm B2JbX+6M1rJFKvdy5Kv0DmXMvbuP8wYQoTL8bbupBXbRoLyQuVbxOFdUzmObuvhhbcMHcS2Nu 1ysZ57WA4TrIb0= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] ppc64: check for AltiVec in setjmp/longjmp On Tue, Dec 07, 2021 at 01:27:08PM -0500, James Y Knight wrote: > The important question at hand is whether the hardware treats "next > instruction" as a critical part of the special case. The recommended > sequence is: > bcl 20,31,$+4 > next-instructions... > > But, does the hardware _also_ trigger the expected special-cased effect = on > the return stack when jumping to locations other than the next instructi= on? > E.g. is this OK w.r.t. return-stack? > bcl 20,31,$+8 > .long __hwcap-. > next-instructions... > > On X86, calling *exactly* the next instruction is how you trigger the > special-case in the return-stack-predictor. But, it sounds like > potentially on PPC, the address is not part of what triggers the > special-case. Is that correct? > In all the code I've read, people seem to gravitate towards the +4 form if they can possibly help it. So I guess it really is the entire instruction that is special. That said, architecturally the right thing will happen either way, and if any kind of shadow stack is even involved or successfully circumvented is in the hands of the implementation, and all implementers whose documentation I have read so far have been very stingy on implementation details like this. The difference with X86 is that in case of PPC we are using a different instruction entirely to get the instruction pointer. X86 only has the one call instruction. Also, I'd thought the return stack was the reason for GNU to add linkonce capability to the linker. Because at some point I started seeing linkonce functions that read the return address into a register and return crop up in assembler listings generated by GCC. I didn't know there was a way to circumvent that stack. Ciao, Markus