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

[Oliver Upton]

On Mon, May 22, 2023 at 12:22:20PM +0100, Will Deacon wrote:
> 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.

Thanks, and fully understand what led to the policy you folks have
implemented. Perhaps in the future we can add an optional, restrictive
model to satisfy users that have a more adversarial relationship with
firmware interfaces. Not worth addressing in this series, though.

Going forwared, can the goals/non-goals of the current pKVM design be
captured somewhere in documentation? I think this can be done
organically as more bits and pieces are upstreamed, but it'd help
reviewers who haven't spent time in the trenches with pKVM to at least
grasp the intent. At least personally, I really like to see the pKVM
stuff landing upstream but haven't had first-hand experience with the
horrors of client devices :)

-- 
Thanks,
Oliver