Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp614605rdb; Tue, 19 Sep 2023 05:37:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGImmnCVRH1PNSzyVp0AE+PWJzSmchu4JfLetQbxUhwMa8Ncvf9ZtCgSCXrRlPUk0gWACFW X-Received: by 2002:a05:6a00:80c2:b0:68f:a92a:8509 with SMTP id ei2-20020a056a0080c200b0068fa92a8509mr3027595pfb.7.1695127077894; Tue, 19 Sep 2023 05:37:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695127077; cv=none; d=google.com; s=arc-20160816; b=icLZGvTzPj489dK3vPqyoV/3iYsg/vju9D+M/nJvSZcy/dde0XkH8SJp7nACu31pPi 4oGPyXupl3k4H7QABSFkHkZ27rOjt1UC+qWTf+8XwjY2ZRlThbOOtCuwSTmTnIYqWslR YRO99KB395VJU3DeHhn/ic88pyl3WXgC7rUuXW9aYzk5koSsEzQLJQK9Yq3tf1dxd3dY qPdB9YhFXlSlDRBt1NPN9a9gDazHNJN6fIst95fznAUwvhpNh/A35rZTEWx5KZb0Pjwa LAuB8a0P3FpV4yV/iRkH7vmh4LNBxMBc39K5+mR2A3GcJr6wtYH9SPjhouAP/TO6OAW3 Be3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=5VORfjBKt407PuE1DSiCwSrwx82eCmS4Ql34Bu25t14=; fh=sHqtZwjkB5b1N4vnD4zPnLJ4Ep3pmwySLmiAtRkXwZ4=; b=dwUP/6Vo3KIS/KPsvzMJksNHDInF5HPGISbZh7mTD8tU7WGC36egc9azQ/5DTobLRA /c38koBR/R1qYi2XroZb6gGnE2RQHptf44aqaL966zuVMvk61uBPNXJ0zhaEk7zkraOH faG00VCazyGC6FVXsY2Gr4PDTAC7Optw9xN9rxidz9Zj/EIHRVyrlS5Cz/8sQsGSNfxH 3xOjed37YIaU+Eafbz3zAZPd4NtfUG+g+gdTK/Li+pCLljhoLCxsrfgvJSdc9Ruxfedc sgGLkpSkayRGPbcoNPqZJzEDkkfz1yf5VvnZm3l74PRZyCN1xNrUlLctpQIKogQmrpyn CH2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EBAM0vgJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id j7-20020a056a00174700b00690cc6f7598si601675pfc.247.2023.09.19.05.37.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 05:37:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EBAM0vgJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 2293E8148B81; Tue, 19 Sep 2023 05:29:34 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232016AbjISM32 (ORCPT + 99 others); Tue, 19 Sep 2023 08:29:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231913AbjISM31 (ORCPT ); Tue, 19 Sep 2023 08:29:27 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C758BF9; Tue, 19 Sep 2023 05:29:21 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71ECCC43395; Tue, 19 Sep 2023 12:29:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695126561; bh=5VORfjBKt407PuE1DSiCwSrwx82eCmS4Ql34Bu25t14=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EBAM0vgJd9vu7RGQiUjMHcwX2JjusZDYcektrrv5NJ65UIHA/gof7kwyb31nUSyIv usI4p1XcZKezcmVHM1WCfhjDPKYKtyzfmvButeheNRz+wauBFnA5tVwnsBD68XgPbj r8QB+/tVUO8qB4/WDhcflw27liI8KeS3D9ytohxL7kBIU6pqq5k3x+3dzlP5/71ilf F5VAGUgHLHimNDoN+6roJBFLswEHhOxMVIU5zjrCQF7qmieFHpnaVBGMzbVcgypWQa G15p5DZI4d29knhUKAzAQ+d8SFAKDusDb/EQ/k63GkzCAK5EG3+bZc22Y6Z2YVHt9p tgWHNFavZHrLQ== Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-501eec0a373so9138812e87.3; Tue, 19 Sep 2023 05:29:21 -0700 (PDT) X-Gm-Message-State: AOJu0Yye1+w9DXFBNc8eFUxjKX36/AmXATc9iFSs/01HFurjK4mZdoij /WoeHqXNLJ4+zlJT/Ku+Xf1Z6p8TM14N1w7e0A== X-Received: by 2002:ac2:4c27:0:b0:500:a6c1:36f7 with SMTP id u7-20020ac24c27000000b00500a6c136f7mr9217639lfq.3.1695126559638; Tue, 19 Sep 2023 05:29:19 -0700 (PDT) MIME-Version: 1.0 References: <20230912121120.380420-1-robh@kernel.org> <20230912121120.380420-2-robh@kernel.org> <20230918100102.GA17472@willie-the-truck> In-Reply-To: From: Rob Herring Date: Tue, 19 Sep 2023 07:29:07 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] arm64: errata: Add Cortex-A520 speculative unprivileged load workaround To: Marc Zyngier Cc: Will Deacon , Catalin Marinas , Jonathan Corbet , James Morse , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 19 Sep 2023 05:29:34 -0700 (PDT) On Mon, Sep 18, 2023 at 5:18=E2=80=AFAM Marc Zyngier = wrote: > > On 2023-09-18 11:01, Will Deacon wrote: > > On Tue, Sep 12, 2023 at 07:11:15AM -0500, Rob Herring wrote: > >> Implement the workaround for ARM Cortex-A520 erratum 2966298. On an > >> affected Cortex-A520 core, a speculatively executed unprivileged load > >> might leak data from a privileged level via a cache side channel. > >> > >> The workaround is to execute a TLBI before returning to EL0. A > >> non-shareable TLBI to any address is sufficient. > > > > Can you elaborate at all on how this works, please? A TLBI addressing a > > cache side channel feels weird (or is "cache" referring to some TLB > > structures rather than e.g. the data cache here?). > > > > Assuming there's some vulnerable window between the speculative > > unprivileged load and the completion of the TLBI, what prevents another > > CPU from observing the side-channel during that time? Also, does the > > TLBI need to be using the same ASID as the unprivileged load? If so, > > then > > a context-switch could widen the vulnerable window quite significantly. > > Another 'interesting' case is the KVM world switch. If EL0 is > affected, what about EL1? Can such a data leak exist cross-EL1, > or from EL2 to El1? Asking for a friend... I'm checking for a definitive answer, but page table isolation also avoids the issue. Wouldn't these scenarios all be similar to page table isolation in that the EL2 or prior EL1 context is unmapped? Rob