On Wed, 8 Jul 2026 21:20:00 GMT, Ashay Rane <[email protected]> wrote:
>> This patch adds MSVC's "/guard:signret" flag to the C/C++ compilation
>> flags so that the VM code includes signing and authentication
>> instructions to ensure that the return address is not tampered by any
>> callee. Specifically, MSVC chooses signing using the B key, so every
>> non-leaf function starts with the `pacibsp` instruction (for signining
>> the return address) and ends with the `autibsp` instruction (for
>> authenticating the return address). Both `pacibsp` and `autibsp`
>> instructions are in the NOP space, so older AArch64 processors that do
>> not support these instructions shouldn't be impacted by these
>> instructions.
>>
>> As a matter of slight detail, this patch adds the "/guard:signret" flag
>> only when the OpenJDK build is passed the "--enable-branch-protection"
>> flag, which is off by default. Consequently, this change will not
>> impact ordinary builds of OpenJDK.
>>
>> I've validated this patch by running the test/jdk:tier{1,2,3},
>> test/hotspot/jtreg:tier{1,2,3}, test/langtools:tier{1,2,3}, and
>> test/lib-test:tier1 tests with branch protection enabled. This patch
>> does not introduce any new failures.
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Ashay Rane has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove redundant conditional preprocessor guard
>
> This file is only built for Windows/ARM64, so we don't need to check of
> `_M_ARM64`.
Regarding the test you've done, IIUC, you built one JDK with
`--enable-branch-protection` and ran the jtreg tests with VM option
`-XX:UseBranchProtection=standard`.
Note that as listed in https://bugs.openjdk.org/browse/JDK-8388072, I found
~500 jtreg failures on Linux/AArch64(i.e. Neoverse-V1 cpu). I was wondering
did you find any jtreg failure on Win/AArch64 side? Thanks
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31795#issuecomment-4934640651
