Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote:

On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote:

quoted

On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote:

quoted

Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
determine partition properties. It assumes that EL2 SW has already read each
partition's manifest and will reply to this ABI.

IIUC, with protected KVM, this information will have to be a part of the
manifest that the KVM host consumes.

The host does not consume the manifest directly -- instead, the bootloader
will use the manifest to populate these DT nodes. Again, these are *only*
for non-secure virtual partitions which are to be managed by KVM.

Yes. Understand and agree. Manifest is an overloaded term. I was using it to
describe the DT nodes that the host will consume.

Hmm, I think that conflates two things though because only the partitions
managed by KVM will have DT nodes.

quoted

quoted

Separate topic, protected KVM does not get dibs on the manifest and it relies on
the KVM host to specify the address ranges for each partition? Does this not
mean that the KVM host can control the physical address space each partition
sees. This seems contrary to the isolation guarantees that protected KVM must
provide?

The host is trusted during early boot, and gives up this trust after
initialising EL2 fully. So roughly speaking, we:

	* Boot at EL2 and install a shim
	* Drop down to EL2 and start the host kernel
	* Before some initialisation (DT parsing, SMP bringup, etc)
	* Init KVM by calling back up to EL2 to install the full hypervisor

At that point, the EL1 host is no longer trusted and the last call
effectively "locks it out" from EL2.

Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition
by the Host. My main concern is if PKVM must trust the Host to provide the
correct physical address space ranges for a partition?

Yes, but that all happens as part of KVM initialisation: the host parses
the DT nodes and memory reservations, and then passes this information
up to EL2.

I guess your point is this is not a problem since PKVM can lock the Host out of
those address ranges in any case?

It has to do this, regardless of how they are probed. Once KVM has
initialised, the host will have a stage-2 which limits it to the memory that
it is allowed to access.

It is a bit counter intuitive that the Host gets to see and potentially
manipulate information that was verified and extracted by the bootloader from
the partition's manifest. This hapens before PKVM sees the same
information. Can't put my finger on what could go wrong though. Depends upon the
threat model too!

I think you're trying too hard to separate the host from the EL2 code during
early boot. Don't forget -- this is all part of the same binary payload that
is loaded and initially run at EL2. Having the host take care of early boot
/significantly/ reduces the amount of code at EL2, which has a very
clear security benefit.

Will

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