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

[xen master] optee: allow plain TMEM buffers with NULL address



commit 0dbed3ad3366734fd23ee3fd1f9989c8c96b6052
Author:     Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
AuthorDate: Fri Jun 19 22:34:01 2020 +0000
Commit:     Stefano Stabellini <sstabellini@xxxxxxxxxx>
CommitDate: Wed Jul 1 10:15:07 2020 -0700

    optee: allow plain TMEM buffers with NULL address
    
    Trusted Applications use a popular approach to determine the required
    size of a buffer: the client provides a memory reference with the NULL
    pointer to a buffer. This is so called "Null memory reference". TA
    updates the reference with the required size and returns it back to the
    client. Then the client allocates a buffer of the needed size and
    repeats the operation.
    
    This behavior is described in TEE Client API Specification, paragraph
    3.2.5. Memory References.
    
    OP-TEE represents this null memory reference as a TMEM parameter with
    buf_ptr = 0x0. This is the only case when we should allow a TMEM
    buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the
    special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag.
    
    This could lead to a potential issue, because IPA 0x0 is a valid
    address, but OP-TEE will treat it as a special case. So, care should
    be taken when construction OP-TEE enabled guest to make sure that such
    guest have no memory at IPA 0x0 and none of its memory is mapped at PA
    0x0.
    
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
    Release-acked-by: Paul Durrant <paul@xxxxxxx>
---
 xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 780f37e527..8a39fe33b0 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -215,6 +215,15 @@ static bool optee_probe(void)
     return true;
 }
 
+/*
+ * TODO: There is a potential issue with guests that either have RAM
+ * at IPA of 0x0 or some of their memory is mapped at PA 0x0. This is
+ * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will
+ * not be able to map buffer with such pointer to TA address space, or
+ * use such buffer for communication with the guest. We either need to
+ * check that guest have no such mappings or ensure that OP-TEE
+ * enabled guest will not be created with such mappings.
+ */
 static int optee_domain_init(struct domain *d)
 {
     struct arm_smccc_res resp;
@@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain *ctx,
         uint64_t next_page_data;
     } *guest_data, *xen_data;
 
+    /*
+     * Special case: a buffer with buf_ptr == 0x0 is considered as a
+     * NULL pointer by OP-TEE. No translation is needed. This can lead
+     * to an issue as IPA 0x0 is a valid address for Xen. See the
+     * comment near optee_domain_init()
+     */
+    if ( !param->u.tmem.buf_ptr )
+        return 0;
+
     /* Offset of user buffer withing OPTEE_MSG_NONCONTIG_PAGE_SIZE-sized page 
*/
     offset = param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1);
 
@@ -865,9 +883,12 @@ static int translate_params(struct optee_domain *ctx,
             }
             else
             {
-                gdprintk(XENLOG_WARNING, "Guest tries to use old tmem arg\n");
-                ret = -EINVAL;
-                goto out;
+                if ( call->xen_arg->params[i].u.tmem.buf_ptr )
+                {
+                    gdprintk(XENLOG_WARNING, "Guest tries to use old tmem 
arg\n");
+                    ret = -EINVAL;
+                    goto out;
+                }
             }
             break;
         case OPTEE_MSG_ATTR_TYPE_NONE:
--
generated by git-patchbot for /home/xen/git/xen.git#master



 


Rackspace

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