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: > > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > > 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. > > > 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
