[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reg. Tee init fail...



On Thu, Jun 30, 2022 at 07:31:38AM +0200, Juergen Gross wrote:
> On 30.06.22 05:32, SK, SivaSangeetha (Siva Sangeetha) wrote:
> > [AMD Official Use Only - General]
> > 
> > +team
> > 
> > -----Original Message-----
> > From: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Sent: Thursday, June 30, 2022 1:34 AM
> > To: Julien Grall <julien@xxxxxxx>
> > Cc: SK, SivaSangeetha (Siva Sangeetha) <SivaSangeetha.SK@xxxxxxx>; 
> > xen-devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini 
> > <sstabellini@xxxxxxxxxx>; Bertrand Marquis <bertrand.marquis@xxxxxxx>; 
> > Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>; jgross@xxxxxxxx; 
> > boris.ostrovsky@xxxxxxxxxx
> > Subject: Re: Reg. Tee init fail...
> > 
> > Adding Juergen and Boris because this is a Linux/x86 issue.
> > 
> > 
> > As you can see from this Linux driver:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fcrypto%2Fccp%2Ftee-dev.c%23L132&amp;data=05%7C01%7CSivaSangeetha.SK%40amd.com%7Ce962a907794f4917a80b08da5a0a7b3b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637921298315828104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=NxmMUckiDRGLv3qLJrhZKBt2zNTuomEZqYJdV74tXxA%3D&amp;reserved=0
> > 
> > Linux as dom0 on x86 is trying to communicate with firmware (TEE). Linux is 
> > calling __pa to pass a physical address to firmware. However, __pa returns 
> > a "fake" address not an mfn. I imagine that a quick workaround would be to 
> > call "virt_to_machine" instead of "__pa" in tee-dev.c.
> > 
> > Normally, if this was a device, the "right fix" would be to use 
> > swiotlb-xen:xen_swiotlb_map_page to get back a real physical address.
> > 
> > However, xen_swiotlb_map_page is meant to be used as part of the dma_ops 
> > API and takes a struct device *dev as input parameter. Maybe 
> > xen_swiotlb_map_page can be used for tee-dev as well?
> > 
> > 
> > Basically tee-dev would need to call dma_map_page before passing addresses 
> > to firmware, and dma_unmap_page when it is done. E.g.:
> > 
> > 
> >    cmd_buffer = dma_map_page(dev, virt_to_page(cmd),
> >                              cmd & ~PAGE_MASK,
> >                              ring_size,
> >                              DMA_TO_DEVICE);
> > 
> > 
> > Juergen, Boris,
> > what do you think?
> 
> Yes, I think using the DMA interface is the correct way to handle that.
> 
> BTW, I did a similar fix for the dcdbas driver recently:
> 
> https://lore.kernel.org/r/20220318150950.16843-1-jgross@xxxxxxxx

I hit similar issue, and the patch below made it work for me (ugly
workaround), or at least stop complaining.

But note one of those places have this comment:

        /* We need actual physical address instead of DMA address, since
         * Trusted OS running on AMD Secure Processor will map this region
         */

I guess it means AMD Secure Processor bypasses IOMMU...

---8<---
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..9d440fc8a56d 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -15,6 +15,7 @@
 #include <linux/gfp.h>
 #include <linux/psp-sev.h>
 #include <linux/psp-tee.h>
+#include <xen/page.h>
 
 #include "psp-dev.h"
 #include "tee-dev.h"
@@ -39,7 +40,7 @@ static int tee_alloc_ring(struct psp_tee_device *tee, int 
ring_size)
        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);
+       rb_mgr->ring_pa = virt_to_machine(start_addr).maddr;
        mutex_init(&rb_mgr->mutex);
 
        return 0;
@@ -129,7 +130,7 @@ static int tee_init_ring(struct psp_tee_device *tee)
                return -ENOMEM;
        }
 
-       cmd_buffer = __psp_pa((void *)cmd);
+       cmd_buffer = virt_to_machine((void *)cmd).maddr;
 
        /* Send command buffer details to Trusted OS by writing to
         * CPU-PSP message registers




-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.