linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>,
	linux-arm-kernel@lists.infradead.org, stefan.wahren@i2se.com,
	mlangsdo@redhat.com, suzuki.poulose@arm.com,
	marc.zyngier@arm.com, julien.thierry@arm.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	steven.price@arm.com, Christoffer Dall <christoffer.dall@arm.com>,
	kvmarm@lists.cs.columbia.edu, ykaukab@suse.de,
	dave.martin@arm.com, shankerd@codeaurora.org
Subject: Re: [PATCH v4 03/12] arm64: Remove the ability to build a kernel without ssbd
Date: Fri, 15 Feb 2019 18:20:38 +0000	[thread overview]
Message-ID: <20190215182037.GI100037@arrakis.emea.arm.com> (raw)
In-Reply-To: <20190130180415.0cab24e0@donnerap.cambridge.arm.com>

On Wed, Jan 30, 2019 at 06:04:15PM +0000, Andre Przywara wrote:
> On Fri, 25 Jan 2019 12:07:02 -0600
> Jeremy Linton <jeremy.linton@arm.com> wrote:
> > Buried behind EXPERT is the ability to build a kernel without
> > SSBD, this needlessly clutters up the code as well as creates
> > the opportunity for bugs. It also removes the kernel's ability
> > to determine if the machine its running on is vulnerable.
> 
> I don't know the original motivation for this config option, typically
> they are not around for no reason.
> I see the benefit of dropping those config options, but we want to make
> sure that people don't start hacking around to remove them again.
> 
> > Since its also possible to disable it at boot time, lets remove
> > the config option.
> 
> Given the level of optimisation a compiler can do with the state being
> known at compile time, I would imagine that it's not the same (though
> probably very close).
> 
> But that's not my call, it would be good to hear some maintainer's
> opinion on this.

Having spoken to Will, we'd rather keep the config options if possible.
Even if they are behind EXPERT and default y, they come in handy when
debugging.

Can we still have the sysfs information regardless of whether the config
is enabled or not? IOW, move the #ifdefs around to always have the
detection while being able to disable the actual workarounds via config?

Are the code paths between config and cmdline disabling identical? At a
quick look I got the impression they are not exactly the same.

-- 
Catalin

  reply	other threads:[~2019-02-15 18:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 18:06 [PATCH v4 00/12] arm64: add system vulnerability sysfs entries Jeremy Linton
2019-01-25 18:07 ` [PATCH v4 01/12] Documentation: Document arm64 kpti control Jeremy Linton
2019-01-30 18:02   ` Andre Przywara
2019-02-06 19:24     ` Jeremy Linton
2019-02-06 21:06       ` André Przywara
2019-01-31 17:58   ` Andre Przywara
2019-02-07  0:25   ` Jonathan Corbet
2019-01-25 18:07 ` [PATCH v4 02/12] arm64: Provide a command line to disable spectre_v2 mitigation Jeremy Linton
2019-01-30 18:03   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 03/12] arm64: Remove the ability to build a kernel without ssbd Jeremy Linton
2019-01-30 18:04   ` Andre Przywara
2019-02-15 18:20     ` Catalin Marinas [this message]
2019-02-15 18:54       ` Jeremy Linton
2019-01-25 18:07 ` [PATCH v4 04/12] arm64: remove the ability to build a kernel without hardened branch predictors Jeremy Linton
2019-01-30 18:04   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 05/12] arm64: remove the ability to build a kernel without kpti Jeremy Linton
2019-01-30 18:05   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 06/12] arm64: add sysfs vulnerability show for spectre v1 Jeremy Linton
2019-01-31 17:52   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 07/12] arm64: add sysfs vulnerability show for meltdown Jeremy Linton
2019-01-31  9:28   ` Julien Thierry
2019-01-31 21:48     ` Jeremy Linton
2019-01-31 17:54   ` Andre Przywara
2019-01-31 21:53     ` Jeremy Linton
2019-01-25 18:07 ` [PATCH v4 08/12] arm64: Advertise mitigation of Spectre-v2, or lack thereof Jeremy Linton
2019-01-31 17:54   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 09/12] arm64: Use firmware to detect CPUs that are not affected by Spectre-v2 Jeremy Linton
2019-01-31 17:55   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 10/12] arm64: add sysfs vulnerability show for spectre v2 Jeremy Linton
2019-01-31 17:55   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 11/12] arm64: add sysfs vulnerability show for speculative store bypass Jeremy Linton
2019-01-31 17:55   ` Andre Przywara
2019-01-25 18:07 ` [PATCH v4 12/12] arm64: enable generic CPU vulnerabilites support Jeremy Linton
2019-01-31 17:56   ` Andre Przywara
2019-02-08 20:05 ` [PATCH v4 00/12] arm64: add system vulnerability sysfs entries Stefan Wahren

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=20190215182037.GI100037@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=dave.martin@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=julien.thierry@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mlangsdo@redhat.com \
    --cc=shankerd@codeaurora.org \
    --cc=stefan.wahren@i2se.com \
    --cc=steven.price@arm.com \
    --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).