Hacker News Reader

Comment by ljhsiung | Hacker News Reader

Hi Joseph! Go Illini! I didn't see you my last semester but I'm glad to see Chris's members doing well in the world. Also always love Mengjia's work.

2 questions.

1) it's relatively known that PAC is brute-forcable given its relatively small key space (16 bits, sometimes 8 if TBI is enabled). How does your attack differ from general brute forces? (My impression is just your leveraging of the BTB/iTLB is a bit more stealthy.) Similarly, in your opinion, would a fix be more ISA-level or you think it's more specific to the M1 (given brute forcing in general is a PtrAuth problem)?

2) you mention in section 8 that this took 3 minutes for a 16b key and tons of syscalls. Wouldn't another proper mitigation be to limit the number of signatures per key? 3 minutes is definitely a long time, and some form of temporal separation may be quite helpful.

View on HN

ILL-INI!!!

1) Our attack does apply a brute force technique with the twist that crashes are suppressed via speculative execution. If you tried to brute force a PAC against the kernel, you'd instantly panic your device and have to reboot.

2) Given that we never sign anything (only try to verify a signed pointer), and that every authentication attempt happens under speculation, I'm not sure how you would rate limit this without absolutely destroying performance. Keep in mind the kernel is doing a whole lot more with PAC than just our attack (for example, every function's return address is also signed with PAC) so distinguishing valid uses from a PACMAN attack might be challenging.

I suppose you could track how many speculative PAC exceptions you got, but it's a little late to add that now isn't it? And it could also raise lots of false positives due to type confusion style mechanisms on valid mispredicted paths.

Thanks for the quick answers.

Third Q-- What's your opinion on BTI as a possible mitigation? Given it's an v8.5 feature meant for JOPs, and this attack is essentially a speculative JOP, maybe we could use BTI to mitigate and heavily reduce the number of gadgets, speculative or not.

Would it be possible instead to mitigate this by removing the side-channel: either don't leave any trace in the TLB of the speculative execution, or deny access to the TLB for user mode software?

Unwinding changes to the TLB on every mispredict would have a significant overhead and hurt overall performance. Removing valid data you just cached (speculatively or otherwise) is generally a bad idea.

User mode software requires a TLB (unless you want to do a page walk for every single instruction!)

Even if you could remove the TLB entirely from the CPU somehow, the attacker could just use the cache or some other microarchitectural structure.

Well that's disappointing. Thanks for the explanation!

I never have to worry about such low level details in my day-to-day work, so this is all new to me.

Reply on news.ycombinator.com