| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180604151251.1fb34793@alans-desktop>
Date: Mon, 4 Jun 2018 15:12:51 +0100
From: Alan Cox <gnomes@...rguk.ukuu.org.uk>
To: Andreas Hartmann <andihartmann@...enet.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Spectre mitigation doesn't seem to work at all?!
> 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.
Spectre is not about memory regions. It's about speculative execution
leaving measurable footprints. What footprints you leave depend upon what
code you are executing. Thus the question becomes 'what can the target
access'.
In order to attack something you need both a way to influence the code
concerned and a way to measure it. In addition it needs to have some
secret you want.
In practice that usually means something on the same system with its own
memory space/privilege level. The usual cases then are user<->kernel and
managed application<->runtime.
Thus it's very different to meltdown style attacks.
If you are actually worried about this you should probably also read up
on more general cache prime/probe attacks and cache profiling (things
like the ARMageddon paper are worth reading - and while it was done on
ARM much of it is generic to most modern processors), as well as timing
attacks.
Alan
Powered by blists - more mailing lists