User Details
- User Since
- Oct 15 2014, 9:44 AM (467 w, 2 d)
Mon, Sep 11
This went through so many rebases that the incremental diff is not very helpful ;) Let's start over on github: https://github.com/llvm/llvm-project/pull/65996
Added the relevant bits of the great documentation John wrote in clang/docs/PointerAuthentication.rst. I tried to trim it down to only the general principles and the intrinsics; some of the discussion around the security model is a little ahead of the rest of the changes, but is still seems fine with these initial changes.
Jul 28 2023
We tried to address this problem by adding an XPACIuntied pseudo, only selecting that instead of the real instruction, and later (after regalloc, which is now unburdened by the tied nature of XPAC, like you're discussing) expanding it to add the mov if necessary:
Jun 26 2023
Jun 23 2023
Jun 22 2023
Jun 10 2023
Please don’t. I’ll send out updated patches.
Apr 25 2023
A comment inline, but LGTM otherwise, thanks!
Feb 28 2023
Feb 21 2023
Dec 8 2022
This makes sense, thanks for checking! I'll have a closer look on my side and follow-up if needed
Sorry for the delay; LGTM, thanks!
Oct 24 2022
Oct 20 2022
To make sure I follow: would it make sense to have the legality check compare the ptrauth bits, and if they match, remove the bundle and promote? We'd have to pass the pointer (not the Function) around. And I don't see how we'd get a signed pointer in the SampleProfile case, so we wouldn't promote there anyway (without a much more interesting target check at least?) But it seems like the other users would generate a direct ptrauth-bundle call to ptrauth-signed target; InstCombine should handle that.
Sep 26 2022
Sep 21 2022
but in AArch64TargetParser.def, marking them v8.6 brings in support for the SM4 cryptographic hash and we don't actually have that
Aug 30 2022
- add test for resign+auth -> auth
- further constrain GISel immediate blends to fail if wider than 16 bits
- Extract out XPACIuntied, leaving it for ptrauth-returns.
- Pull in key/opcode helper functions from later patch in the series.
Aug 22 2022
Jun 9 2022
Yep, committed c68b469e0788, thanks!
May 26 2022
May 20 2022
May 11 2022
Hi @nikic, I may have hit an issue with this change: when the noop-bitcast result is already used in other (potentially already selected) blocks, we already assigned a vreg for the value, and it may be too late to change it when selecting this bitcast. Concretely, this repro fails for x86_64 with -verify-machineinstrs, because the second use of %tmp1 uses a never-defined vreg:
Apr 20 2022
Apr 14 2022
Sure, filed 54914 to cherry-pick into 14.0.2
Apr 12 2022
D'oh, this fell through the cracks, sorry folks! I committed the fix I had in mind (cfa4fe7c5187). Long story short: this change exposed an old bug in the LOH pass: it wasn't honoring regmasks in bundled MIs, but since we used to split the bundle and emit the attached call separately, the (unbundled) latter was still visible to the pass. That's not true as of this change. I think for the sort of code that uses bundles on aarch64 it's usually selectors that get corrupted in a later msgSend, and that ends up exploding in dyld the way we're seeing in both cases.
Mar 23 2022
Reading this again, I have a feeling defaulting to newest will come back to bite us (or, well, apple folks.) But we can reevaluate if we get to that. So, LGTM, thanks!
The apple-* bits LGTM, thanks! @pcc caught a couple more in rGa8a3a43792, I still need to go over those as well
Ah, further down, there's a different crash signature in bisect6.txt, in dyld strlen: that one does ring a bell. I assume it's handling a corrupt selector, but there's not much context to know for sure. I have a later change that may take care of that, hopefully that resolves your original crash as well!
Mar 9 2022
Mar 7 2022
Thanks!
Mar 2 2022
Feb 18 2022
Feb 14 2022
I committed a modified description, happy to make more changes:
Feb 11 2022
Feb 8 2022
Jan 28 2022
Jan 26 2022
Jan 25 2022
Jan 24 2022
Same, makes sense, thanks!
Jan 18 2022
Dec 13 2021
Dec 8 2021
Dec 1 2021
Quite the old TODO, nice ;) LGTM!
Makes sense, LGTM!
Nov 18 2021
Nov 14 2021
Thanks all for the reviews! 68854f4e572a
Nov 11 2021
Hey folks! Any more comments?