It's always hard to communicate fairly academic side channels in a way that the audience of a press-release (which is typically anyone) can get any level of detail.
We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D
Luckily there's always the paper.
Even still, it relies on the assumption that you know that the user is typing, and that they're typing something that's interesting to you. You could pop a login page and expect the user to sign in, but it's still a very tenuous scenario to measure what you think might be keypresses. The time to redraw a text box is just as easily the focus ring being drawn, or the submit button being hovered, or a minor scroll event.
Even then, the best that I know of for password recovery from timing is "Timing Analysis of Keystrokes and Timing Attacks on SSH", which relies on having data about the user in advance, and they only manage to reduce the search space by about 50x. I'm sure the state of the art is probably a bit better, but that's still assuming a lot: key press timing (that's probably noisy) isn't going to be a meaningful attack vector for arbitrary users online.
that said, I don't expect to see any of these attacks in the wild. they're primarily demonstrations of the technique and to show that the channel is there
as is often the case with side-channel attacks, a serious attacker would much more likely go for un-/recently patched traditional vulnerabilities
short version: only the lower bits of an address are compared at first, because the rest might take a while to resolve
so the cpu can speculate that the rest is gonna match as well and start to work with the data, and then either keep it or throw it away once the rest of the address is known
The problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.
it affects all loads, but for sgx the attacker scenario is that you have compromised the OS, which makes it significantly easier to create the conditions (faults/microcode assists) that cause the LVI than if you were just another userspace program (but it's not impossible there either)
We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D Luckily there's always the paper.
This article also did a pretty good job of a high-level summary imo https://www.securityweek.com/new-attack-shows-risks-of-brows...