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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 2B18AC48BE8 for ; Tue, 15 Jun 2021 14:26:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0CFF761581 for ; Tue, 15 Jun 2021 14:26:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231639AbhFOO2H (ORCPT ); Tue, 15 Jun 2021 10:28:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:44078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231495AbhFOO1r (ORCPT ); Tue, 15 Jun 2021 10:27:47 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id A5FA761483; Tue, 15 Jun 2021 14:25:41 +0000 (UTC) Date: Tue, 15 Jun 2021 15:25:39 +0100 From: Catalin Marinas To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Mark Rutland , James Morse , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm: Fix ttbr0 values stored in struct thread_info for software-pan Message-ID: <20210615142539.GJ26027@arm.com> References: <1623749578-11231-1-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1623749578-11231-1-git-send-email-anshuman.khandual@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 15, 2021 at 03:02:58PM +0530, Anshuman Khandual wrote: > When using CONFIG_ARM64_SW_TTBR0_PAN, a task's thread_info::ttbr0 must be > the TTBR0_EL1 value used to run userspace. With 52-bit PAs, the PA must be > packed into the TTBR using phys_to_ttbr(), but we forget to do this in some > of the SW PAN code. Thus, if the value is installed into TTBR0_EL1 (as may > happen in the uaccess routines), this could result in UNPREDICTABLE > behaviour. > > Since hardware with 52-bit PA support almost certainly has HW PAN, which > will be used in preference, this shouldn't be a practical issue, but let's > fix this for consistency. I'm ok with fixing this for consistency. We should never hit those paths unless someone built hardware with 52-bit PA (8.2) but without PAN (8.1) and it would not be architecture compliant. I'll leave it with Will for 5.14, it's no a fix that needs urgent queuing. Reviewed-by: Catalin Marinas