Hi All,
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI), I got more doubts on alignment
and dropped huge chunk of interface APIs in the driver in order to keep
it simple, and get aligned more with that prototype and avoid scanning
lots of code unnecessary.
Here are few things to clarify:
1. DT bindings
---------------
I was initially against adding bindings for Tx/Rx buffers for
partitions. As per the spec, an endpoint could allocate the
buffer pair and use the FFA_RXTX_MAP interface to map it with the
Hypervisor(KVM here). However looking at the prototype and also
I remember you mentioning that it is not possible to manage buffers
in that way. Please confirm if you plan to add the buffer details
fetcthing them through ioctls in KVM and adding them to VM DT nodes
in KVM userspace. I will update the bindings accordingly.
2. Driver
---------
a. Support for multiple partitions in a VM
------------------------------------------
I am not sure if there is need for supporting multiple partitions
within a VM. It should be possible to do so as I expect to create
device for each partition entry under arm-psa-ffa devicetree node.
However, I don't want to assume something that will never be a
usecase. However I don't think this will change must of the
abstraction as we need to keep the interface API implementation
separate to support different partitions on various platforms.
b. SMCCC interface
------------------
This is something I messed up completely while trying to add
support for SMCCC v1.2. It now supports x0-x17 as parameter
registers(input) and return registers(output). I started simple
with x0-x7 as both input and output as PSA FF-A needs that at
most. But extending to x0-x17 then became with messy in my
implementation. That's the reason I dropped it completely
here and thought of checking it first.
Do we need to extend the optimisations that were done to handle
ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
as both input and ouput. Hyper-V guys need full x0-x17 support.
I need some guidance as what is the approach preferred ?
3. Partitions
-------------
I am not sure if we have a full define partition that we plan to
push upstream. Without one, we can have a sample/example partition
to test all the interface APIs, but is that fine with respect to
what we want upstream ? Any other thoughts that helps to test the
driver ?
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
Sudeep Holla (3):
dt-bindings: Add ARM PSA FF binding for non-secure VM partitions
firmware: Add support for PSA FF-A transport for VM partitions
firmware: Add example PSA FF-A non-secure VM partition
.../devicetree/bindings/arm/arm,psa-ffa.txt | 47 ++++
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_psa_ffa/Kconfig | 22 ++
drivers/firmware/arm_psa_ffa/Makefile | 3 +
drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++
drivers/firmware/arm_psa_ffa/partition.c | 71 +++++
include/linux/arm_psa_ffa.h | 42 +++
8 files changed, 437 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig
create mode 100644 drivers/firmware/arm_psa_ffa/Makefile
create mode 100644 drivers/firmware/arm_psa_ffa/driver.c
create mode 100644 drivers/firmware/arm_psa_ffa/partition.c
create mode 100644 include/linux/arm_psa_ffa.h
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -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";+ };+ };+ };
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This is just an example non-secure VM partition to show how to create
the device and use the PSA FF-A interface APIs.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_psa_ffa/Kconfig | 7 +++
drivers/firmware/arm_psa_ffa/Makefile | 1 +
drivers/firmware/arm_psa_ffa/partition.c | 71 ++++++++++++++++++++++++
3 files changed, 79 insertions(+)
create mode 100644 drivers/firmware/arm_psa_ffa/partition.c
@@ -0,0 +1,42 @@+/* SPDX-License-Identifier: GPL-2.0 */+/*+*Copyright(C)2019,2020ArmLtd.+*/++#ifndef __LINUX_ARM_PSA_FFA_H+#define __LINUX_ARM_PSA_FFA_H++#include<linux/device.h>+#include<linux/types.h>++structpsa_ffa_partition_info{+/* The ID of the VM the information is about */+uint16_tid;+/* The number of execution contexts implemented by the partition */+uint16_texecution_context;+/* The Partition's properties, e.g. supported messaging methods */+uint32_tpartition_properties;+};+++/**+*structpsa_ffa_ops-representsthevariousPSA_FFAprotocoloperations+*availableforanendpoint.+*/+structarm_psa_ffa_handle{+u16(*id_get)(void);+int(*partition_info_get)(u32uuid0,u32uuid1,u32uuid2,u32uuid3,+structpsa_ffa_partition_info**);+};++#if IS_REACHABLE(CONFIG_ARM_PSA_FFA_TRANSPORT)+structarm_psa_ffa_handle*arm_psa_ffa_handle_get(structdevice*dev);+#else+staticinline+structarm_psa_ffa_handle*arm_psa_ffa_handle_get(structdevice*dev)+{+returnNULL;+}+#endif++#endif /*__LINUX_ARM_PSA_FFA_H*/
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2020-06-04 13:37:53
Hi Sudeep, [+Fuad, Andrew and Ard]
(To other interested readers: if you haven't seen it, the FF-A spec is here:
https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf
since this discussion makes no sense without that, and a tiny bit of sense
with it. It used to be called "SPCI" but it was recently renamed.)
On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI),
Yes, I need to do the Big Rename at some point. Joy.
I got more doubts on alignment and dropped huge chunk of interface APIs in
the driver in order to keep it simple, and get aligned more with that
prototype and avoid scanning lots of code unnecessary.
You also dropped most of the code, so this doesn't really do anything in
its current form ;)
Here are few things to clarify:
1. DT bindings
---------------
I was initially against adding bindings for Tx/Rx buffers for
partitions. As per the spec, an endpoint could allocate the
buffer pair and use the FFA_RXTX_MAP interface to map it with the
Hypervisor(KVM here). However looking at the prototype and also
I remember you mentioning that it is not possible to manage buffers
in that way. Please confirm if you plan to add the buffer details
fetcthing them through ioctls in KVM and adding them to VM DT nodes
in KVM userspace. I will update the bindings accordingly.
I think it's useful to have a mode of operation where the hypervisor
allocates the RX/TX buffers and advertises them in the DT. However, we
can always add this later, so there's no need to have it in the binding
from the start. Best start as simple as possible, I reckon.
Setting the static RX/TX buffer allocation aside, why is a DT node needed
at all for the case where Linux is running purely as an FF-A client? I
thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
without a binding at all for the client case.
2. Driver
---------
a. Support for multiple partitions in a VM
------------------------------------------
I am not sure if there is need for supporting multiple partitions
within a VM. It should be possible to do so as I expect to create
device for each partition entry under arm-psa-ffa devicetree node.
However, I don't want to assume something that will never be a
usecase. However I don't think this will change must of the
abstraction as we need to keep the interface API implementation
separate to support different partitions on various platforms.
I think Ard has a case for something like this, where a VM actually consists
of multiple partitions so that S-EL0 services can be provided from NS-EL0.
However, he probably wants that for a dynamically created VM, so we'd
need a way to instantiate an FFA namespace for the VM. Maybe that can be
done entirely in userspace by the VMM...
b. SMCCC interface
------------------
This is something I messed up completely while trying to add
support for SMCCC v1.2. It now supports x0-x17 as parameter
registers(input) and return registers(output). I started simple
with x0-x7 as both input and output as PSA FF-A needs that at
most. But extending to x0-x17 then became with messy in my
implementation. That's the reason I dropped it completely
here and thought of checking it first.
Do we need to extend the optimisations that were done to handle
ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
as both input and ouput. Hyper-V guys need full x0-x17 support.
I need some guidance as what is the approach preferred ?
I think we can start off with x0-x7 and extend if later if we need to.
3. Partitions
-------------
I am not sure if we have a full define partition that we plan to
push upstream. Without one, we can have a sample/example partition
to test all the interface APIs, but is that fine with respect to
what we want upstream ? Any other thoughts that helps to test the
driver ?
I think that's the best you can do for now. We can probably help with
testing as our stuff gets off the ground.
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
No problem. Maybe it would help if I described roughly what we were thinking
of doing for KVM (this is open for discussion, of course):
1. Describe KVM-managed partitions in the DT, along the lines of [1]
2. Expose each partition as a file to userspace. E.g.:
/dev/spci/:
self
e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
49f65057-d002-4ae2-b4ee-d31c7940a13d
Here, self would be a symlink to the host uuid. The host uuid file
would implement FFA_MEM operations using an ioctl(), so you could,
for example, share a user buffer with multiple partitions by issuing
a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
as arguments. Messaging would be implemented as ioctl()s on the
partition uuid files themselves.
3. We'll need some (all?) of these patches to unmap memory from the host
when necessary:
https://lwn.net/Articles/821215/
(for nVHE, we'll have a stage-2 for the host so we can unmap there as
well)
For communicating with partitions that are not managed by KVM (e.g. trusted
applications), it's not clear to me how much of that will be handled in
kernel or user. I think it would still be worth exposing the partitions as
files, but perhaps having them root only or just returning -EPERM for the
ioctl() if a kernel driver has claimed the partition as its own? Ideally,
FF-A would allow us to transition some of the Trusted OS interfacing code
out to userspace, but I don't know how realistic that is.
Anyway, to enable this, I think we need a clear separation in the kernel
between the FF-A code and the users: KVM will want to expose things as
above, but if drivers need to use this stuff as well then they can plug in
as additional users and we don't have to worry about tripping over the
RX/TX buffers etc.
What do you think, and do you reckon you can spin a cut-down driver that
implements the common part of the logic (since I know you've written much
of this code already)?
Cheers,
Will
[1] https://android-kvm.googlesource.com/linux/+/8632a5723ef106017c4ab57e95d9ce7630d35522%5E%21/#F0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
quoted
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI),
Yes, I need to do the Big Rename at some point. Joy.
😁
quoted
I got more doubts on alignment and dropped huge chunk of interface APIs in
the driver in order to keep it simple, and get aligned more with that
prototype and avoid scanning lots of code unnecessary.
You also dropped most of the code, so this doesn't really do anything in
its current form ;)
Yes, it was intentional 😉
quoted
Here are few things to clarify:
1. DT bindings
---------------
I was initially against adding bindings for Tx/Rx buffers for
partitions. As per the spec, an endpoint could allocate the
buffer pair and use the FFA_RXTX_MAP interface to map it with the
Hypervisor(KVM here). However looking at the prototype and also
I remember you mentioning that it is not possible to manage buffers
in that way. Please confirm if you plan to add the buffer details
fetcthing them through ioctls in KVM and adding them to VM DT nodes
in KVM userspace. I will update the bindings accordingly.
I think it's useful to have a mode of operation where the hypervisor
allocates the RX/TX buffers and advertises them in the DT. However, we
can always add this later, so there's no need to have it in the binding
from the start. Best start as simple as possible, I reckon.
OK
Setting the static RX/TX buffer allocation aside, why is a DT node needed
at all for the case where Linux is running purely as an FF-A client? I
thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
without a binding at all for the client case.
Agreed, I added for RxTx buffers and initially to build the parent/child
hierarchy for all users of the driver. Initially I was assuming only
in-kernel users and now I agree we should avoid any in kernel users if
possible.
One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
information to the caller. So we need to have established buffers before
that and one of the reason you don't find that in this RFC. I dropped that
too which I wanted initially.
quoted
2. Driver
---------
a. Support for multiple partitions in a VM
------------------------------------------
I am not sure if there is need for supporting multiple partitions
within a VM. It should be possible to do so as I expect to create
device for each partition entry under arm-psa-ffa devicetree node.
However, I don't want to assume something that will never be a
usecase. However I don't think this will change must of the
abstraction as we need to keep the interface API implementation
separate to support different partitions on various platforms.
I think Ard has a case for something like this, where a VM actually consists
of multiple partitions so that S-EL0 services can be provided from NS-EL0.
However, he probably wants that for a dynamically created VM, so we'd
need a way to instantiate an FFA namespace for the VM. Maybe that can be
done entirely in userspace by the VMM...
Interesting...
quoted
b. SMCCC interface
------------------
This is something I messed up completely while trying to add
support for SMCCC v1.2. It now supports x0-x17 as parameter
registers(input) and return registers(output). I started simple
with x0-x7 as both input and output as PSA FF-A needs that at
most. But extending to x0-x17 then became with messy in my
implementation. That's the reason I dropped it completely
here and thought of checking it first.
Do we need to extend the optimisations that were done to handle
ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
as both input and ouput. Hyper-V guys need full x0-x17 support.
I need some guidance as what is the approach preferred ?
I think we can start off with x0-x7 and extend if later if we need to.
Sure
quoted
3. Partitions
-------------
I am not sure if we have a full define partition that we plan to
push upstream. Without one, we can have a sample/example partition
to test all the interface APIs, but is that fine with respect to
what we want upstream ? Any other thoughts that helps to test the
driver ?
I think that's the best you can do for now. We can probably help with
testing as our stuff gets off the ground.
OK
quoted
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
No problem. Maybe it would help if I described roughly what we were thinking
of doing for KVM (this is open for discussion, of course):
1. Describe KVM-managed partitions in the DT, along the lines of [1]
2. Expose each partition as a file to userspace. E.g.:
/dev/spci/:
self
e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
49f65057-d002-4ae2-b4ee-d31c7940a13d
Here, self would be a symlink to the host uuid. The host uuid file
would implement FFA_MEM operations using an ioctl(), so you could,
for example, share a user buffer with multiple partitions by issuing
a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
as arguments. Messaging would be implemented as ioctl()s on the
partition uuid files themselves.
OK, IIUC that covers mostly KVM implementation. We still need a way to
share the RxTx buffer info to the partitions and DT/ACPI(?) is one
possible way. Based on you comment about not needing DT node, do you have
any other way to communicate the buffer info to the partitions ?
3. We'll need some (all?) of these patches to unmap memory from the host
when necessary:
https://lwn.net/Articles/821215/
(for nVHE, we'll have a stage-2 for the host so we can unmap there as
well)
Sounds more fun.
For communicating with partitions that are not managed by KVM (e.g. trusted
applications), it's not clear to me how much of that will be handled in
kernel or user. I think it would still be worth exposing the partitions as
files, but perhaps having them root only or just returning -EPERM for the
ioctl() if a kernel driver has claimed the partition as its own? Ideally,
FF-A would allow us to transition some of the Trusted OS interfacing code
out to userspace, but I don't know how realistic that is.
Ah good, so we can still manage in-kernel users this way but we need to
provide interface to such a driver which I agree that we need to avoid
if possible.
Anyway, to enable this, I think we need a clear separation in the kernel
between the FF-A code and the users:
Agreed.
KVM will want to expose things as above, but if drivers need to use this
stuff as well then they can plug in as additional users and we don't have to
worry about tripping over the RX/TX buffers etc.
I am confused a bit. When you refer drivers above, are you referring to
drivers in host kernel(hypervisor) or in the partitions. I fail to
imagine need for the former.
What do you think, and do you reckon you can spin a cut-down driver that
implements the common part of the logic (since I know you've written much
of this code already)?
I am not sure if I am aligned with your thoughts on the buffer sharing
yet.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2020-06-09 22:35:57
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 <redacted>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2020-06-10 07:43:53
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:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2020-06-10 07:57:21
Hi Sudeep,
On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:
On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
quoted
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI),
Yes, I need to do the Big Rename at some point. Joy.
Setting the static RX/TX buffer allocation aside, why is a DT node needed
at all for the case where Linux is running purely as an FF-A client? I
thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
without a binding at all for the client case.
Agreed, I added for RxTx buffers and initially to build the parent/child
hierarchy for all users of the driver. Initially I was assuming only
in-kernel users and now I agree we should avoid any in kernel users if
possible.
One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
information to the caller. So we need to have established buffers before
that and one of the reason you don't find that in this RFC. I dropped that
too which I wanted initially.
Ok, sounds like we should at least get to a position where we can enumerate
things, though.
quoted
quoted
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
No problem. Maybe it would help if I described roughly what we were thinking
of doing for KVM (this is open for discussion, of course):
1. Describe KVM-managed partitions in the DT, along the lines of [1]
2. Expose each partition as a file to userspace. E.g.:
/dev/spci/:
self
e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
49f65057-d002-4ae2-b4ee-d31c7940a13d
Here, self would be a symlink to the host uuid. The host uuid file
would implement FFA_MEM operations using an ioctl(), so you could,
for example, share a user buffer with multiple partitions by issuing
a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
as arguments. Messaging would be implemented as ioctl()s on the
partition uuid files themselves.
OK, IIUC that covers mostly KVM implementation. We still need a way to
share the RxTx buffer info to the partitions and DT/ACPI(?) is one
possible way. Based on you comment about not needing DT node, do you have
any other way to communicate the buffer info to the partitions ?
This is only a concern if KVM chooses to provide the Rx/Tx buffer pair
though, right? If we punt that down the road for the moment, then we can
just rely on FFA_RXTX_MAP for now.
quoted
For communicating with partitions that are not managed by KVM (e.g. trusted
applications), it's not clear to me how much of that will be handled in
kernel or user. I think it would still be worth exposing the partitions as
files, but perhaps having them root only or just returning -EPERM for the
ioctl() if a kernel driver has claimed the partition as its own? Ideally,
FF-A would allow us to transition some of the Trusted OS interfacing code
out to userspace, but I don't know how realistic that is.
Ah good, so we can still manage in-kernel users this way but we need to
provide interface to such a driver which I agree that we need to avoid
if possible.
quoted
Anyway, to enable this, I think we need a clear separation in the kernel
between the FF-A code and the users:
Agreed.
quoted
KVM will want to expose things as above, but if drivers need to use this
stuff as well then they can plug in as additional users and we don't have to
worry about tripping over the RX/TX buffers etc.
I am confused a bit. When you refer drivers above, are you referring to
drivers in host kernel(hypervisor) or in the partitions. I fail to
imagine need for the former.
I'm referring to in-kernel users in the host kernel. For KVM-managed guests,
we may not need these, although signalling things like system shutdown might
be better off done without relying on userspace. But my point is really that
separating the buffer management from the users means we can serialise
consumers, whether they are in-kernel or out in userspace.
quoted
What do you think, and do you reckon you can spin a cut-down driver that
implements the common part of the logic (since I know you've written much
of this code already)?
I am not sure if I am aligned with your thoughts on the buffer sharing
yet.
Hi Will,
On Wed, Jun 10, 2020 at 08:57:12AM +0100, Will Deacon wrote:
Hi Sudeep,
On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:
[...]
quoted
Agreed, I added for RxTx buffers and initially to build the parent/child
hierarchy for all users of the driver. Initially I was assuming only
in-kernel users and now I agree we should avoid any in kernel users if
possible.
One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
information to the caller. So we need to have established buffers before
that and one of the reason you don't find that in this RFC. I dropped that
too which I wanted initially.
Ok, sounds like we should at least get to a position where we can enumerate
things, though.
Yes.
[...]
quoted
OK, IIUC that covers mostly KVM implementation. We still need a way to
share the RxTx buffer info to the partitions and DT/ACPI(?) is one
possible way. Based on you comment about not needing DT node, do you have
any other way to communicate the buffer info to the partitions ?
This is only a concern if KVM chooses to provide the Rx/Tx buffer pair
though, right? If we punt that down the road for the moment, then we can
just rely on FFA_RXTX_MAP for now.
Ah OK, I was under the assumption that we didn't want to use FFA_RXTX_{,UN}MAP
[...]
quoted
I am confused a bit. When you refer drivers above, are you referring to
drivers in host kernel(hypervisor) or in the partitions. I fail to
imagine need for the former.
I'm referring to in-kernel users in the host kernel. For KVM-managed guests,
we may not need these, although signalling things like system shutdown might
be better off done without relying on userspace. But my point is really that
separating the buffer management from the users means we can serialise
consumers, whether they are in-kernel or out in userspace.
Understood.
quoted
quoted
What do you think, and do you reckon you can spin a cut-down driver that
implements the common part of the logic (since I know you've written much
of this code already)?
I am not sure if I am aligned with your thoughts on the buffer sharing
yet.
Ok, please let me know if you have any more questions.
None ATM. As I mentioned I had ruled out RXTX_{,UN}MAP which was my
misunderstanding.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2020-06-10 13:56:43
On Wed, Jun 10, 2020 at 1:43 AM Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 10 Jun 2020, at 08:43, Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
From: Will Deacon <will@kernel.org> Date: 2020-06-11 17:12:30
On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
quoted
On 10 Jun 2020, at 08:43, Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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:
quoted
quoted
On 10 Jun 2020, at 08:43, Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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
From: Will Deacon <will@kernel.org> Date: 2020-06-15 09:51:41
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:
quoted
On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
quoted
quoted
On 10 Jun 2020, at 08:43, Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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.
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
quoted
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI),
Yes, I need to do the Big Rename at some point. Joy.
😁
quoted
quoted
I got more doubts on alignment and dropped huge chunk of interface APIs in
the driver in order to keep it simple, and get aligned more with that
prototype and avoid scanning lots of code unnecessary.
You also dropped most of the code, so this doesn't really do anything in
its current form ;)
Yes, it was intentional 😉
quoted
quoted
Here are few things to clarify:
1. DT bindings
---------------
I was initially against adding bindings for Tx/Rx buffers for
partitions. As per the spec, an endpoint could allocate the
buffer pair and use the FFA_RXTX_MAP interface to map it with the
Hypervisor(KVM here). However looking at the prototype and also
I remember you mentioning that it is not possible to manage buffers
in that way. Please confirm if you plan to add the buffer details
fetcthing them through ioctls in KVM and adding them to VM DT nodes
in KVM userspace. I will update the bindings accordingly.
I think it's useful to have a mode of operation where the hypervisor
allocates the RX/TX buffers and advertises them in the DT. However, we
can always add this later, so there's no need to have it in the binding
from the start. Best start as simple as possible, I reckon.
OK
quoted
Setting the static RX/TX buffer allocation aside, why is a DT node needed
at all for the case where Linux is running purely as an FF-A client? I
thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
without a binding at all for the client case.
Agreed, I added for RxTx buffers and initially to build the parent/child
hierarchy for all users of the driver. Initially I was assuming only
in-kernel users and now I agree we should avoid any in kernel users if
possible.
One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
information to the caller. So we need to have established buffers before
that and one of the reason you don't find that in this RFC. I dropped that
too which I wanted initially.
quoted
quoted
2. Driver
---------
a. Support for multiple partitions in a VM
------------------------------------------
I am not sure if there is need for supporting multiple partitions
within a VM. It should be possible to do so as I expect to create
device for each partition entry under arm-psa-ffa devicetree node.
However, I don't want to assume something that will never be a
usecase. However I don't think this will change must of the
abstraction as we need to keep the interface API implementation
separate to support different partitions on various platforms.
I think Ard has a case for something like this, where a VM actually consists
of multiple partitions so that S-EL0 services can be provided from NS-EL0.
However, he probably wants that for a dynamically created VM, so we'd
need a way to instantiate an FFA namespace for the VM. Maybe that can be
done entirely in userspace by the VMM...
Interesting...
quoted
quoted
b. SMCCC interface
------------------
This is something I messed up completely while trying to add
support for SMCCC v1.2. It now supports x0-x17 as parameter
registers(input) and return registers(output). I started simple
with x0-x7 as both input and output as PSA FF-A needs that at
most. But extending to x0-x17 then became with messy in my
implementation. That's the reason I dropped it completely
here and thought of checking it first.
Do we need to extend the optimisations that were done to handle
ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
as both input and ouput. Hyper-V guys need full x0-x17 support.
I need some guidance as what is the approach preferred ?
I think we can start off with x0-x7 and extend if later if we need to.
Sure
quoted
quoted
3. Partitions
-------------
I am not sure if we have a full define partition that we plan to
push upstream. Without one, we can have a sample/example partition
to test all the interface APIs, but is that fine with respect to
what we want upstream ? Any other thoughts that helps to test the
driver ?
I think that's the best you can do for now. We can probably help with
testing as our stuff gets off the ground.
OK
quoted
quoted
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
No problem. Maybe it would help if I described roughly what we were thinking
of doing for KVM (this is open for discussion, of course):
1. Describe KVM-managed partitions in the DT, along the lines of [1]
2. Expose each partition as a file to userspace. E.g.:
/dev/spci/:
self
e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
49f65057-d002-4ae2-b4ee-d31c7940a13d
Here, self would be a symlink to the host uuid. The host uuid file
would implement FFA_MEM operations using an ioctl(), so you could,
for example, share a user buffer with multiple partitions by issuing
a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
as arguments. Messaging would be implemented as ioctl()s on the
partition uuid files themselves.
OK, IIUC that covers mostly KVM implementation. We still need a way to
share the RxTx buffer info to the partitions and DT/ACPI(?) is one
possible way. Based on you comment about not needing DT node, do you have
any other way to communicate the buffer info to the partitions ?
quoted
3. We'll need some (all?) of these patches to unmap memory from the host
when necessary:
https://lwn.net/Articles/821215/
(for nVHE, we'll have a stage-2 for the host so we can unmap there as
well)
Sounds more fun.
quoted
For communicating with partitions that are not managed by KVM (e.g. trusted
applications), it's not clear to me how much of that will be handled in
kernel or user. I think it would still be worth exposing the partitions as
files, but perhaps having them root only or just returning -EPERM for the
ioctl() if a kernel driver has claimed the partition as its own? Ideally,
FF-A would allow us to transition some of the Trusted OS interfacing code
out to userspace, but I don't know how realistic that is.
Ah good, so we can still manage in-kernel users this way but we need to
provide interface to such a driver which I agree that we need to avoid
if possible.
The OP-TEE driver is an in-kernel user, I don't see that we can migrate
that to user space in the nearest future. In fact I'm not sure it would
make sense since we have a kernel internal interface which is used by
some drivers.
Cheers,
Jens
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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:
quoted
On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote:
quoted
On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
quoted
quoted
On 10 Jun 2020, at 08:43, Will Deacon [off-list ref] wrote:
On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
quoted
On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
quoted
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <redacted>
---
.../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.
quoted
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)
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?
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!
quoted
quoted
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.
From: Will Deacon <will@kernel.org> Date: 2020-06-15 11:55:57
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
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:
quoted
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.
Sure. I am realising the need to maintain the distinction :o)
quoted
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.
Ok. Good to know this.
quoted
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.
quoted
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.
Most of this driver should be usable on any platform, so it would be
better to only depend on ARM64 in the component that has the arm64
specific implementation of your low level conduit.
...
+struct arm_smccc_res
+__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0,
...
+struct arm_smccc_res
+__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0,
Can these two functions move out of this file so this driver only
depends on a function matching the arm_psa_ffa_fn type?
...
+static int psa_ffa_probe(struct platform_device *pdev)
+{
+ int ret;
+ enum arm_smccc_conduit conduit;
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
+ return 0;
+
+ conduit = arm_smccc_1_1_get_conduit();
If you make this device a child device of the conduit, then you don't
need this here. Other conduits can be added to for instance support
other architectures without adding entries to this enum and modifying
this driver.
--
Arve Hjønnevåg
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel