I use Cookie Clicker as my benchmark. Set it to Christmas and turn on audio. Does the reindeer sound play before the reindeer leaves the screen? On Chrome the deer was gone by the time the jingle quit and almost gone by the time it started. On Firefox, the deer was halfway across the screen. Click a wrinkler. Does it respond to every click? Triple click one. Did it pop? It should, but on Chrome it sometimes takes four-five clicks. Get a cookie storm. Does it even react to you clicking the cookies before they disappear?

I'm on Linux with a 4k monitor so maybe there's something with Chrome in that environment, but Firefox does reasonably well.

Getting to the point where I'm going to have to dig out my old VIA-powered Wal-Mart PC to do my banking and such on to ensure security from hackers dropping javascript into my browser.

At the very least, the slow speed means I'll realize pretty quickly when someone is trying to use it to mine cryptocurrencies.

Better get started on mining your TaxCoin now, returns are due in 4 months!

mov rax, kerneladdr is the instruction that page used as the exception, which is a page fault and a memory access violation that should segfault. What I was missing is that non-root users can actually trap SIGSEGV (which I should have realized, otherwise SIGSEGV would terminate debuggers too), though the stack overflow pages on this definitely demonstrate it's not simple to come up with a trap that isn't "crash into debugger" or "exit".

That's exactly what happens.

cause a page fault, and then

Write a short little helloworld.c that causes a page fault and then prints "Hello World". Let me know what happens to "and then" when you run it as a non-root user.

There's another piece of the puzzle that is still missing/not being talked about. I suspect that this exploit *only* works meaningfully when done in a virtualized guest with a hostile admin/root exploit. My suspicion could work with a root exploit without a VM, but you're already root so why?

Based on this link from Hacker News: https://cyber.wtf/2017/07/28/n... and the linked email/patch from AMD, it looks like what happens is that AMD checks memory permissions up front before allowing an instruction into the pipeline, while Intel made the memory permission check as a later part of the pipeline, apparently after the memory was accessed and inserted into the cache.

You agree to a list of permissions up-front, plus any that future auto-updates add, but in recent versions of android (which not all phones get) you can go to the settings and disable individual permissions after the fact, along with a warning that the app may stop working if you do so.

Wow that's a lot of syllables just to agree with the people in the story refusing to work for the pay given.

CPC factsheets and guidance documents claim

If it were true, they wouldn't need "fact sheets" and "guidance documents" to "claim" this, it would be written in the law.