All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Quentin Perret <qperret@google.com>
Cc: kernel-team@android.com, Andrew Walbran <qwandor@google.com>,
	Marc Zyngier <maz@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	kvmarm@lists.linux.dev, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/12] KVM: arm64: Block unsafe FF-A calls from the host
Date: Wed, 16 Nov 2022 17:48:42 +0000	[thread overview]
Message-ID: <Y3Uiemx6YQxoZWhh@google.com> (raw)
In-Reply-To: <20221116170335.2341003-4-qperret@google.com>

Sorry, hit send a bit too early. Reviewing the patch itself:

On Wed, Nov 16, 2022 at 05:03:26PM +0000, Quentin Perret wrote:

[...]

> +static bool ffa_call_unsupported(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:
> +		return true;
> +	}
> +
> +	return false;
> +}

Wouldn't an allowlist behave better in this case? While unlikely, you
wouldn't want EL3 implementing some FFA_BACKDOOR_PVM SMC that falls
outside of the denylist and is passed through.

> +bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
> +{
> +	DECLARE_REG(u64, func_id, host_ctxt, 0);
> +	struct arm_smccc_res res;
> +
> +	if (!is_ffa_call(func_id))
> +		return false;
> +
> +	switch (func_id) {
> +	/* Memory management */
> +	case FFA_FN64_RXTX_MAP:
> +	case FFA_RXTX_UNMAP:
> +	case FFA_MEM_SHARE:
> +	case FFA_FN64_MEM_SHARE:
> +	case FFA_MEM_LEND:
> +	case FFA_FN64_MEM_LEND:
> +	case FFA_MEM_RECLAIM:
> +	case FFA_MEM_FRAG_TX:
> +		break;
> +	}

What is the purpose of this switch?

> +
> +	if (!ffa_call_unsupported(func_id))
> +		return false; /* Pass through */

Another (tiny) benefit of implementing an allowlist is that it avoids
the use of double-negative logic like this.

--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Quentin Perret <qperret@google.com>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andrew Walbran <qwandor@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 03/12] KVM: arm64: Block unsafe FF-A calls from the host
Date: Wed, 16 Nov 2022 17:48:42 +0000	[thread overview]
Message-ID: <Y3Uiemx6YQxoZWhh@google.com> (raw)
Message-ID: <20221116174842.i1hdjkxcHiHY54-BHYVxiXCmCVrrj7LTKmrlMT4-_q0@z> (raw)
In-Reply-To: <20221116170335.2341003-4-qperret@google.com>

Sorry, hit send a bit too early. Reviewing the patch itself:

On Wed, Nov 16, 2022 at 05:03:26PM +0000, Quentin Perret wrote:

[...]

> +static bool ffa_call_unsupported(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:
> +		return true;
> +	}
> +
> +	return false;
> +}

Wouldn't an allowlist behave better in this case? While unlikely, you
wouldn't want EL3 implementing some FFA_BACKDOOR_PVM SMC that falls
outside of the denylist and is passed through.

> +bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
> +{
> +	DECLARE_REG(u64, func_id, host_ctxt, 0);
> +	struct arm_smccc_res res;
> +
> +	if (!is_ffa_call(func_id))
> +		return false;
> +
> +	switch (func_id) {
> +	/* Memory management */
> +	case FFA_FN64_RXTX_MAP:
> +	case FFA_RXTX_UNMAP:
> +	case FFA_MEM_SHARE:
> +	case FFA_FN64_MEM_SHARE:
> +	case FFA_MEM_LEND:
> +	case FFA_FN64_MEM_LEND:
> +	case FFA_MEM_RECLAIM:
> +	case FFA_MEM_FRAG_TX:
> +		break;
> +	}

What is the purpose of this switch?

> +
> +	if (!ffa_call_unsupported(func_id))
> +		return false; /* Pass through */

Another (tiny) benefit of implementing an allowlist is that it avoids
the use of double-negative logic like this.

--
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Quentin Perret <qperret@google.com>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andrew Walbran <qwandor@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 03/12] KVM: arm64: Block unsafe FF-A calls from the host
Date: Wed, 16 Nov 2022 17:48:42 +0000	[thread overview]
Message-ID: <Y3Uiemx6YQxoZWhh@google.com> (raw)
In-Reply-To: <20221116170335.2341003-4-qperret@google.com>

