mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Andreas Hartmann <andihartmann@freenet.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Spectre mitigation doesn't seem to work at all?!
Date: Mon, 4 Jun 2018 15:12:51 +0100	[thread overview]
Message-ID: <20180604151251.1fb34793@alans-desktop> (raw)
In-Reply-To: <d8fbee2d-305a-9fc0-356e-b8d4cbd59dbd@maya.org>

> 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

  parent reply	other threads:[~2018-06-04 14:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 12:19 Andreas Hartmann
2018-06-04  7:43 ` Andreas Hartmann
2018-06-04 21:25   ` Thomas Gleixner
2018-06-04  8:15 ` Peter Zijlstra
2018-06-04  8:50   ` Andreas Hartmann
2018-06-04  9:15     ` Peter Zijlstra
2018-06-04  9:19     ` Mark Rutland
2018-06-04 10:00       ` Andreas Hartmann
2018-06-04 14:12     ` Alan Cox [this message]
2018-06-05  5:53       ` Andreas Hartmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180604151251.1fb34793@alans-desktop \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=andihartmann@freenet.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®