From: Oliver Upton <oliver.upton@linux.dev>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Quentin Perret <qperret@google.com>,
Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Sebastian Ene <sebastianene@google.com>,
Fuad Tabba <tabba@google.com>,
kvmarm@lists.linux.dev, kernel-team@android.com,
Andrew Walbran <qwandor@google.com>
Subject: Re: [PATCH v2 01/10] KVM: arm64: Block unsafe FF-A calls from the host
Date: Wed, 10 May 2023 19:08:01 +0000 [thread overview]
Message-ID: <ZFvrkQ8Nt6AUZwrt@linux.dev> (raw)
In-Reply-To: <20230419122051.1341-2-will@kernel.org>
Hi Will,
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.
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.
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-05-10 19:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 12:20 [PATCH v2 00/10] KVM: arm64: FF-A proxy for pKVM Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 01/10] KVM: arm64: Block unsafe FF-A calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-05-10 19:08 ` Oliver Upton [this message]
2023-05-22 11:22 ` Will Deacon
2023-05-22 11:22 ` Will Deacon
2023-05-23 8:07 ` Oliver Upton
2023-05-23 8:07 ` Oliver Upton
2023-04-19 12:20 ` [PATCH v2 02/10] KVM: arm64: Probe FF-A version and host/hyp partition ID during init Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 03/10] KVM: arm64: Allocate pages for hypervisor FF-A mailboxes Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 04/10] KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-05-10 20:50 ` Oliver Upton
2023-05-22 11:48 ` Will Deacon
2023-05-22 11:48 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 05/10] KVM: arm64: Add FF-A helpers to share/unshare memory with secure world Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 06/10] KVM: arm64: Handle FFA_MEM_SHARE calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 07/10] KVM: arm64: Handle FFA_MEM_RECLAIM " Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 08/10] KVM: arm64: Handle FFA_MEM_LEND " Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 09/10] KVM: arm64: Handle FFA_FEATURES call " Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 10/10] KVM: arm64: pkvm: Add support for fragmented FF-A descriptors Will Deacon
2023-04-19 12:20 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFvrkQ8Nt6AUZwrt@linux.dev \
--to=oliver.upton@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=james.morse@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=qperret@google.com \
--cc=qwandor@google.com \
--cc=sebastianene@google.com \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.