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 1CCAFC77B75 for ; Tue, 23 May 2023 08:08:25 +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=+PyVlwwYfi5RTOuasY2RQ/LefnllnO9XQpudGEDCxgU=; b=SdytCcgOdAiPsx KKEK8WR7bN/41aCbwHGUkmn/ezeC7p8IUWeWgi2DVk+Hfwk/xW5gxZ6qKpsDaBRl4Mew7oD3EW5f2 zWVPJSdHjo6vfk0/UEJjUu6lmttcCsGlN33sWJqSAVcz9opCbq9Yj4CZyyYwFjMYgrvr+8kxiJBi9 x4KUif12btGSWsS2ZajE+/nvmIu5LgC7o4Gs8FjHrWyEy9Lsrpx2LbWbiCho5NeMxFoWYlwm/JPic D9Jn7yQTQs9z1j1T+znUELNSug/OtZyBixL2t1aX2F/RqBq0UM4heW86cfuIsSIPnZprNFlwBFbVH mlq6t7qHLw1m6UDdTVvQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1N3l-009NNE-1w; Tue, 23 May 2023 08:07:57 +0000 Received: from out-22.mta0.migadu.com ([2001:41d0:1004:224b::16]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1N3g-009NJM-1d for linux-arm-kernel@lists.infradead.org; Tue, 23 May 2023 08:07:54 +0000 Date: Tue, 23 May 2023 08:07:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1684829253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=egNMb28a15n4c3sHtWFH9e+9zVJTUhwvGv6/Dco47WE=; b=saPb0XldYatkwDqqep6/PG2P9zPGV8HqRVGhrRMWRInadXayojG4/sWDT3d+U3dQSTyyUq 2vphfGG6B1wtJDsblgTU36ue4Jcse6mh1WSlolG+rLn7ieiPRlFqvq2W0sB+82hVyNjYHD Ml6RrumyXANgSM9DS+rH6XYq89281wE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Will Deacon 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: References: <20230419122051.1341-1-will@kernel.org> <20230419122051.1341-2-will@kernel.org> <20230522112220.GA5965@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230522112220.GA5965@willie-the-truck> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230523_010752_963462_222D70B9 X-CRM114-Status: GOOD ( 32.32 ) 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 On Mon, May 22, 2023 at 12:22:20PM +0100, Will Deacon wrote: > 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. Thanks, and fully understand what led to the policy you folks have implemented. Perhaps in the future we can add an optional, restrictive model to satisfy users that have a more adversarial relationship with firmware interfaces. Not worth addressing in this series, though. Going forwared, can the goals/non-goals of the current pKVM design be captured somewhere in documentation? I think this can be done organically as more bits and pieces are upstreamed, but it'd help reviewers who haven't spent time in the trenches with pKVM to at least grasp the intent. At least personally, I really like to see the pKVM stuff landing upstream but haven't had first-hand experience with the horrors of client devices :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel