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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 9AB18C2D0E4 for ; Tue, 17 Nov 2020 10:55:32 +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 25CB52464E for ; Tue, 17 Nov 2020 10:55:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Pcjp0su5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 25CB52464E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1k8USkNXCwDSKR7MiZI8zOFFxA8Vq+116NL5saz1pEY=; b=Pcjp0su58tnAQzpYtRKXvlJCS IGXkO4cs0Q9sOInC6ypabGUijQCMHF70/4ykhG07ZRWb8OK5q7dv+SO6IcctCTni+nizdlCjHPFzT CiIK8CFVR39NdAQVOuKAgEJ6nKiygSfaNVvxJZl+OtjfNyIcqRtLMmyAm18gKvjUV37KnFUiUoFs+ JksaddKrjZsiVQbcSy4w4kUh98F0FrUMU815PaJg2Rfa23TIgSV85SH3ECqih1HNlwo+c/vsl/S0e IdHRH/UGXqfQsbpezMzIRhY5K8IF1I6/BCsCkYQrdtnrtVxUwk3r9DvGlOALRlhSyESoYb6tbnkWg rkbuPUL9A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1keyd1-0004lS-Rg; Tue, 17 Nov 2020 10:54:27 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1keycx-0004jP-KR for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 10:54:24 +0000 Received: from trantor (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A26DF2464E; Tue, 17 Nov 2020 10:54:20 +0000 (UTC) Date: Tue, 17 Nov 2020 10:54:18 +0000 From: Catalin Marinas To: Mark Rutland Subject: Re: [PATCHv4 14/17] arm64: uaccess: remove set_fs() Message-ID: References: <20201113124937.20574-1-mark.rutland@arm.com> <20201113124937.20574-15-mark.rutland@arm.com> <20201117104454.GA73209@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201117104454.GA73209@C02TD0UTHF1T.local> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201117_055423_813815_F96EDDDC X-CRM114-Status: GOOD ( 19.85 ) 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: james.morse@arm.com, will@kernel.org, hch@lst.de, linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 17, 2020 at 10:44:54AM +0000, Mark Rutland wrote: > On Mon, Nov 16, 2020 at 05:40:48PM +0000, Catalin Marinas wrote: > > On Fri, Nov 13, 2020 at 12:49:34PM +0000, Mark Rutland wrote: > > > We no longer need to flip UAO to access kernel memory under KERNEL_DS, > > > and head.S unconditionally clears UAO for all kernel configurations via > > > an ERET in init_kernel_el. Thus, we don't need to dynamically flip UAO, > > > nor do we need to context-switch it. However, we do need to clear UAO > > > (and set PAN) during SDEI entry. > > > > If the kernel never sets the UAO bit, why do we need to clear it during > > SDEI entry? > > The fear was taking an SDEI event from a VM which had UAO set, with the > SDEI FW not clearing UAO. > > That might not happen in practice because while the spec implies that > could happen, TF-A currently generates a new PSTATE from scratch, and > going forward the spec will be aligned with regular exception entry > rules for PSTATE (so UAO will be cleared automatically). Does this requirement apply retrospectively or it only for the future SDEI specs? > So we can probably drop the clearing of UAO if you prefer. I don't like clearing UAO specifically. There may be other PSTATE bits in the future we don't know or care about and that are left set by firmware. If we don't trust firmware to give a clean PSTATE, can we reset it with an ERET? -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel