211–220 of 264 posts
I'm due to refresh my gaming PC, and I was going to go with Intel again as they've not been a problem. However, if Intel chips are going to incur the same 5% - 50% performance hit on Windows, I might end up investing in AMD hardware instead.
Earlier quoted context omitted.
Those tricks cost latency. You can get away with hiding some of that latency in access time to persistent storage. It's much harder to do so with RAM. ECC helps, and can be done at full rate, but isn't a complete solution for all possible problems. And anything you do in hardware at full RAM speed is expensive.
The trick I heard was to literally throttle the writes if you see repeated parallel writes or similar -- as row hammer depends on rapid writes that should be sufficient. But I also have no real idea how hardware actually works :) (magnets? how do they work?)
Earlier quoted context omitted.
The internal caches have ECC but rowhammer targets the DIMMs. ECC DIMMs would solve the issue but Intel, for market segmentation reasons, fuses off the ability to handle ECC memory in consumer chips.
ECC doesn't protect against rowhammer though. It makes it more difficult but not impossible.
Ok so all I hear is Intel and no trace of AMD? So X86_64 ISA wise the only diff between modern CPUs are AVX512. I bet you within the foundations of AVX512 lies a nasty one that can't be patched with microcode update.
I'm confused, what makes you think the AMD and Intel cpu internals are the same?
This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another.
I was talking from an ISA perspective. For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.
Earlier quoted context omitted.
I'd assume that parity is checked on access, which may give enough time to flip more than one bit before it's detected.
ECC memory controller performs memory scrubbing periodically, in the background, during which it checks parity and corrects any bitflips. Otherwise ECC would not work nearly as well as it does.
I'm confused about the TLB impact. The pythonsweetness link claims these patches now require TLB flushes when crossing the kernel/user boundary, but the description of KAISER @ lwn[1] suggests that these flushes are unnecessary with "more recent" processors supporting PCIDs. How recent is "more recent", and is the PCID support likely to be ported back to earlier kernels along with KPTI? TLB flushes for syscalls would…
If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent ker…
As far as I know PCID hidden entries in the TLB result in the same page fault as non-existent entries, so the page fault handling becomes constant timed.
Earlier quoted context omitted.
They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the already well-known side channel attacks, I would not be surprised at all if someone just finished the work and demonstrated that you can actually read priviledged data with a correct…
That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before
>I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture
This is why one should not use verilog and run formal validation of all and everything related to hdl code
Earlier quoted context omitted.
Alternatively, use Firefox (on your mobile) to skip Amp and other sillinesses. Greatly improved my mobile browsing experience, haven't looked back (ublock origin, hint hint).
Firefox is pretty slow on my phone and sometimes when I try to search something, nothing happens. I want to like it, but chrome is just a lot smoother :'( I do love how Google tries to "downgrade" its experience on Firefox mobile, but all it really does is cut out all the javascript and material design bullshit.
Earlier quoted context omitted.
I don't think rowhammer style attacks are possible on TLBs, since they are SRAMs (CAMs, to be precise), not DRAMs.
I took OP to mean "rowhammer style" in the sense of a chip operation having unexpected physical effects on nearby transistors; not an attack literally identical to rowhammer.
Earlier quoted context omitted.
ECC memory controller performs memory scrubbing periodically, in the background, during which it checks parity and corrects any bitflips. Otherwise ECC would not work nearly as well as it does.
Parity isn't checked during every single row refresh?