[PATCH v2 01/10] KVM: arm64: Block unsafe FF-A calls from the host

[Will Deacon]

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.

Will