Hello Mark, On 06/04/2018 at 11:19 AM Mark Rutland wrote: > On Mon, Jun 04, 2018 at 10:50:07AM +0200, Andreas Hartmann wrote: >> Hello Peter, >> >> thanks for your answer! I appreciate it! >> >> On 06/04/2018 at 10:15 AM Peter Zijlstra wrote: >>> On Fri, Jun 01, 2018 at 02:19:38PM +0200, Andreas Hartmann wrote: >>> >>>> I tested the spectre mitigation of different machines and kernels with >>>> https://github.com/crozone/SpectrePoC >>>> >>>> You can see the results below. >>> >>>> My question: Did I miss something? >>> >>> Yes. >>> >>>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >>>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >>>> Build: ... INTEL_MITIGATION_DISABLED LINUX_KERNEL_MITIGATION_DISABLED >>> >>> ^^^^^^^^ ^^^^^^^^ >>> >>> The POC is a v1 on itself. V1 needs to be fixed for every individual >>> executable (worse, for every individual location in the code, and we're >>> still finding them). The kernel mitigation status for v1 only indicates >>> the kernel itself has mitigations (for some locations). >>> >>> The POC is meant to test effectiveness of these mitigations, either the >>> original LFENCE or the dependent instruction thing, but you have to >>> enable one or the other. >> >> Ok, this means every program running on the machine has to care itself >> to be spectre v1 - safe. > > Correct. Primiarily this matters for things like JITs, where untrusted code > may > be run in the same address space as sensitive data. > >> A malicious program most probably won't care about that. Therefore, my >> next question is: which memory regions can be exploited by a malicious >> program? The complete physical memory or only the memory provided to the >> malicious program? Should be the latter if this approach should have any >> impact. > > Assuming you have a CPU which is not vulnerable to meltdown / variant-3, or > you > have mitigated this, (e.g. with KPTI), a malicious program can only access > data > within its own address space. > > Spectre variant-1 alone only gives access to memory in the address space of > the > program itself.
Thanks Mark! Now I've a better understanding about the effects the different vulnerabilities around Spectre and Meltdown do have and I'm now hopefully able to better estimate them. As I'm mostly using AMD-CPUs (like Ryzen 1 e.g.) for virtualization, I should be secure by default regarding unwanted global memory access from the VM to the host memory, because the Ryzen 1 CPU is not affected by Meltdown at all. Regards, Andreas
