| Message ID | 20200601094512.50509-2-sudeep.holla@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | firmware: Add support for PSA FF-A interface | expand |
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > at virtual interface(VMs). > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt I'm hoping this goes away if the firmware is discoverable, but if not DT bindings are DT schema now. Rob
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. We'll need the binding for the kvm host side, because there are plenty of partition properties that are not discoverable (e.g. number of vCPUs). I'll have a go a yamlifying what I have... Will
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. > Yes, consider it gone. I introduced it to couple of reasons both of which are now irrelevant. We may revisit this if we need it for Rx/Tx buffer information. The KVM host may need the binding, this was for the guests/ partitions as Will has already mentioned. -- Regards, Sudeep
On Wed, Jun 10, 2020 at 1:43 AM Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > at virtual interface(VMs). > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > --- > > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > 1 file changed, 47 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > I'm hoping this goes away if the firmware is discoverable, but if not DT > > bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). BTW, there's already a partitioning binding for Power in ePAPR. I've not paid much attention to it, but maybe it could be useful here. Rob
Hi Will, > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition >>> at virtual interface(VMs). >>> >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> --- >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ >>> 1 file changed, 47 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt >> >> I'm hoping this goes away if the firmware is discoverable, but if not DT >> bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). Just trying to understand the req. a bit better… The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine the count of partitions and their vCPUs. Is this about a guest being able to find out how many vCPUs it has? Cheers, Achin > > I'll have a go a yamlifying what I have... > > Will >
On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > >>> at virtual interface(VMs). > >>> > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > >>> --- > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > >>> 1 file changed, 47 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > >> > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > >> bindings are DT schema now. > > > > We'll need the binding for the kvm host side, because there are plenty > > of partition properties that are not discoverable (e.g. number of vCPUs). > > Just trying to understand the req. a bit better… > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > the count of partitions and their vCPUs. > > Is this about a guest being able to find out how many vCPUs it has? This is about KVM finding out the information it needs in order to spawn non-secure partitions. I don't see how it can do that with FFA_PARTITION_INFO_GET -- who would respond? But you're right that number of vCPUs was a bad example. We also need information such as the entry point. Will
On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > >>> at virtual interface(VMs). > > >>> > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > >>> --- > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > >>> 1 file changed, 47 insertions(+) > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > >> > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > >> bindings are DT schema now. > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > Just trying to understand the req. a bit better… > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > the count of partitions and their vCPUs. > > > > Is this about a guest being able to find out how many vCPUs it has? > > This is about KVM finding out the information it needs in order to spawn > non-secure partitions. I don't see how it can do that with > FFA_PARTITION_INFO_GET -- who would respond? 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. But then, can this be made discoverable (use a SMC for discovery) at all as Rob had originally suggested. Firmware (Secure world) has no clue and the bootloader is long gone. 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? > > But you're right that number of vCPUs was a bad example. We also need > information such as the entry point. Yes. From a spec perspective this should be specified in the partition manifest unless the base address of the loaded image can be assummed to be the entry point. cheers, Achin > > Will
On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > >>> at virtual interface(VMs). > > > >>> > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > >>> --- > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > >>> 1 file changed, 47 insertions(+) > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > >> > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > >> bindings are DT schema now. > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > Just trying to understand the req. a bit better… > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > the count of partitions and their vCPUs. > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > This is about KVM finding out the information it needs in order to spawn > > non-secure partitions. I don't see how it can do that with > > FFA_PARTITION_INFO_GET -- who would respond? > > 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. > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > had originally suggested. Firmware (Secure world) has no clue and the bootloader > is long gone. Make what discoverable? > 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. > > But you're right that number of vCPUs was a bad example. We also need > > information such as the entry point. > > Yes. From a spec perspective this should be specified in the partition manifest > unless the base address of the loaded image can be assummed to be the entry > point. Right, but the format of the manifest isn't defined by the spec so I really don't think it's something that Linux should be dealing with directly. Will
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: > > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > > >>> at virtual interface(VMs). > > > > >>> > > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > >>> --- > > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > > >>> 1 file changed, 47 insertions(+) > > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > >> > > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > > >> bindings are DT schema now. > > > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > > > Just trying to understand the req. a bit better… > > > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > > the count of partitions and their vCPUs. > > > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > > > This is about KVM finding out the information it needs in order to spawn > > > non-secure partitions. I don't see how it can do that with > > > FFA_PARTITION_INFO_GET -- who would respond? > > > > 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. > > > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > > had originally suggested. Firmware (Secure world) has no clue and the bootloader > > is long gone. > > Make what discoverable? I thought the original question was to make partition properties discoverable instead of relying on DT nodes. I might have misunderstood. Looks like we are on the same page in any case :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? 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 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! > > > > But you're right that number of vCPUs was a bad example. We also need > > > information such as the entry point. > > > > Yes. From a spec perspective this should be specified in the partition manifest > > unless the base address of the loaded image can be assummed to be the entry > > point. > > Right, but the format of the manifest isn't defined by the spec so I really > don't think it's something that Linux should be dealing with directly. Agree. cheers, Achin > > Will
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
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
diff --git a/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt new file mode 100644 index 000000000000..ee543fb5b397 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt @@ -0,0 +1,47 @@ +Arm Platform Security Architecture(PSA) Firmware Framework(FF) for Armv8-A +-------------------------------------------------------------------------- + +This binding is intended to define the interface the firmware framework +implementing the Non-secure partitions/endpoints(mostly VMs) as described +in ARM document ARM DEN 0077A ("Arm Platform Security Architecture +Firmware Framework for Arm v8-A") [0] + +In the case of a Non-secure virtual FF-A instance, the hypervisor +(e.g. Linux KVM) can use this binding to create and launch VM partitions. + +The SMCCC conduit available in the VM partition itself is used and hence +there is no explicit binding to specify the conduit used for PSA FFA +interface. + +Required properties: + +- compatible : Should be one of: + "arm,psa-ffa" + +- One or more child nodes, each describing an PSA FFA partition using the + following required properties: + + - compatible: Should be one of: + "arm,psa-ffa-partition" + + - uuid : The 128-bit UUID [2] of the service implemented by this partition, + represented as a string. + +[0] https://developer.arm.com/docs/den0077/latest +[1] https://tools.ietf.org/html/rfc4122 + +Example: + + #address-cells = <2>; + #size-cells = <2>; + + firmware { + psa-ffa { + compatible = "arm,psa-ffa"; + + partition0: psa_ffa_partition { + compatible = "arm,psa-ffa-partition"; + uuid = "12345678-9abc-def0-1234-56789abcdef0"; + }; + }; + };
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition at virtual interface(VMs). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt