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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7F77C77B75 for ; Mon, 22 May 2023 11:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=sDnRtb3+nL15URYneIjzro7hr2hjwzGIsFnqK/Kh+xo=; b=VTxLvfsJULXwoG Mg4+TNsp/lrKLJqhQNBtnS1ZmN3Mbn1w4QGRaE/3/7zVAwhTIX0yY2dCOFtgxuZ8FToQPAG7JalF2 WBLA/jCHDHTw96G17G/iuVgsIQrCViCV4qX3k8tkhITNrwTBZ7fmlip34Rsy/G7PNCcd8ztCJud9O SoXoSKtPDS8FkRBMWYEWyCB9/Mn9M8a/tEyZBuQaP0W6EIlJ7ftBvEIbXrV02Elp7BMBfn7A9JSIc 7189pPSsoaQtksYaJOTZ1BIO1YETQRlCnWrKCTfuHfJpPlQLEECuUYw4r2ehFMdbdnce8RttwlHgL oO9tG5t67eirh/zL4H0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q13cV-006FCm-27; Mon, 22 May 2023 11:22:31 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q13cS-006FBd-1h for linux-arm-kernel@lists.infradead.org; Mon, 22 May 2023 11:22:29 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B75CA614C8; Mon, 22 May 2023 11:22:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCA60C433EF; Mon, 22 May 2023 11:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684754547; bh=YkBpB7jMH6+3MZC+ka33JFuH7waAcgd/5sK3Imgnm4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qMNJpHBkEdX+jEneMe7IcGcqGXSOhBzGN5DMYRwHacFUZkhylfSmjEcA0BeNsuon+ ITLO/Agq7vxgm4ywBFIsrPnlfQQqmjyYM/urIpAKaCUkBWDHUc9JQMjuYuPYnOdoAL hZWcytMBgIGLHtxf1eJf1J7Ym7lT9k/1RoxglvAsl8Wtz1k/XgpLe9BuO3e4sFlYOi 5A0fPnb4p1GcuyYL5MvII9IKkOoSySrb/yXvnZF0dZEH65rV8x6tN80jTQJmVuPnlt nD5WN3q+827zHAn92mJ+c7nRL3/bgQeND62PtFXQfzYvvypc8a7qzaNp65klnTMWYr bYF2L04dpwHuw== Date: Mon, 22 May 2023 12:22:20 +0100 From: Will Deacon To: Oliver Upton Cc: linux-arm-kernel@lists.infradead.org, Quentin Perret , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Sudeep Holla , Sebastian Ene , Fuad Tabba , kvmarm@lists.linux.dev, kernel-team@android.com, Andrew Walbran Subject: Re: [PATCH v2 01/10] KVM: arm64: Block unsafe FF-A calls from the host Message-ID: <20230522112220.GA5965@willie-the-truck> References: <20230419122051.1341-1-will@kernel.org> <20230419122051.1341-2-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230522_042228_642799_1DB0A23C X-CRM114-Status: GOOD ( 25.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hi Oliver, On Wed, May 10, 2023 at 07:08:01PM +0000, Oliver Upton wrote: > On Wed, Apr 19, 2023 at 01:20:42PM +0100, Will Deacon wrote: > > +/* > > + * Is a given FFA function supported, either by forwarding on directly > > + * or by handling at EL2? > > + */ > > +static bool ffa_call_supported(u64 func_id) > > +{ > > + switch (func_id) { > > + /* Unsupported memory management calls */ > > + case FFA_FN64_MEM_RETRIEVE_REQ: > > + case FFA_MEM_RETRIEVE_RESP: > > + case FFA_MEM_RELINQUISH: > > + case FFA_MEM_OP_PAUSE: > > + case FFA_MEM_OP_RESUME: > > + case FFA_MEM_FRAG_RX: > > + case FFA_FN64_MEM_DONATE: > > + /* Indirect message passing via RX/TX buffers */ > > + case FFA_MSG_SEND: > > + case FFA_MSG_POLL: > > + case FFA_MSG_WAIT: > > + /* 32-bit variants of 64-bit calls */ > > + case FFA_MSG_SEND_DIRECT_REQ: > > + case FFA_MSG_SEND_DIRECT_RESP: > > + case FFA_RXTX_MAP: > > + case FFA_MEM_DONATE: > > + case FFA_MEM_RETRIEVE_REQ: > > + /* Don't advertise any features just yet */ > > + case FFA_FEATURES: > > + return false; > > + } > > + > > + return true; > > +} > > Apologies for rehashing something we dicussed in v1... > > Enforcing the pKVM policy as a denylist rather than an allowlist > deserves a bit more elaboration, at least in the form of a comment. I > understand that we must trust EL3 by construction, but it is fuzzy why > it gets extended to what EL1 might do with FF-A calls that are unknown > to pKVM. Sure thing, I'll add a comment for the next version. > Broadening the scope for a moment, is my understanding correct that > limiting 'unknown' SMCs from host EL1 are an explicit non-goal of pKVM's > security model? Assuming a well-intentioned EL3, I'm just a bit worried > about any vendor-specific junkware that could be used by a malicious > EL1. It's a valid concern, but the sad reality is that every shipping Android device makes use of 'unknown' SMCs and if we reject them at EL2 then the device won't function properly and we've shot ourselves in the foot. So we basically have two options: (1) Add per-device logic to EL2 which knows how to introspect the 'unknown' SMCs and filter out bad requests from EL1 (2) Let them through by default, intercepting standard requests such as PSCI and FF-A at EL2 and rely on the firmware not to expose non-standard memory sharing calls We have patches in Android to support modules loading code into EL2, which makes option (1) practical, but without that support upstream, (2) is the best we can do for now. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel