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.