Sorry, hit send a bit too early. Reviewing the patch itself:

On Wed, Nov 16, 2022 at 05:03:26PM +0000, Quentin Perret wrote:

[...]

> +static bool ffa_call_unsupported(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:
> +		return true;
> +	}
> +
> +	return false;
> +}

Wouldn't an allowlist behave better in this case? While unlikely, you
wouldn't want EL3 implementing some FFA_BACKDOOR_PVM SMC that falls
outside of the denylist and is passed through.

> +bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
> +{
> +	DECLARE_REG(u64, func_id, host_ctxt, 0);
> +	struct arm_smccc_res res;
> +
> +	if (!is_ffa_call(func_id))
> +		return false;
> +
> +	switch (func_id) {
> +	/* Memory management */
> +	case FFA_FN64_RXTX_MAP:
> +	case FFA_RXTX_UNMAP:
> +	case FFA_MEM_SHARE:
> +	case FFA_FN64_MEM_SHARE:
> +	case FFA_MEM_LEND:
> +	case FFA_FN64_MEM_LEND:
> +	case FFA_MEM_RECLAIM:
> +	case FFA_MEM_FRAG_TX:
> +		break;
> +	}

What is the purpose of this switch?

> +
> +	if (!ffa_call_unsupported(func_id))
> +		return false; /* Pass through */

Another (tiny) benefit of implementing an allowlist is that it avoids
the use of double-negative logic like this.

--
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-11-16 17:48 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 17:03 [PATCH 00/12] KVM: arm64: FF-A proxy for pKVM Quentin Perret
2022-11-16 17:03 ` Quentin Perret
2022-11-16 17:03 ` Quentin Perret
2022-11-16 17:03 ` [PATCH 01/12] firmware: arm_ffa: Move constants to header file Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-12-01 11:43   ` Sudeep Holla
2022-12-01 11:43     ` Sudeep Holla
2022-12-01 11:43     ` Sudeep Holla
2022-11-16 17:03 ` [PATCH 02/12] firmware: arm_ffa: Move comment before the field it is documenting Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-12-01 11:53   ` Sudeep Holla
2022-12-01 11:53     ` Sudeep Holla
2022-12-01 11:53     ` Sudeep Holla
2022-12-01 15:49     ` Will Deacon
2022-12-01 15:49       ` Will Deacon
2022-12-01 15:49       ` Will Deacon
2022-11-16 17:03 ` [PATCH 03/12] KVM: arm64: Block unsafe FF-A calls from the host Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:40   ` Oliver Upton
2022-11-16 17:40     ` Oliver Upton
2022-11-16 17:40     ` Oliver Upton
2023-04-18 12:41     ` Will Deacon
2023-04-18 12:41       ` Will Deacon
2022-11-16 17:48   ` Oliver Upton [this message]
2022-11-16 17:48     ` Oliver Upton
2022-11-16 17:48     ` Oliver Upton
2023-04-18 12:48     ` Will Deacon
2023-04-18 12:48       ` Will Deacon
2022-11-16 17:03 ` [PATCH 04/12] KVM: arm64: Probe FF-A version and host/hyp partition ID during init Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 05/12] KVM: arm64: Handle FFA_FEATURES call from the host Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 06/12] KVM: arm64: Allocate pages for hypervisor FF-A mailboxes Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 07/12] KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 08/12] KVM: arm64: Add FF-A helpers to share/unshare memory with secure world Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 09/12] KVM: arm64: Handle FFA_MEM_SHARE calls from the host Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 10/12] KVM: arm64: Handle FFA_MEM_RECLAIM " Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 11/12] KVM: arm64: Handle FFA_MEM_LEND " Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03 ` [PATCH 12/12] ANDROID: KVM: arm64: pkvm: Add support for fragmented FF-A descriptors Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:03   ` Quentin Perret
2022-11-16 17:06   ` Quentin Perret
2022-11-16 17:06     ` Quentin Perret
2022-11-16 17:06     ` Quentin Perret
2022-12-02 11:17 ` [PATCH 00/12] KVM: arm64: FF-A proxy for pKVM Will Deacon
2022-12-02 11:17   ` Will Deacon
2022-12-02 11:17   ` 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=Y3Uiemx6YQxoZWhh@google.com \
    --to=oliver.upton@linux.dev \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=qperret@google.com \
    --cc=qwandor@google.com \
    --cc=sudeep.holla@arm.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.