Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp661533pxb; Thu, 25 Feb 2021 11:41:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwXkZLoGbrsrVDCt7ZFNVHAdxwX22S6d3xs9U/XbS/Kl5rKCpAABZtGdv5PIB8fDh4Up28l X-Received: by 2002:a17:906:27c7:: with SMTP id k7mr4345871ejc.13.1614282105466; Thu, 25 Feb 2021 11:41:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614282105; cv=none; d=google.com; s=arc-20160816; b=mEmKSOwOXpugcZxnEGMWhDrkYzNR3zNnDI6pQStevsn7X/eS4O2svsp552o6ZS59yg TAgycabSwRS4cl5+Ta8KToQjJZPkr35+NEvPhZH6WVcZ3TCWv8QdftJTicRLCj/DZM+K lK+jovZPBYDqYs6vAvIbPQvP/gFckZEsu4vfXMcMW6GJ8BhkHFRI0dABOEvhNrzt3roO o2VmpPZEHaQkKuzq0ujMWTgo3qcCfkJEX9x7h+ZrpDjmok96TjaMH5Qjexim/xc0tQ6m nRdvQTOnSBHVzfh+Z5B268YY2paoG/i0tccGvuu8XpaXh1iVV5YWBvFrW/aMxcosZPxE go8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=v4bPKGniClmITPSsdRUUxwP4rpCFNfo0+3YdQpADO14=; b=NoJDACZ9R0WN10Q+PJn4m2pNWkJWQ3Fu4FSCB2XD6Ahw5bHugJWDyZksbIvu4dED2S GUOJHR42tTNFsGK0xD3I+AH2SHQAVBGX/VHbmgPhnAa08GcxPfdVpuxFdlHrOdr1A4Lc ntOQzK3SrWKLSixQVj8T3km/ewPyu3Y9LCCpH6ukg+ZCmF9m2byPQVQUUil/CJDl3KFv eZMjTwThMS1/ekksFLHBjXJ8BJZbbSk9j7nKFcnVmr7/BeOCU8gO69tXtbobnvS8sMNo rWmL3voy7dbgFhrNSyxCPIRrxUDE1ONo3hbe73ukNDjC68RzrY062bGQYcv3+0Y7dWsS kGMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr20si3705226ejc.23.2021.02.25.11.41.22; Thu, 25 Feb 2021 11:41:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234952AbhBYTkZ (ORCPT + 99 others); Thu, 25 Feb 2021 14:40:25 -0500 Received: from foss.arm.com ([217.140.110.172]:48192 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234123AbhBYTgs (ORCPT ); Thu, 25 Feb 2021 14:36:48 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4E70312FC; Thu, 25 Feb 2021 11:36:03 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id D12323F70D; Thu, 25 Feb 2021 11:36:01 -0800 (PST) From: Suzuki K Poulose To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, mathieu.poirier@linaro.org, mike.leach@linaro.org, anshuman.khandual@arm.com, leo.yan@linaro.org, Suzuki K Poulose , Marc Zyngier , Will Deacon , Catalin Marinas , Mark Rutland Subject: [PATCH v4 03/19] kvm: arm64: Hide system instruction access to Trace registers Date: Thu, 25 Feb 2021 19:35:27 +0000 Message-Id: <20210225193543.2920532-4-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20210225193543.2920532-1-suzuki.poulose@arm.com> References: <20210225193543.2920532-1-suzuki.poulose@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest, when the trace register accesses are trapped (CPTR_EL2.TTA == 1). So, the guest will get an undefined instruction, if trusts the ID registers and access one of the trace registers. Lets be nice to the guest and hide the feature to avoid unexpected behavior. Even though this can be done at KVM sysreg emulation layer, we do this by removing the TRACEVER from the sanitised feature register field. This is fine as long as the ETM drivers can handle the individual trace units separately, even when there are differences among the CPUs. Cc: Marc Zyngier Cc: Will Deacon Cc: Catalin Marinas Cc: Mark Rutland Signed-off-by: Suzuki K Poulose --- New patch --- arch/arm64/kernel/cpufeature.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 066030717a4c..a4698f09bf32 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -383,7 +383,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = { * of support. */ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6), ARM64_FTR_END, }; -- 2.24.1