From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 565993E3D9D for ; Thu, 23 Apr 2026 09:29:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776936553; cv=none; b=FT37oO4jkz0sZwTIIhXdX5QdrpUO33keLb8rTcQvSkzbxeHoUYb958K6Wq4f+S/cy0nGQBA8KalZf6RMCsw6adTyu/45TYZ4pDLsB1vvcdJqwvP+aheidhKX+15q7dJH2QNGKDBc3YVSwoILp6hefiyRN5yPpMuc2mN6AWNm58A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776936553; c=relaxed/simple; bh=GEojIYOirnzY4XB4TS8FhRxgruQ0ZVW9LyRhvu+i+RQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p6f5HzVrEyeEeZVKiOYmdNGr2JeDUFNZSjgg59RojssrgiR67bY8uByYL7ZD1pDGRxEVRR2eTsJ1b38/gngRSJ7qrH4A/QRcSe2FySPYiXQ/8s4MVvtam5r6na7ivsqicvrww+yUJ6eYDVLW97T/nKaArlXlpb9HHnwmbRc1SYs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=j+HMv0Vd; arc=none smtp.client-ip=209.85.208.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="j+HMv0Vd" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-67148a70f8aso49721a12.1 for ; Thu, 23 Apr 2026 02:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776936551; x=1777541351; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=BKpJvW7DhMmQGBTcK6buF1FQEMkYscuj/n2ufvkVhMQ=; b=j+HMv0Vdcks7nTfJuSx4forfCW+J9rhkYnCdryV2N+j0gjPHMRA5hMH1I4jRghI1ea HUlqb1zHGVJdyaARdaDn2kpCzVELxoW5bMZOlCafBOhXdFxMTrsmDGgxe7vPXgc+YoD4 qC+TLPIzpLodyOIu8AbHuV82V7AkqBaHb7l5pR09g9blOsOAFztvuXiOpv6vJp9Oi2B6 F6oh2MECtW9cLNbpTDPKk9uQg1dr6wjV6PHdBWNBSasKqv1GazOnRle9WiKbpypihCil RldZRpumOVngDR3t/fT1+jbPZU9kPudnvEMObdOLnR41t6rUitMbOTXIB0dY2VlndpaY SNkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776936551; x=1777541351; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BKpJvW7DhMmQGBTcK6buF1FQEMkYscuj/n2ufvkVhMQ=; b=kmE7YXDDt7ytWdKCJiaTSfo6j9NY3W1AO6aGMicZmEBtu8R4G3bODpsyL5sGOlkVJf N7kZgqxuDQJWFeV2fILR+feu2s74Q6U6vSQQ5IetonlGtabnnjIATYECmN14P48F3O2F Ig9C5U9u5axIga8EZHE5GOHIJyilTHXTPjsx6MaD4qSMq4dMVBwObeULDY9NHtCW7hYD M8mfTiSmN5l+Hu71D24tYDwxBE4onepYtXefvQKzD2QgWuUigojGlkq0h7aOudiRdRjs ijFhRpwRaPlQhZVu+9GideBNykQh2WZe/iEli8iOr3xJmHAB+4wtVWIT772UgpDiwGEC KPgQ== X-Forwarded-Encrypted: i=1; AFNElJ+mJar5Mvkz7VxG0Ji3g1hcJhjeMS2CTvI6lBzbup8hhKXnuKrBQ4xnVuOResXJ51x9RkK4yZxRRpCgDc8=@vger.kernel.org X-Gm-Message-State: AOJu0Ywj9RilWp+C85PSAIoKlm4Nijxm7MfDinPBQ8x3GLqmyLLwiFy1 85ZAyMErMneCZwX10HRFN9irk5VouaAfCyL9OH0r19B4UpEnAOOyYUMNX5g+i5dZcQ== X-Gm-Gg: AeBDiev5dGrHOG6fj35zowAbn9X+nW3OCNr/r4XKpu78ui4IQT1hLJR7umLW1DqMMaE lsxmIBfVc/80he9FL/sRMNLSEyXenHtP/aOpPzd9bJHluLRHAvnxShkqV4AuWjDU/JJ8NvvQ7m8 GUVsGQYFFayOk9kaQeBewVqo5FbgIXmEMTLGvvasSSAn5SvI/diBdH9hqDY/u5RyjWZ5wJ8cK5A c4mc73TkIIiB90xz9+pBSb5BSklU9rFjY8c3jOwBAEn+wEEl7lLESvvO76K8KkQH5NSDLoQ7DLU ludrX6jDgR9WbpBXwoPkKW+6/l3REmf7Chm4YunwlewyawSiamTFDFbqwkQMqdmV0YrRdGTFRNN /piQ1CJ6NPikMOWg/kUUeZDTIuwseK4lJttX5rwLYv/yjoMY8+C4VocPterVIqqgUqLQyAqOekE RER0PfXcDoRE0Gywws4OcMPVaWxnxJLnqX0mX8fERnuu+abfxdgICCtXg2WMHTeTBAgBi40jVKC AikltoLIP0pXm8fT8k= X-Received: by 2002:a05:6402:902:b0:670:7177:94df with SMTP id 4fb4d7f45d1cf-67440714a81mr250309a12.6.1776936550235; Thu, 23 Apr 2026 02:29:10 -0700 (PDT) Received: from google.com (117.15.199.104.bc.googleusercontent.com. [104.199.15.117]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-672c4d5babcsm3890524a12.23.2026.04.23.02.29.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 02:29:08 -0700 (PDT) Date: Thu, 23 Apr 2026 09:29:04 +0000 From: Sebastian Ene To: Marc Zyngier 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 Message-ID: References: <20260422102540.1433704-1-sebastianene@google.com> <86bjfb18v1.wl-maz@kernel.org> <867bpy14kx.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867bpy14kx.wl-maz@kernel.org> On Thu, Apr 23, 2026 at 09:08:46AM +0100, Marc Zyngier wrote: > 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. Ack. > > > > > 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. Sorry, what I meant is that a potentially malicious host could abuse this limitation of the FF-A proxy validation which is looking at a fixed offset to do the EMAD validation. Another EMAD can be placed at a different offset and it will bypass the validation of the proxy alltogether. We have two choices: the simple one is what this patch does (enforce a fixed offset) or the second one : patch `ffa_mem_desc_offset` to use ep_mem_offset instead of `sizeof(struct ffa_mem_region)` and validate the ep_mem_offset. > > -- > Without deviation from the norm, progress is not possible. Thanks, Sebastian