Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 18 Jan 2018 15:28:20 -0800
From:   Jayachandran C <jnair@caviumnetworks.com>
To:     Jon Masters <jcm@jonmasters.org>
Cc:     Will Deacon <will.deacon@arm.com>, marc.zyngier@arm.com,
        linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com,
        ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
        linux-kernel@vger.kernel.org, labbott@redhat.com,
        christoffer.dall@linaro.org
Subject: Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2
Message-ID: <20180118232816.GA93910@jc-sabre>
References: <20180108164651.GQ25869@arm.com>
 <1515502022-7376-1-git-send-email-jnair@caviumnetworks.com>
 <e9a192da-f603-6523-6d2e-858eb9c7d1b2@jonmasters.org>
 <20180116234554.GA38392@jc-sabre>
 <20180118135354.GB20783@arm.com>
 <20180118175615.GF38392@jc-sabre>
 <cd75aa1e-10ec-2e40-3136-a34d4ec2258f@jonmasters.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cd75aa1e-10ec-2e40-3136-a34d4ec2258f@jonmasters.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Received-SPF: None (protection.outlook.com: cavium.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2018 23:28:29.2699 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e30aa73d-bca2-4889-5ecd-08d55ecb2f0e
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0701MB1064
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jon,

On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote:
> On 01/18/2018 12:56 PM, Jayachandran C wrote:
> > On Thu, Jan 18, 2018 at 01:53:55PM +0000, Will Deacon wrote:
> >> Hi JC,
> >>
> >> On Tue, Jan 16, 2018 at 03:45:54PM -0800, Jayachandran C wrote:
> >>> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote:
> >>>> On 01/09/2018 07:47 AM, Jayachandran C wrote:
> >>>>
> >>>>> Use PSCI based mitigation for speculative execution attacks targeting
> >>>>> the branch predictor. The approach is similar to the one used for
> >>>>> Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> >>>>> test if the firmware supports the capability.
> >>>>>
> >>>>> If the secure firmware has been updated with the mitigation code to
> >>>>> invalidate the branch target buffer, we use the PSCI version call to
> >>>>> invoke it.
> >>>>
> >>>> What's the status of this patch currently? Previously you had suggested
> >>>> to hold while the SMC got standardized, but then you seemed happy with
> >>>> pulling in. What's the latest?
> >>>
> >>> My understanding is that the SMC standardization is being worked on
> >>> but will take more time, and the KPTI current patchset will go to
> >>> mainline before that.
> >>>
> >>> Given that, I would expect arm64 maintainers to pick up this patch for
> >>> ThunderX2, but I have not seen any comments so far.
> >>>
> >>> Will/Marc, please let me know if you are planning to pick this patch
> >>> into the KPTI tree.
> >>
> >> Are you really sure you want us to apply this? If we do, then you can't run
> >> KVM guests anymore because your IMPDEF SMC results in an UNDEF being
> >> injected (crash below).
> >>
> >> I really think that you should just hook up the enable_psci_bp_hardening
> >> callback like we've done for the Cortex CPUs. We can optimise this later
> >> once the SMC standarisation work has been completed (which is nearly final
> >> now and works in a backwards-compatible manner).
> > 
> > I think Marc's patch here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm64/kpti&id=d35e77fae4b70331310c3bc1796bb43b93f9a85e
> > handles returning for undefined smc calls in guest.
> > 
> > I think in this case we have to choose between crashing or giving a false
> > sense of security when a guest compiled with HARDEN_BRANCH_PREDICTOR is
> > booted on an hypervisor that does not support hardening. Crashing maybe
> > a reasonable option.
> 
> Crashing is a completely unreasonable option and is totally
> unacceptable. We never do this in enterprise, period.
> 
> It's reasonable to give an output in dmesg that a system isn't hardened,
> but it's not reasonable to crash. On x86, we added a new qemu machine
> type for those guests that would have IBRS exposed, and ask users to
> switch that on explicitly, but even if they boot the new kernels on
> unpatched infrastructure, we'll detect the lack of the branch predictor
> control interface and just log that.
> 
> The exact same thing should happen on ARM.

With the current patchset from ARM, there is no way of detecting if the
hypervisor is hardened or not, to provide the warning.  The only other
option I have call get version blindly and provide a false sense of
security.

Since both options are bad, I don't have a good solution here. If RedHat
has a preference here on what would be better, I can go with that.

JC.