**UPDATE: This comment was on the original video. Casey replaced the video by now, so these comments do no longer apply to the current video.**
I believe you were wrong explaining the bit around 25 minutes 25 seconds into the video. The attacker process can never access the same memory as the victim, so therefore can not time it. What I think does sound possible is that the attacker times access to its own memory to figure out if the memory got evicted from the cache, because the victim process accessed _some other_ memory that maps to the same cache set.
Another thing I believe sounds a bit sketchy to me at 46'20": the reason p is not being prefetched when loading b is exactly the opposite of what you said: because the attacker is NOT force evicting it from the cache, such that the do-not-scan-tag is still there, and so it does NOT prefetch p.
How do you evict specific pages and leave others unevicted? I am refering to those holding A in B arrays, how do we ensure that B stays in L2 so it does not get rescanned, but A is evicted? Or am I misunderstanding something
The explanation is phenomenal, thanks. I've already sent it to bunch of people.
I have two conflicting thoughts on DMP:
1. It might seem like this is the reason why some heavier websites (which are usually a pointer soup in JS) seems to run very noticeably better on M series MacBooks. I remember discussing this with coworkers, who all noticed it in Jira and Slack after upgrade.
2. On the other hand, V8 uses pointer compression to pack 64-bit pointers to 32 bits, because JS can't address more than that anyway, and this seems to nullify the DMP optimization. I wonder how does DMP interact with optimizations like this.
Same can be said about any code using indexes (entity ids) instead of pointers, which is pretty common practice. I wonder when do the perf gains you get from allocating your objects yourself outweigh the benefits from DMP and vice versa. It could be that in some cases, it's better to first map your array of indexes to array of pointers, to make sure DMP gets triggered on them, which seems like a pretty counterintuitive thing to do.
What I wonder is why such hardware optimisations are needed. It seems to me that the hardware designers are doing the same as software designers, that is making unnecessarily complicated things which inevitably lead to bugs and hence security vulnerabilities. I might be completely wrong, but this kind of optimisation seems to support code that heavily uses chain of pointers, like in a typical OO style where objects have several references to other, often small, objects. If it wasn't that case, then probably the DMP wouldn't make a significant impact and definitely wouldn't be worth the risk of introducing a security vulnerability, especially if Apple will have to patch it in a way that will cripple the performance hence defeating the purpose of the DMP itself.
I think Casey was right when in a previous video claimed that Apple made the M-series chips to support bad code.
Thank you for putting in the all work to make this understandable. Some people are too frickin smart, god damn! As someone who knows very little about security and only really started thinking about CPUs with this course, it was pretty mind blowing
One thing that I wonder is how security researchers decide to release findings like this? Doesn't describing this exploit in detail make it available to a lot more attackers?
Also really hoping apple doesn't have to release a fix that slows my laptop down...
Sitting here with my morning coffee and watching this before work is making me so happy right now!
It's invaluable that you spend the time to create such high-quality videos.
Thanks Casey!
- Jorge
Superb explanation!
Even though we are doing optimization here, this nitty-gritty details of hardware and exploits are so fascinating.
Thanks, Casey.
**UPDATE: This comment was on the original video. Casey replaced the video by now, so these comments do no longer apply to the current video.**
I believe you were wrong explaining the bit around 25 minutes 25 seconds into the video. The attacker process can never access the same memory as the victim, so therefore can not time it. What I think does sound possible is that the attacker times access to its own memory to figure out if the memory got evicted from the cache, because the victim process accessed _some other_ memory that maps to the same cache set.
Another thing I believe sounds a bit sketchy to me at 46'20": the reason p is not being prefetched when loading b is exactly the opposite of what you said: because the attacker is NOT force evicting it from the cache, such that the do-not-scan-tag is still there, and so it does NOT prefetch p.
How do you evict specific pages and leave others unevicted? I am refering to those holding A in B arrays, how do we ensure that B stays in L2 so it does not get rescanned, but A is evicted? Or am I misunderstanding something
The explanation is phenomenal, thanks. I've already sent it to bunch of people.
I have two conflicting thoughts on DMP:
1. It might seem like this is the reason why some heavier websites (which are usually a pointer soup in JS) seems to run very noticeably better on M series MacBooks. I remember discussing this with coworkers, who all noticed it in Jira and Slack after upgrade.
2. On the other hand, V8 uses pointer compression to pack 64-bit pointers to 32 bits, because JS can't address more than that anyway, and this seems to nullify the DMP optimization. I wonder how does DMP interact with optimizations like this.
Same can be said about any code using indexes (entity ids) instead of pointers, which is pretty common practice. I wonder when do the perf gains you get from allocating your objects yourself outweigh the benefits from DMP and vice versa. It could be that in some cases, it's better to first map your array of indexes to array of pointers, to make sure DMP gets triggered on them, which seems like a pretty counterintuitive thing to do.
That was a great video, thank you.
What I wonder is why such hardware optimisations are needed. It seems to me that the hardware designers are doing the same as software designers, that is making unnecessarily complicated things which inevitably lead to bugs and hence security vulnerabilities. I might be completely wrong, but this kind of optimisation seems to support code that heavily uses chain of pointers, like in a typical OO style where objects have several references to other, often small, objects. If it wasn't that case, then probably the DMP wouldn't make a significant impact and definitely wouldn't be worth the risk of introducing a security vulnerability, especially if Apple will have to patch it in a way that will cripple the performance hence defeating the purpose of the DMP itself.
I think Casey was right when in a previous video claimed that Apple made the M-series chips to support bad code.
Thank you for putting in the all work to make this understandable. Some people are too frickin smart, god damn! As someone who knows very little about security and only really started thinking about CPUs with this course, it was pretty mind blowing
One thing that I wonder is how security researchers decide to release findings like this? Doesn't describing this exploit in detail make it available to a lot more attackers?
Also really hoping apple doesn't have to release a fix that slows my laptop down...