Page MenuHomePhabricator

[StopInfoMachException] Summarize arm64e BLRAx/LDRAx auth failures
ClosedPublic

Authored by vsk on May 13 2021, 11:05 AM.

Details

Summary

Upstream lldb support for summarizing BLRAx and LDRAx auth failures.

rdar://41615322

Diff Detail

Event Timeline

vsk created this revision.May 13 2021, 11:05 AM
vsk requested review of this revision.May 13 2021, 11:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2021, 11:05 AM
DavidSpickett added a subscriber: DavidSpickett.

I think the test files should go in test/API/functionalities/ptrauth_diagnostics/ instead.

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/BLRAA_error/blraa.c
19 ↗(On Diff #345224)

What is the purpose of the // Before: blocks here? Simply to give you a clue what happened if the test fails, or something else?

(I guess I'm really saying "Before", before what exactly)

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/LDRAA_error/TestPtrauthLDRAADiagnostic.py
5 ↗(On Diff #345224)

If you're on/connecting to arm64e you can assume a toolchain that supports ptrauth, correct?

(we (Linaro) will probably extend these tests for to run on AArch64 Linux and there we would need to check toolchain support or use hint space)

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/brkC47x_code/brkC47x.c
10 ↗(On Diff #345224)

Can you explain in this test what brk 0xc470 means?

lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
1055

Comment what the meaning of the break code is. (or range of codes, 0-4 I guess)

Best guess is that this brk causes the cpu to authenticate a code held in x16, some kind of control flow check?

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
92

Worth asserting that abi_sp is valid? Though for Mach it's probably going to be all of the time.

121

Are you comparing against LLDB_INVALID_ADDRESS to check whether you were able to read x16, or do you not expect to see UINT64_MAX to ever fail to authenticate in this context?

Seems to me like 0xF....F ending up in a register would likely cause an auth failure but I could have the wrong end of the stick here.

124

Do we know that the address in x16 is always a code address?

Though if MacOS isn't using separate ptrauth masks maybe it doesn't matter.

126

What does it mean here that the address failed to resolve?

179

I would add something like:

The current PC which points to the address we tried to branch to.

Which gives some context to the return_pc - 4 earlier.

185

Again what would it mean if this doesn't resolve? (just wondering if there's some handling to be done or ignoring it is fine)

Guessing that it could mean that the branch was to some random address that isn't in any memory currently mapped.

204

I don't know if you only want "correct" code but I've mistakenly clobbered LR in inline assembly before without putting it in the clobber list. Would that count?

vsk updated this revision to Diff 345513.May 14 2021, 11:37 AM

Address code review feedback.

vsk added a comment.May 14 2021, 11:37 AM

Thanks for the review!

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/BLRAA_error/blraa.c
19 ↗(On Diff #345224)

These 'Before' blocks show the reader how lldb interpreted auth-related exceptions prior to this change, and show the expected codegen (handy if the test ever regresses).

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/LDRAA_error/TestPtrauthLDRAADiagnostic.py
5 ↗(On Diff #345224)

Yes, that's right. I don't believe there's anything Darwin-specific hardcoded into these test cases, and hope that they're reusable for AArch64 Linux testing.

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/brkC47x_code/brkC47x.c
10 ↗(On Diff #345224)

In certain cases, AppleClang may insert auth traps in software: Use brk 0xc470 + aut key, where 0x70 == 'p', 0xc4 == 'a' + 'c'.

lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
1055

Will do.

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
92

I went ahead and added the assert.

121

RegisterValue::GetAsUInt64() should return UINT64_MAX if it fails. I'll clean this up by checking whether the earlier ReadRegister call succeeded.

124

For now we assume that the code address fixup is always appropriate for Darwin/arm64e.

126

It's possible that lldb doesn't know about the image the fixed address points to (it could be a garbage value). In this case we conservatively don't hint that there's a ptrauth issue.

179

Will do.

185

Ignoring it (i.e. declining to hint at ptrauth failure) seems fine.

204

We'd like to have lldb be smart enough to diagnose this. It's just that, early on, in our survey of auth issues encountered during bringup, this wasn't a common case.

I think some of my questions are too detailed for this initial patch, I'm sure we can improve the diagnostics over time as situations come up. Glad to see this being upstreamed.

Not very knowledgeable on Mach specifics so I'll leave the final review to others.

lldb/packages/Python/lldbsuite/test/functionalities/ptrauth_diagnostics/BLRAA_error/blraa.c
19 ↗(On Diff #345224)

Cool, but could you reword it? something like:

// Without PAuth diagnostics we got:

Or "expected codegen and lldb output used to be", so readers have context if they're just looking at this test because it failed and they're not working on pauth specifically.

Also you could put the text in comments instead of an ifdef: (/// instead of // so they look different to check lines)

/// * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x2000000100007f9c)
///    frame #0: 0x0000000100007f9c blraa2`foo

I don't think FileCheck will trip up on anything in this.

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
126

So in that case we would report stopped due to a breakpoint, that's a special pac breakpoint but no pointer authentication issue? Isn't that confusing for the user?

Maybe not because it's hinting at accidental corruption vs. deliberate misdirection, you probably have the experiences to inform that.

This is an improvement as is so no need to change it I'm just curious.

Can you add a test for this situation? Assuming you can find an address you know would never be valid.

lldb/test/API/functionalities/ptrauth_diagnostics/BRAA_error/braa.c
20

This one needs a comment like the others:

/// Without PAuth diagnostics ...
vsk updated this revision to Diff 345940.May 17 2021, 10:54 AM

Address review feedback.

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
126

The image containing the fixed address from x16 is usually loaded. If it's not, that's indeed a very confusing situation (& would more likely than not implicate an AppleClang bug). I don't believe the situation is made *more* confusing because lldb declines to print a ptrauth hint. I've added a test for this (it just sets x16 = 0xbad).

DavidSpickett added inline comments.May 18 2021, 1:29 AM
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
126

Thanks, reading the test I see what you mean.

You convert to EXC_BAD_ACCESS even if the x16 address isn't loaded, so I'm not seeing EXC_BREAKPOINT and wondering why I hit this breakpoint that I didn't add. (didn't add manually at least)

vsk added a comment.May 25 2021, 11:12 AM

Friendly ping.

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
126

I see what you mean. In this scenario, EXC_BAD_ACCESS seems a bit more to the point (to me, at least -- since with that particular trap code, there's no way this is a debugger breakpoint).

Apologies, I missed the ping. A couple of minor comments otherwise this looks good to me.

@omjavaid Should take a look too as he's doing/did the PAC work for Arm Linux. I figure this can go in for Mac and be made generic later as needed. (e.g. Arm Linux won't have the special brk bits)

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
259

Don't need the {} here.

375

Also unneeded {} here.

vsk updated this revision to Diff 360180.Jul 20 2021, 9:43 AM

Drop unneeded braces in switch cases.

DavidSpickett accepted this revision.Sep 8 2021, 2:29 AM

Apologies, I forgot about this for way too long. I don't think Omair is going to object anyway so let's get this in.

This revision is now accepted and ready to land.Sep 8 2021, 2:29 AM
This revision was landed with ongoing or failed builds.Sep 14 2021, 2:04 PM
This revision was automatically updated to reflect the committed changes.