From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65BDBC433DF for ; Thu, 13 Aug 2020 09:20:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 42B872078B for ; Thu, 13 Aug 2020 09:20:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="rL5RVbFK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726048AbgHMJUA (ORCPT ); Thu, 13 Aug 2020 05:20:00 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:45007 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726053AbgHMJT7 (ORCPT ); Thu, 13 Aug 2020 05:19:59 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1597310399; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=rqTuz315PIl0OvWEUQPSIGL8Yokr6Ob5ozpoNbkalTU=; b=rL5RVbFK5Rea+CS5JPIpfnfobNiIg0Yne0zYiekKQSv4b7/Yen8By4kHWhxbxg43O3JOKUR1 3oRaM0SPeZz1eGnKKOniV5+2o5vZpUH0AtWMmUUWjLoLWfHKwm3jt+OolDMgI8ROFUFboAMi LjyLDb8Fiz+pqjPp9Eabz/urXRk= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI1MzIzYiIsICJsaW51eC1hcm0tbXNtQHZnZXIua2VybmVsLm9yZyIsICJiZTllNGEiXQ== Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n10.prod.us-west-2.postgun.com with SMTP id 5f3505aa46ed996674c77ea9 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 13 Aug 2020 09:19:38 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 1E961C433CA; Thu, 13 Aug 2020 09:19:38 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9B43BC433C9; Thu, 13 Aug 2020 09:19:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Aug 2020 14:49:37 +0530 From: Sai Prakash Ranjan To: Will Deacon Cc: Catalin Marinas , Marc Zyngier , Andre Przywara , Mark Rutland , Suzuki K Poulose , Stephen Boyd , Douglas Anderson , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH] arm64: Add KRYO4XX gold CPU core to spectre-v2 safe list In-Reply-To: <20200813090324.GB9829@willie-the-truck> References: <20200813081834.13576-1-saiprakash.ranjan@codeaurora.org> <20200813090324.GB9829@willie-the-truck> Message-ID: <89f0f41514e547533c3fa66364e5a2ac@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 2020-08-13 14:33, Will Deacon wrote: > On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote: >> KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2 >> bits set and are spectre-v2 safe. But on big.LITTLE systems where >> they are coupled with other CPU cores such as the KRYO4XX silver >> based on Cortex-A55 which are spectre-v2 safe but do not have CSV2 >> bits set, the system wide safe value will be set to the lowest value >> of CSV2 bits as per FTR_LOWER_SAFE defined for CSV2 bits of register >> ID_AA64PFR0_EL1. >> >> This is a problem when booting a guest kernel on gold CPU cores >> where it will incorrectly report ARM_SMCCC_ARCH_WORKAROUND_1 warning >> and consider them as vulnerable for Spectre variant 2 due to system >> wide safe value which is used in kvm emulation code when reading id >> registers. One wrong way of fixing this is to set the FTR_HIGHER_SAFE >> for CSV2 bits, so instead add the KRYO4XX gold CPU core to the safe >> list which will be consulted even when the sanitised read reports >> that CSV2 bits are not set for KRYO4XX gold cores. >> >> Reported-by: Stephen Boyd >> Signed-off-by: Sai Prakash Ranjan >> --- >> arch/arm64/kernel/cpu_errata.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/kernel/cpu_errata.c >> b/arch/arm64/kernel/cpu_errata.c >> index 6bd1d3ad037a..6cbdd2d98a2a 100644 >> --- a/arch/arm64/kernel/cpu_errata.c >> +++ b/arch/arm64/kernel/cpu_errata.c >> @@ -545,6 +545,7 @@ static const struct midr_range >> spectre_v2_safe_list[] = { >> MIDR_ALL_VERSIONS(MIDR_HISI_TSV110), >> MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER), >> MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER), >> + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD), > > We shouldn't be putting CPUs in the safe list when they have CSV2 > reporting > that they are mitigated in hardware, so I don't think this is the right > approach. > Ok but the only thing I find wrong in this approach is that it is a redundant information because CSV2 is already advertising the mitigation, but again CSV2 check is done first so it doesn't really hurt to add it to the safe list because we already know that it is safe. > Sounds more like KVM should advertise CSV2 for the vCPUs if all of the > physical CPUs without CSV2 set are on the safe list. But then again, > KVM > has always been slightly in denial about big.LITTLE because you can't > sensibly expose it to a guest if there are detectable differences... > Sorry but I don't see how the guest kernel will see the CSV2 bits set for gold CPU cores without actually adding them to the safe list or reading the not sanitised value of ID_AA64PFR0_EL1 ? Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E004C433DF for ; Thu, 13 Aug 2020 09:21:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 52FEA20781 for ; Thu, 13 Aug 2020 09:21:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IEueFvK9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="kd9p2hcP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52FEA20781 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DjV/U8l8UNl2ins8PJQQ8A3L77o5P6+DRM6fn7EsDdk=; b=IEueFvK9LozrSNOJR8F0v/FVU u7FCyXSC8k5zSlxm/qqd/FRiUKSyhjD/pgRHqdBTOGDKy0je5g97TorhYMcxZD2chyWORehPevQ78 Wat1xyzM+A62FtSyxsfi40PLElGkAiJ2LkwG7e4rT5s3ZoF+2fDKL+bkfIcW0Yi0G50BPbgbsBhR3 AzYvcmy/c2dLwl07RT3KVmR1H0enpfWkJKxCDxBnMsoBn1Hv1x0PFq/27rRMGYsjdnQMEevVT9KP3 C2kSRRGK5Q58BSiqmvIiBXJ+q+2hugKjYn/z0qKAi3Z67gp54dGD0gE4U7cEBiD/Iv0cZMyjWQpHS B21e89nNg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k69Om-0001nX-Hv; Thu, 13 Aug 2020 09:19:48 +0000 Received: from mail29.static.mailgun.info ([104.130.122.29]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k69Oi-0001mY-On for linux-arm-kernel@lists.infradead.org; Thu, 13 Aug 2020 09:19:47 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1597310386; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=rqTuz315PIl0OvWEUQPSIGL8Yokr6Ob5ozpoNbkalTU=; b=kd9p2hcPXwB1hPnLXpF0QoXEKeVAPeO+Tob1fUBtaLkzaq8PkKUXDFFEkjfpi5KFHkJxRAES i338eXP19JlpKmi0HxJ5kcPwsCA3E3TC/Nw0r03SKhOLj8Ff0Xs4t9/VcwgOg4XH0lusLwkx TY7sz+C1j6oEmVx/2OZu4sI4qLk= X-Mailgun-Sending-Ip: 104.130.122.29 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n09.prod.us-west-2.postgun.com with SMTP id 5f3505aa4c787f237baea6e1 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 13 Aug 2020 09:19:38 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 5F1FAC433CB; Thu, 13 Aug 2020 09:19:38 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9B43BC433C9; Thu, 13 Aug 2020 09:19:37 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 13 Aug 2020 14:49:37 +0530 From: Sai Prakash Ranjan To: Will Deacon Subject: Re: [PATCH] arm64: Add KRYO4XX gold CPU core to spectre-v2 safe list In-Reply-To: <20200813090324.GB9829@willie-the-truck> References: <20200813081834.13576-1-saiprakash.ranjan@codeaurora.org> <20200813090324.GB9829@willie-the-truck> Message-ID: <89f0f41514e547533c3fa66364e5a2ac@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200813_051946_260775_4A68A25C X-CRM114-Status: GOOD ( 29.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Marc Zyngier , Suzuki K Poulose , Catalin Marinas , linux-arm-msm@vger.kernel.org, Douglas Anderson , Stephen Boyd , linux-arm-kernel@lists.infradead.org, Andre Przywara , linux-kernel@vger.kernel.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-08-13 14:33, Will Deacon wrote: > On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote: >> KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2 >> bits set and are spectre-v2 safe. But on big.LITTLE systems where >> they are coupled with other CPU cores such as the KRYO4XX silver >> based on Cortex-A55 which are spectre-v2 safe but do not have CSV2 >> bits set, the system wide safe value will be set to the lowest value >> of CSV2 bits as per FTR_LOWER_SAFE defined for CSV2 bits of register >> ID_AA64PFR0_EL1. >> >> This is a problem when booting a guest kernel on gold CPU cores >> where it will incorrectly report ARM_SMCCC_ARCH_WORKAROUND_1 warning >> and consider them as vulnerable for Spectre variant 2 due to system >> wide safe value which is used in kvm emulation code when reading id >> registers. One wrong way of fixing this is to set the FTR_HIGHER_SAFE >> for CSV2 bits, so instead add the KRYO4XX gold CPU core to the safe >> list which will be consulted even when the sanitised read reports >> that CSV2 bits are not set for KRYO4XX gold cores. >> >> Reported-by: Stephen Boyd >> Signed-off-by: Sai Prakash Ranjan >> --- >> arch/arm64/kernel/cpu_errata.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/kernel/cpu_errata.c >> b/arch/arm64/kernel/cpu_errata.c >> index 6bd1d3ad037a..6cbdd2d98a2a 100644 >> --- a/arch/arm64/kernel/cpu_errata.c >> +++ b/arch/arm64/kernel/cpu_errata.c >> @@ -545,6 +545,7 @@ static const struct midr_range >> spectre_v2_safe_list[] = { >> MIDR_ALL_VERSIONS(MIDR_HISI_TSV110), >> MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER), >> MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER), >> + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD), > > We shouldn't be putting CPUs in the safe list when they have CSV2 > reporting > that they are mitigated in hardware, so I don't think this is the right > approach. > Ok but the only thing I find wrong in this approach is that it is a redundant information because CSV2 is already advertising the mitigation, but again CSV2 check is done first so it doesn't really hurt to add it to the safe list because we already know that it is safe. > Sounds more like KVM should advertise CSV2 for the vCPUs if all of the > physical CPUs without CSV2 set are on the safe list. But then again, > KVM > has always been slightly in denial about big.LITTLE because you can't > sensibly expose it to a guest if there are detectable differences... > Sorry but I don't see how the guest kernel will see the CSV2 bits set for gold CPU cores without actually adding them to the safe list or reading the not sanitised value of ID_AA64PFR0_EL1 ? Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel