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 12FDEF99344 for ; Thu, 23 Apr 2026 08:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RjGZE78tox+GBfp/rqdK8TMUYnKuTzcYH6aVfvG6asc=; b=R2l8F0G9lQRv/ZfRDgB2l3r/T3 0GhOcbbUURNwkZuyDh8mbMHg19URkmQWEg9ESpFu/2Aa7VYe7xtLfCPaUWB47BNHIJ4eOK1rVDuRo SIMGz1fqad+KWarQ2znIBUqghwW64x2vw/jJcBJB1zfjU39Py4VCQzO0wOerD7XOaETMQCQe26fun 5Guu/7V19UuAO8nQ3eiTURMBtGPkalkcAqI9T/Tudx44aNl91znbmH21vE6SGH5XGc5ael+daCV0j o/YUKaAmN1fA8uILJEvcLd1lQuX43sAHlMde3PcFyu4KjfVneMA/cUlLeCDjP9YMC7NfpkbbmtuxC z58c4e9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wFp7D-0000000BCi0-0WuL; Thu, 23 Apr 2026 08:08:51 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wFp7B-0000000BChr-3HZF for linux-arm-kernel@lists.infradead.org; Thu, 23 Apr 2026 08:08:49 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 2EB7360052; Thu, 23 Apr 2026 08:08:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D71E8C2BCB2; Thu, 23 Apr 2026 08:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776931728; bh=Yy/Tfq/9F8NbivnASS2KOxeiLK7q4WMxkOdk5fR99pI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=N3BSPJ+JUmCeDLYPRnJec2nJwSVaWKdxbDy6Idc8Ll/rx3aRuNiMv+R3GNQrGVRGF DsGv58QdWyGZ9vrOgEnNtyiImWPrHeDEj95Gc1kwcgvy6escuhqf/odwTog1CGS0+O 4ro8EWWAFM42JhZiDfrimtjt6ueB3o6Hyi97dF9IjFSMlaSRdKKGs3TZMnnV4l3T/k A+MjrtP9zJRcBnw4b1fSrwM410KZfdVcfN3nE+0H9skBDJXXK3tBfe69y6+jJm/sPl 0Gugrt/fpholSb+Wj5+kgml2oLFt7aGAKMr3x0ClZEI3wIMoUClHAgqMsJU40skP01 Ug6cY5u7D193A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wFp78-0000000DyA0-2GNW; Thu, 23 Apr 2026 08:08:46 +0000 Date: Thu, 23 Apr 2026 09:08:46 +0100 Message-ID: <867bpy14kx.wl-maz@kernel.org> From: Marc Zyngier To: Sebastian Ene Cc: oupton@kernel.org, will@kernel.org, ayrton@google.com, catalin.marinas@arm.com, joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, mrigendra.chaubey@gmail.com, perlarsen@google.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, stable@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement In-Reply-To: References: <20260422102540.1433704-1-sebastianene@google.com> <86bjfb18v1.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sebastianene@google.com, oupton@kernel.org, will@kernel.org, ayrton@google.com, catalin.marinas@arm.com, joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, mrigendra.chaubey@gmail.com, perlarsen@google.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 22 Apr 2026 14:35:55 +0100, Sebastian Ene wrote: > > On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote: > > On Wed, 22 Apr 2026 11:25:40 +0100, > > Sebastian Ene wrote: > > > > > > Prevent the pKVM hypervisor from making assumptions that the > > > endpoint memory access descriptor (EMAD) comes right after the > > > FF-A memory region header and enforce a strict placement for it > > > when validating an FF-A memory lend/share transaction. > > Hello Marc, > > > > > As I read this, you want to remove a bad assumption... > > > > > > > > Prior to FF-A version 1.1 the header of the memory region > > > didn't contain an offset to the endpoint memory access descriptor. > > > The layout of a memory transaction looks like this: > > > > > > Field name | Offset > > > -- 0 > > > [ Header (ffa_mem_region) |__ ep_mem_offset > > > EMAD 1 (ffa_mem_region_attributes) | > > > ] > > > > > > Reject the host from specifying a memory access descriptor offset > > > that is different than the size of the memory region header. > > > > And yet you decide that you want to enforce this assumption. I don't > > understand how you arrive to this conclusion. > > > > Looking at the spec, it appears that the offset is *designed* to allow > > a gap between the header and the EMAD. Refusing to handle a it seems to be a > > violation of the spec. > > > > What am I missing? > > While the spec allows the gap to be variable (since version 1.1), the > arm ff-a driver places it at a fixed position in: > ffa_mem_region_additional_setup() > https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671 That's an implementation detail, and you shouldn't rely on this. > and makes use of the same assumption in: ffa_mem_desc_offset(). > https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448 > The later one seems wrong IMO. because we should compute the offset > based on the value stored in ep_mem_offset and not adding it up with > sizeof(struct ffa_mem_region). > > Maybe this should be the fix instead and not the one in pKVM ? What do > you think ? I think you should parse the buffers as the spec intends them, without assumptions or limitations. > > The current implementation in pKVM makes use of the > ffa_mem_desc_offset() to validate the first EMAD. If a compromised host > places an EMAD at a different offset than sizeof(struct ffa_mem_region), > then pKVM will not validate that EMAD. Why compromised? Isn't that a perfectly valid thing to do? What I understand is that the FFA 1.1 implementation in pKVM doesn't match the expectations of the spec. If that's indeed the case, pKVM should be fixed to accept these messages correctly, or stop using FFA 1.1. M. -- Without deviation from the norm, progress is not possible.