linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
	suzuki.poulose@arm.com, marc.zyngier@arm.com,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, ykaukab@suse.de,
	shankerd@codeaurora.org
Subject: Re: [PATCH 0/6] add system vulnerability sysfs entries
Date: Thu, 13 Dec 2018 12:07:28 +0000	[thread overview]
Message-ID: <20181213120726.GB3505@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20181206234408.1287689-1-jeremy.linton@arm.com>

On Thu, Dec 06, 2018 at 05:44:02PM -0600, Jeremy Linton wrote:
> Part of this series was originally by Mian Yousaf Kaukab.
> 
> Arm64 machines should be displaying a human readable
> vulnerability status to speculative execution attacks in
> /sys/devices/system/cpu/vulnerabilities 

Is there any agreement on the strings that will be returned in there?

A quick search didn't find anything obvious upstream.  There is
documentation proposed in [1], but I don't know what happened to it and
it doesn't define the mitigation strings at all.  (I didn't follow the
discussion, so there is likely background here I'm not aware of.)

If the mitigation strings are meaningful at all, they really ought to be
documented somewhere since this is ABI.

> This series enables that behavior by providing the expected
> functions. Those functions expose the cpu errata and feature
> states, as well as whether firmware is responding appropriately
> to display the overall machine status. This means that in a
> heterogeneous machine we will only claim the machine is mitigated
> or safe if we are confident all booted cores are safe or
> mitigated. Otherwise, we will display unknown or unsafe
> depending on how much of the machine configuration can
> be assured.

Can the vulnerability status change once we enter userspace?

I see no locking or other concurrency protections, and various global
variables that could be __ro_after_init if nothing will change them
after boot.

If they can change after boot, userspace has no way to be notified,

(I haven't grokked the patches fully, so the answer to this question may
be reasonably straightforward...)


Cheers
---Dave

[1] https://lkml.org/lkml/2018/1/8/145

  parent reply	other threads:[~2018-12-13 12:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 23:44 [PATCH 0/6] add system vulnerability sysfs entries Jeremy Linton
2018-12-06 23:44 ` [PATCH 1/6] arm64: kpti: move check for non-vulnerable CPUs to a function Jeremy Linton
2018-12-13  9:13   ` Julien Thierry
2018-12-12 14:36     ` Jeremy Linton
2018-12-06 23:44 ` [PATCH 2/6] arm64: add sysfs vulnerability show for meltdown Jeremy Linton
2018-12-13  9:23   ` Julien Thierry
2018-12-13 10:46     ` Julien Thierry
2018-12-12 14:49       ` Jeremy Linton
2018-12-14  8:55         ` Julien Thierry
2018-12-06 23:44 ` [PATCH 3/6] arm64: add sysfs vulnerability show for spectre v1 Jeremy Linton
2018-12-06 23:44 ` [PATCH 4/6] arm64: add sysfs vulnerability show for spectre v2 Jeremy Linton
2018-12-13 11:09   ` Julien Thierry
2019-01-02 22:19     ` Jeremy Linton
2018-12-06 23:44 ` [PATCH 5/6] arm64: add sysfs vulnerability show for speculative store bypass Jeremy Linton
2018-12-14 10:34   ` Steven Price
2018-12-14 10:36     ` Will Deacon
2018-12-14 10:41       ` Steven Price
2018-12-14 11:28         ` Dave Martin
2018-12-14 11:33           ` Will Deacon
2018-12-06 23:44 ` [PATCH 6/6] arm64: enable generic CPU vulnerabilites support Jeremy Linton
2018-12-13 12:07 ` Dave Martin [this message]
2018-12-12 15:48   ` [PATCH 0/6] add system vulnerability sysfs entries Jeremy Linton
2018-12-13 19:26     ` Dave Martin

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=20181213120726.GB3505@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    --cc=ykaukab@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).