On Mon, Jun 15, 2020 at 12:55:49PM +0100, Will Deacon wrote: > 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. Sure. I am realising the need to maintain the distinction :o) > > > > > 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. Ok. Good to know this. > > > 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. Agree. > > > 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. Fair point! cheers, Achin > > Will
