On Thu, Jan 25, 2018 at 02:09:40PM -0800, Nadav Amit wrote: > The PoC apparently does not work with 3GB of memory or more on 32-bit. Does > you setup has more? Can you try the attack while setting max_addr=1G ? No, I tested on: Pentium M (Dothan): 1.5 GB RAM, PAE for NX, 2GB/2GB split CONFIG_NOHIGHMEM=y CONFIG_VMSPLIT_2G=y CONFIG_PAGE_OFFSET=0x80000000 CONFIG_X86_PAE=y and Xeon (Pentium 4): 2 GB RAM, no PAE, 1.75GB/2.25GB split CONFIG_NOHIGHMEM=y CONFIG_VMSPLIT_2G_OPT=y CONFIG_PAGE_OFFSET=0x78000000 Now I'm testing with standard settings on Pentium M: 1.5 GB RAM, no PAE, 3GB/1GB split, ~890 MB RAM available CONFIG_NOHIGHMEM=y CONFIG_PAGE_OFFSET=0xc0000000 CONFIG_X86_PAE=n and it still does not work. reliability from https://github.com/IAIK/meltdown reports 0.38% (1/256 = 0.39%, "true" random), and other libkdump tools does not work. https://github.com/paboldin/meltdown-exploit (on linux_proc_banner symbol) reports: cached = 46, uncached = 515, threshold 153 read c0897020 = ff (score=0/1000) read c0897021 = ff (score=0/1000) read c0897022 = ff (score=0/1000) read c0897023 = ff (score=0/1000) read c0897024 = ff (score=0/1000) NOT VULNERABLE and my exploit with: for (i = 0; i < 256; i++) { unsigned char *px = p + (i << 12); t = rdtsc(); readb(px); t = rdtsc() - t; if (t < 100) printf("%02x %lld\n", i, t); } loop returns only "00 45". When I change the exploit code (now based on paboldin code to be sure) to: movzx (%[addr]), %%eax movl $0xaa, %%eax shl $12, %%eax movzx (%[target], %%eax), %%eax I always get "0xaa 51", so the CPU is speculatively executing the second load with (0xaa << 12) in eax, and without the movl instruction, eax seems to be always 0. I even tried to remove the shift: movzx (%[addr]), %%eax movzx (%[target], %%eax), %%eax and I've been reading known value (from /dev/mem, for instance 0x20), I've modified target array offset, and the CPU is still touching "wrong" cacheline, eax == 0 instead of 0x20. I've also tested movl instead of movzx (with and 0xff). On Core 2 Quad in 64-bit mode everything works as expected, vulnerable to Meltdown (I did not test it in 32-bit mode). I don't have any Core "1" to test. On that Pentium M syscall slowdown caused by PTI is huge, 7.5 times slower (7 times compared to patched kernel with disabled PTI), on Skylake with PCID the same trivial benchmark is "only" 3.5 times slower (and 5.2 times slower without PCID). Krzysiek -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
