On Mon, 24 Jan 2022 16:44:23 GMT, Andrew Dinn <ad...@openjdk.org> wrote:
> These test fixes all look like they are doing the right thing and are > localized to systems that have PAC_RET support. > > It was a bit of a surprise to realize that double-protecting was a faux pas > and, in consequence, that there there were places where a protected address > was being encountered where a raw one was needed. It makes me wonder if there > are other places where that might happen lying dormant which just happen not > to have been found by any existing test. Do we have any way of systematically > excluding that possibility (I supsect the answer is no but I have to ask). check_return_address() is being a huge help here. Before signing, the check is used to confirm it's a raw value. Meaning we get a segfault at the point of the second sign. It's a fairly straightforward process to then figure out that issue. (Without the check, the segfault would occur on return after the authentication. Which could be a long way away from the signing. From experience, that's not a fun debug journey.) There might still be some places where that code path is currently not executed today by any of the tests. There's no obvious way to catch those issues. Once this is in, getting some regular testing will be fairly crucial to make sure it doesn't rot. ------------- PR: https://git.openjdk.java.net/jdk/pull/6334
