Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/12/2022 9:13 PM, Tom Lendacky wrote:
> On 12/12/22 05:21, Rijo Thomas wrote:
>> On 12/10/2022 2:31 AM, Tom Lendacky wrote:
>>> On 12/6/22 06:30, Rijo Thomas wrote:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
>>>
>>> This worries me a bit... if psp_init() fails, it may still be referenced
>>> as the master device. What's the reason for moving it?
>>
>> Hmm. Okay, I see your point.
>>
>> In psp_tee_alloc_dmabuf(), we call psp_get_master_device(). Without above
>> change, psp_get_master_device() returns NULL.
>>
>> I think in psp_dev_init(), we can add below error handling:
>>
>> ret = psp_init(psp);
>> if (ret)
>> goto e_init;
>> ...
>>
>> e_init:
>> if (sp->clear_psp_master_device)
>> sp->clear_psp_master_device(sp);
>>
>> Will this help address your concern?
>
> Yes, that works.
>
>>
>>>
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
>>>
>>> It looks like both calls to this use the same gfp_t values, you can
>>> probably eliminate from the call and just specify them in here.
>>>
>>
>> Okay, I will remove gfp_t flag from the function argument.
>>
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma,
gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
>>>
>>> I don't think you can have one of these be NULL without both being NULL,
>>> but I guess it doesn't hurt to check.
>>>
>>
>> Okay, we will keep both checks for now.
>>
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+ > + dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
>>>
>>> You need a nice comment above this all explaining that. I guess you're
>>> using the presence of a domain to determine whether you're running on
>>> bare-metal vs within a hypervisor? I'm not sure what will happen if the
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/12/22 05:21, Rijo Thomas wrote:
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
On 12/6/22 06:30, Rijo Thomas wrote:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
This worries me a bit... if psp_init() fails, it may still be referenced as
the master device. What's the reason for moving it?
Hmm. Okay, I see your point.
In psp_tee_alloc_dmabuf(), we call psp_get_master_device(). Without above
change, psp_get_master_device() returns NULL.
I think in psp_dev_init(), we can add below error handling:
ret = psp_init(psp);
if (ret)
goto e_init;
...
e_init:
if (sp->clear_psp_master_device)
sp->clear_psp_master_device(sp);
Will this help address your concern?
Yes, that works.
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
It looks like both calls to this use the same gfp_t values, you can probably
eliminate from the call and just specify them in here.
Okay, I will remove gfp_t flag from the function argument.
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
I don't think you can have one of these be NULL without both being NULL, but I
guess it doesn't hurt to check.
Okay, we will keep both checks for now.
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+ > + dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
You need a nice comment above this all explaining that. I guess you're using
the presence of a domain to determine whether you're running on bare-metal vs
within a hypervisor? I'm not sure what will happen if the guest ever gets an
emulated IOMMU...
Sure we will add a comment.
We are not trying to determive bare-metal vs hypervisor here, but determine
whether DMA handle returned by dma_alloc_coherent() is an IOVA or not.
If the address is an IOVA, we convert IOVA to physical address using
iommu_iova_to_phys(). This was our intention.
Ok, but if a VM gets an emulated IOMMU and ends up with an IOVA, that IOVA
points to a GPA - and if the size is over a page, then you aren't
guaranteed to have contiguous physical memory.
Probably not a concern at the moment, but not sure about what happens in
the future.
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
> On 12/6/22 06:30, Rijo Thomas wrote:
>> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
>> ring buffer address sent by host to ASP must be a real physical
>> address and the pages must be physically contiguous.
>>
>> In a virtualized environment though, when the driver is running in a
>> guest VM, the pages allocated by __get_free_pages() may not be
>> contiguous in the host (or machine) physical address space. Guests
>> will see a guest (or pseudo) physical address and not the actual host
>> (or machine) physical address. The TEE running on ASP cannot decipher
>> pseudo physical addresses. It needs host or machine physical address.
>>
>> To resolve this problem, use DMA APIs for allocating buffers that must
>> be shared with TEE. This will ensure that the pages are contiguous in
>> host (or machine) address space. If the DMA handle is an IOVA,
>> translate it into a physical address before sending it to ASP.
>>
>> This patch also exports two APIs (one for buffer allocation and
>> another to free the buffer). This API can be used by AMD-TEE driver to
>> share buffers with TEE.
>>
>> Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
>> Cc: Tom Lendacky
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Rijo Thomas
>> Co-developed-by: Jeshwanth
>> Signed-off-by: Jeshwanth
>> Reviewed-by: Devaraj Rangasamy
>> ---
>> drivers/crypto/ccp/psp-dev.c | 6 +-
>> drivers/crypto/ccp/tee-dev.c | 116 ++-
>> drivers/crypto/ccp/tee-dev.h | 9 +--
>> include/linux/psp-tee.h | 47 ++
>> 4 files changed, 127 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index c9c741ac8442..2b86158d7435 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
>> goto e_err;
>> }
>> + if (sp->set_psp_master_device)
>> + sp->set_psp_master_device(sp);
>> +
>
> This worries me a bit... if psp_init() fails, it may still be referenced as
> the master device. What's the reason for moving it?
Hmm. Okay, I see your point.
In psp_tee_alloc_dmabuf(), we call psp_get_master_device(). Without above
change, psp_get_master_device() returns NULL.
I think in psp_dev_init(), we can add below error handling:
ret = psp_init(psp);
if (ret)
goto e_init;
...
e_init:
if (sp->clear_psp_master_device)
sp->clear_psp_master_device(sp);
Will this help address your concern?
>
>> ret = psp_init(psp);
>> if (ret)
>> goto e_irq;
>> - if (sp->set_psp_master_device)
>> - sp->set_psp_master_device(sp);
>> -
>> /* Enable interrupt */
>> iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
>> diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
>> index 5c9d47f3be37..1631d9851e54 100644
>> --- a/drivers/crypto/ccp/tee-dev.c
>> +++ b/drivers/crypto/ccp/tee-dev.c
>> @@ -12,8 +12,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>> #include
>> #include "psp-dev.h"
>> @@ -21,25 +22,64 @@
>> static bool psp_dead;
>> +struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
>
> It looks like both calls to this use the same gfp_t values, you can probably
> eliminate from the call and just specify them in here.
>
Okay, I will remove gfp_t flag from the function argument.
>> +{
>> + struct psp_device *psp = psp_get_master_device();
>> + struct dma_buffer *dma_buf;
>> + struct iommu_domain *dom;
>> +
>> + if (!psp || !size)
>> + return NULL;
>> +
>> + dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
>> + if (!dma_buf)
>> + return NULL;
>> +
>> + dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
>> + if (!dma_buf->vaddr || !dma_buf->dma) {
>
> I don't think you can have one of these be NULL without both being NULL, but
> I guess it doesn't hurt to check.
>
Okay, we will keep both checks for now.
>> + kfree(dma_buf);
>> + return NULL;
>> + }
>> +
>> + dma_buf->size = size;
>> + > + dom = iommu_get_domain_for_dev(psp->dev);
>> + if (dom)
>
> You need a nice comment above this all explaining that. I guess you're using
> the presence of a domain to determine whether you're running on bare-metal vs
> within a hypervisor? I'm not sure what will happen if the guest ever gets an
> emulated IOMMU...
Sure we will add a comment.
We are not trying to determive bare-metal vs hypervisor here, but determine
whether DMA handle returned by dma_alloc_coherent() is an IOVA or not.
If the address is an IOVA, we convert IOVA to physical address using
iommu_iova_to_phys(). This was our intention.
>
>> + dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
>
> If
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/6/22 06:30, Rijo Thomas wrote:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
This worries me a bit... if psp_init() fails, it may still be referenced
as the master device. What's the reason for moving it?
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
It looks like both calls to this use the same gfp_t values, you can
probably eliminate from the call and just specify them in here.
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
I don't think you can have one of these be NULL without both being NULL,
but I guess it doesn't hurt to check.
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+ > +dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
You need a nice comment above this all explaining that. I guess you're
using the presence of a domain to determine whether you're running on
bare-metal vs within a hypervisor? I'm not sure what will happen if the
guest ever gets an emulated IOMMU...
+ dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
If you're just looking to get the physical address, why not just to an
__pa(dma_buf->vaddr)?
Also, paddr might not be the best name, since it isn't always a physical
address, but I can't really think of something right now.
Thanks,
Tom
+ else
+ dma_buf->paddr = dma_buf->dma;
+
+ return dma_buf;
+}
+EXPORT_SYMBOL(psp_tee_alloc_dmabuf);
+
+void psp_tee_free_dmabuf(struct dma_buffer *dma_buf)
+{
+ struct psp_device *psp = psp_get_master_device();
+
+ if (!psp || !dma_buf)
+ return;
+
+ dma_free_coherent(psp->dev, dma_buf->size,
+ dma_buf->vaddr, dma_buf->dma);
+
+ kfree(dma_buf);
+}
+EXPORT_SYMBOL(psp_tee_free_dmabuf);
+
static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size)
{
struct ring_buf_manager *rb_mgr = >rb_mgr;
- void *start_addr;
if (!ring_size)
return -EINVAL;
- /* We need actual physical address instead of DMA address, since
-* Trusted OS running on AMD Secure
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/6/2022 6:26 PM, Christian König wrote:
> Am 06.12.22 um 13:54 schrieb Rijo Thomas:
>>
>> On 12/6/2022 6:11 PM, Christian König wrote:
>>> Am 06.12.22 um 13:30 schrieb Rijo Thomas:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
>>> Maybe use some other name than dma_buffer for your structure, cause that is
>>> usually something completely different in the Linux kernel.
>>>
>> Sure Christian. I shall rename "struct dma_buffer" to "struct shm_buffer"
>> (Shared Memory Buffer) in the file include/linux/psp-tee.h
>> The functions psp_tee_alloc_dmabuf() and psp_tee_free_dmabuf() shall be
>> renamed to psp_tee_alloc_shmbuf() and psp_tee_free_shmbuf(), respectively.
>> I shall do correction in next patch revision. I will wait for others to
>> review as well before I post update.
>
> I strongly suggest to use the name psp_buffer or something similar because
> shm_buffer is usually used for something else as well.
I see that the TEE subsystem defines "struct tee_shm".
Okay, I will name the newly added structure as "struct psp_tee_buffer" and the
APIs as psp_tee_alloc_buffer() and psp_tee_free_buffer().
Complete function prototype:
struct psp_tee_buffer *psp_tee_alloc_buffer(unsigned long size, gfp_t gfp);
void psp_tee_free_buffer(struct psp_tee_buffer *buffer);
Does this look okay?
Thanks,
Rijo
>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Rijo
>>
>>> Regards,
>>> Christian.
>>>
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma,
gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+
+ dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
+ dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
Am 06.12.22 um 13:54 schrieb Rijo Thomas:
On 12/6/2022 6:11 PM, Christian König wrote:
Am 06.12.22 um 13:30 schrieb Rijo Thomas:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Maybe use some other name than dma_buffer for your structure, cause that is
usually something completely different in the Linux kernel.
Sure Christian. I shall rename "struct dma_buffer" to "struct shm_buffer"
(Shared Memory Buffer) in the file include/linux/psp-tee.h
The functions psp_tee_alloc_dmabuf() and psp_tee_free_dmabuf() shall be renamed
to psp_tee_alloc_shmbuf() and psp_tee_free_shmbuf(), respectively.
I shall do correction in next patch revision. I will wait for others to review
as well before I post update.
I strongly suggest to use the name psp_buffer or something similar
because shm_buffer is usually used for something else as well.
Regards,
Christian.
Thanks,
Rijo
Regards,
Christian.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+
+ dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
+ dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
+ else
+ dma_buf->paddr = dma_buf->dma;
+
+ return dma_buf;
+}
+EXPORT_SYMBOL(psp_tee_alloc_dmabuf);
+
+void psp_tee_free_dmabuf(struct dma_buffer *dma_buf)
+{
+ struct psp_device *psp = psp_get_master_device();
+
+ if (!psp || !dma_buf)
+ return;
+
+ dma_free_coherent(psp->dev, dma_buf->size,
+ dma_buf->vaddr, dma_buf->dma);
+
+ kfree(dma_buf);
+}
+EXPORT_SYMBOL(psp_tee_free_dmabuf);
+
static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size)
{
struct ring_buf_manager *rb_mgr = >rb_mgr;
- void *start_addr;
if (!ring_size)
return -EINVAL;
- /* We need actual physical address instead of DMA address, since
- * Trusted OS running on AMD Secure Processor will map this region
- */
- start_addr = (void *)__get_free_pages(GFP_KERNEL, get_order(ring_size));
- if (!start_addr)
+ rb_mgr->ring_buf = psp_tee_alloc_dmabuf(ring_size,
+
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/6/2022 6:11 PM, Christian König wrote:
> Am 06.12.22 um 13:30 schrieb Rijo Thomas:
>> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
>> ring buffer address sent by host to ASP must be a real physical
>> address and the pages must be physically contiguous.
>>
>> In a virtualized environment though, when the driver is running in a
>> guest VM, the pages allocated by __get_free_pages() may not be
>> contiguous in the host (or machine) physical address space. Guests
>> will see a guest (or pseudo) physical address and not the actual host
>> (or machine) physical address. The TEE running on ASP cannot decipher
>> pseudo physical addresses. It needs host or machine physical address.
>>
>> To resolve this problem, use DMA APIs for allocating buffers that must
>> be shared with TEE. This will ensure that the pages are contiguous in
>> host (or machine) address space. If the DMA handle is an IOVA,
>> translate it into a physical address before sending it to ASP.
>>
>> This patch also exports two APIs (one for buffer allocation and
>> another to free the buffer). This API can be used by AMD-TEE driver to
>> share buffers with TEE.
>
> Maybe use some other name than dma_buffer for your structure, cause that is
> usually something completely different in the Linux kernel.
>
Sure Christian. I shall rename "struct dma_buffer" to "struct shm_buffer"
(Shared Memory Buffer) in the file include/linux/psp-tee.h
The functions psp_tee_alloc_dmabuf() and psp_tee_free_dmabuf() shall be renamed
to psp_tee_alloc_shmbuf() and psp_tee_free_shmbuf(), respectively.
I shall do correction in next patch revision. I will wait for others to review
as well before I post update.
Thanks,
Rijo
> Regards,
> Christian.
>
>>
>> Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
>> Cc: Tom Lendacky
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Rijo Thomas
>> Co-developed-by: Jeshwanth
>> Signed-off-by: Jeshwanth
>> Reviewed-by: Devaraj Rangasamy
>> ---
>> drivers/crypto/ccp/psp-dev.c | 6 +-
>> drivers/crypto/ccp/tee-dev.c | 116 ++-
>> drivers/crypto/ccp/tee-dev.h | 9 +--
>> include/linux/psp-tee.h | 47 ++
>> 4 files changed, 127 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index c9c741ac8442..2b86158d7435 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
>> goto e_err;
>> }
>> + if (sp->set_psp_master_device)
>> + sp->set_psp_master_device(sp);
>> +
>> ret = psp_init(psp);
>> if (ret)
>> goto e_irq;
>> - if (sp->set_psp_master_device)
>> - sp->set_psp_master_device(sp);
>> -
>> /* Enable interrupt */
>> iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
>> diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
>> index 5c9d47f3be37..1631d9851e54 100644
>> --- a/drivers/crypto/ccp/tee-dev.c
>> +++ b/drivers/crypto/ccp/tee-dev.c
>> @@ -12,8 +12,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>> #include
>> #include "psp-dev.h"
>> @@ -21,25 +22,64 @@
>> static bool psp_dead;
>> +struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
>> +{
>> + struct psp_device *psp = psp_get_master_device();
>> + struct dma_buffer *dma_buf;
>> + struct iommu_domain *dom;
>> +
>> + if (!psp || !size)
>> + return NULL;
>> +
>> + dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
>> + if (!dma_buf)
>> + return NULL;
>> +
>> + dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
>> + if (!dma_buf->vaddr || !dma_buf->dma) {
>> + kfree(dma_buf);
>> + return NULL;
>> + }
>> +
>> + dma_buf->size = size;
>> +
>> + dom = iommu_get_domain_for_dev(psp->dev);
>> + if (dom)
>> + dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
>> + else
>> + dma_buf->paddr = dma_buf->dma;
>> +
>> + return dma_buf;
>> +}
>> +EXPORT_SYMBOL(psp_tee_alloc_dmabuf);
>> +
>> +void psp_tee_free_dmabuf(struct dma_buffer *dma_buf)
>> +{
>> + struct psp_device *psp = psp_get_master_device();
>> +
>> + if (!psp || !dma_buf)
>> + return;
>> +
>> + dma_free_coherent(psp->dev, dma_buf->size,
>> + dma_buf->vaddr, dma_buf->dma);
>> +
>> + kfree(dma_buf);
>> +}
>> +EXPORT_SYMBOL(psp_tee_free_dmabuf);
>> +
>> static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size)
>> {
>> struct ring_buf_manager *rb_mgr = >rb_mgr;
>> - void *start_addr;
>> if (!ring_size)
>> return -EINVAL;
>> - /* We need actual physical address instead of DMA address, since
>> - * Trusted OS running on AMD Secure Processor will map this region
>> - */
>> - start_addr = (void
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
Am 06.12.22 um 13:30 schrieb Rijo Thomas:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Maybe use some other name than dma_buffer for your structure, cause that
is usually something completely different in the Linux kernel.
Regards,
Christian.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+
+ dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
+ dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
+ else
+ dma_buf->paddr = dma_buf->dma;
+
+ return dma_buf;
+}
+EXPORT_SYMBOL(psp_tee_alloc_dmabuf);
+
+void psp_tee_free_dmabuf(struct dma_buffer *dma_buf)
+{
+ struct psp_device *psp = psp_get_master_device();
+
+ if (!psp || !dma_buf)
+ return;
+
+ dma_free_coherent(psp->dev, dma_buf->size,
+ dma_buf->vaddr, dma_buf->dma);
+
+ kfree(dma_buf);
+}
+EXPORT_SYMBOL(psp_tee_free_dmabuf);
+
static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size)
{
struct ring_buf_manager *rb_mgr = >rb_mgr;
- void *start_addr;
if (!ring_size)
return -EINVAL;
- /* We need actual physical address instead of DMA address, since
-* Trusted OS running on AMD Secure Processor will map this region
-*/
- start_addr = (void *)__get_free_pages(GFP_KERNEL, get_order(ring_size));
- if (!start_addr)
+ rb_mgr->ring_buf = psp_tee_alloc_dmabuf(ring_size,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!rb_mgr->ring_buf) {
+ dev_err(tee->dev, "ring allocation failed\n");
return -ENOMEM;
-
- memset(start_addr, 0x0, ring_size);
- rb_mgr->ring_start = start_addr;
- rb_mgr->ring_size = ring_size;
- rb_mgr->ring_pa = __psp_pa(start_addr);
+ }
mutex_init(_mgr->mutex);
return 0;
@@ -49,15 +89,8 @@ static void tee_free_ring(struct psp_tee_device *tee)
{
[PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+
+ dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
+ dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
+ else
+ dma_buf->paddr = dma_buf->dma;
+
+ return dma_buf;
+}
+EXPORT_SYMBOL(psp_tee_alloc_dmabuf);
+
+void psp_tee_free_dmabuf(struct dma_buffer *dma_buf)
+{
+ struct psp_device *psp = psp_get_master_device();
+
+ if (!psp || !dma_buf)
+ return;
+
+ dma_free_coherent(psp->dev, dma_buf->size,
+ dma_buf->vaddr, dma_buf->dma);
+
+ kfree(dma_buf);
+}
+EXPORT_SYMBOL(psp_tee_free_dmabuf);
+
static int tee_alloc_ring(struct psp_tee_device *tee, int ring_size)
{
struct ring_buf_manager *rb_mgr = >rb_mgr;
- void *start_addr;
if (!ring_size)
return -EINVAL;
- /* We need actual physical address instead of DMA address, since
-* Trusted OS running on AMD Secure Processor will map this region
-*/
- start_addr = (void *)__get_free_pages(GFP_KERNEL, get_order(ring_size));
- if (!start_addr)
+ rb_mgr->ring_buf = psp_tee_alloc_dmabuf(ring_size,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!rb_mgr->ring_buf) {
+ dev_err(tee->dev, "ring allocation failed\n");
return -ENOMEM;
-
- memset(start_addr, 0x0, ring_size);
- rb_mgr->ring_start = start_addr;
- rb_mgr->ring_size = ring_size;
- rb_mgr->ring_pa = __psp_pa(start_addr);
+ }
mutex_init(_mgr->mutex);
return 0;
@@ -49,15 +89,8 @@ static void tee_free_ring(struct psp_tee_device *tee)
{
struct ring_buf_manager *rb_mgr = >rb_mgr;
- if (!rb_mgr->ring_start)
- return;
+ psp_tee_free_dmabuf(rb_mgr->ring_buf);
- free_pages((unsigned long)rb_mgr->ring_start,
-
