Hello Julien,

Julien Grall writes:

Hi,

On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

This flag enables TEE support for a domain.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

xen/arch/arm/domain.c | 4 ++++ xen/arch/arm/domctl.c | 1 + xen/include/public/arch-arm.h | 3 +++ 3 files changed, 8 insertions(+) , diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 11b618515b..f04041931d 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -702,6 +702,10 @@ int arch_domain_create(struct domain *d, if ( (rc = domain_vtimer_init(d, &config->arch)) != 0 ) goto fail;

• if ( config->arch.tee_enabled )

•    if ( (rc = tee_enable(d)) != 0 )
  

This function does not yet exist. But I think it would make sense to fold this patch in the next one.

If you were talking about tee_enable(), then it was introduced in the previous patch.

Sure, I'll squash this patch into the previous one.

...

•        goto fail;
  

• update_domain_wallclock_time(d);
    /*
  

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index 20691528a6..f019e035e8 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -13,6 +13,7 @@ #include <xen/sched.h> #include <xen/types.h> #include <xsm/xsm.h> +#include <asm-arm/tee/tee.h> #include <public/domctl.h> void arch_get_domain_info(const struct domain *d, diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index eb424e8286..b7a010e99e 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -323,6 +323,9 @@ struct xen_arch_domainconfig { * */ uint32_t clock_frequency;

• /* IN */
• uint8_t tee_enabled;

Can you move this after gic_version? So we don't introduce more padding.

Sure.

...

}; #endif /* __XEN__ || __XEN_TOOLS__ */

Cheers,

-- Best regards,Volodymyr Babchuk

Hi Julien,

Julien Grall writes:

Hi Volodymyr,

On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

Add very basic OP-TEE mediator. It can probe for OP-TEE presence, tell it about domain creation/destruction and forward all known calls.

This is all what is needed for Dom0 to work with OP-TEE as long as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call OP-TEE from DomU will fail and can lead to spectacular results. Also, problems can arise if Dom0 uses pages mapped from other domains. So, this patch should not be merged without next patches in the series.

The last sentence is not necessary in the commit message. You can add it after "---". So it is stripped down when the patch is committed, yet we know it should not be merged :).

Oh, okay.

...

This code issues two non-preemptible calls to OP-TEE: to create and to destroy client context. They can't block in OP-TEE, but OP-TEE can wait on a splinlocks, so there is no maximal execution time guaranteed.

This paragraph is worrying. From the discussion we had on the previous version and some discussions at Linaro Connect with OP-TEE folks, I gathered this call should not take a long time.

Yes, this is right. It **should** not take a long time. And currently I can't see why it would take a long time anyways. But, you know, theoretically, there is no upper limit on waiting for spinlock.

In general spinlock should have no contention or wait should be limited. In particular, in the context of OP-TEE I would expect something is really wrong if you wait on a spinlock for a really long time as you block the normal world. So maybe this is just a misunderstanding of the commit message?

Yes, I think it is a misunderstanding. OP-TEE uses spinlocks in the same way as XEN or kernel - for short atomic operations. But as spinlock() function have no timeout argument, theoretically it would block for a long time.

I think, I'll remove that clause from the commit message. Just for clarity :)

...

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Fixed coding style
• Introduced tee/Kconfig
• Fixed error messages

xen/arch/arm/Kconfig | 2 + xen/arch/arm/tee/Kconfig | 4 + xen/arch/arm/tee/Makefile | 1 + xen/arch/arm/tee/optee.c | 151 ++++++++++++++++++++++++++++ xen/include/asm-arm/tee/optee_smc.h | 50 +++++++++ 5 files changed, 208 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/optee.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index e527b2f885..99e6f0ebb2 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -237,3 +237,5 @@ source "arch/arm/platforms/Kconfig" source "common/Kconfig"

source "drivers/Kconfig"

+source "arch/arm/tee/Kconfig" diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig new file mode 100644 index 0000000000..5b829db2e9 --- /dev/null +++ b/xen/arch/arm/tee/Kconfig @@ -0,0 +1,4 @@ +config OPTEE

• bool "Enable OP-TEE mediator"
• default n
• depends on TEE

diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile index c54d4796ff..982c879684 100644 --- a/xen/arch/arm/tee/Makefile +++ b/xen/arch/arm/tee/Makefile @@ -1 +1,2 @@ obj-y += tee.o +obj-$(CONFIG_OPTEE) += optee.o diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c new file mode 100644 index 0000000000..73ad25ee0b --- /dev/null +++ b/xen/arch/arm/tee/optee.c @@ -0,0 +1,151 @@ +/*

• • xen/arch/arm/tee/optee.c
• • OP-TEE mediator
• • Volodymyr Babchuk volodymyr_babchuk@epam.com
• • Copyright (c) 2018 EPAM Systems.
• • This program is free software; you can redistribute it and/or modify
• • it under the terms of the GNU General Public License version 2 as
• • published by the Free Software Foundation.
• */

+#include <xen/device_tree.h> +#include <xen/sched.h> +#include <asm/smccc.h> +#include <asm/tee/tee.h>

+#include <asm/tee/optee_msg.h> +#include <asm/tee/optee_smc.h>

+/* Client ID 0 is reserved for hypervisor itself */ +#define OPTEE_CLIENT_ID(domain) (domain->domain_id + 1)

The second 'domain' should be between () to avoid macro-expansion issue.

...

+static bool optee_probe(void) +{

• struct dt_device_node *node;
• struct arm_smccc_res resp;
• /* Check for entry in dtb */
• node = dt_find_compatible_node(NULL, NULL, "linaro,optee-tz");
• if ( !node )

•    return false;
  

• /* Check UID */
• arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp);
• if ( (uint32_t)resp.a0 != OPTEE_MSG_UID_0 ||

•     (uint32_t)resp.a1 != OPTEE_MSG_UID_1 ||
  

•     (uint32_t)resp.a2 != OPTEE_MSG_UID_2 ||
  

•     (uint32_t)resp.a3 != OPTEE_MSG_UID_3 )
  

•    return false;
  

• return true;

+}

+static int optee_enable(struct domain *d) +{

• struct arm_smccc_res resp;
• /*

• * Inform OP-TEE about a new guest.
  

• * This is a "Fast" call in terms of OP-TEE. This basically
  

• * means that it can't be preempted, because there is no
  

• * thread allocated for it in OP-TEE. It is close to atomic
  

• * context in linux kernel: E.g. no blocking calls can be issued.
  

• * Also, interrupts are disabled.
  

• * Right now OP-TEE just frees allocated memory, so it should be
  

• * really fast.
  

The last sentence looks wrong in this context.

...

• */
  

• arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0,

•              &resp);
  

• if ( resp.a0 != OPTEE_SMC_RETURN_OK )
• {

•    gprintk(XENLOG_WARNING, "Unable to create OPTEE client: rc = 0x%X\n",
  

•            (uint32_t)resp.a0);
  

•    return -ENODEV;
  

• }
• return 0;

+}

+static void forward_call(struct cpu_user_regs *regs) +{

• struct arm_smccc_res resp;
• arm_smccc_smc(get_user_reg(regs, 0),

•              get_user_reg(regs, 1),
  

•              get_user_reg(regs, 2),
  

•              get_user_reg(regs, 3),
  

•              get_user_reg(regs, 4),
  

•              get_user_reg(regs, 5),
  

•              get_user_reg(regs, 6),
  

•              OPTEE_CLIENT_ID(current->domain),
  

•              &resp);
  

• set_user_reg(regs, 0, resp.a0);
• set_user_reg(regs, 1, resp.a1);
• set_user_reg(regs, 2, resp.a2);
• set_user_reg(regs, 3, resp.a3);
• set_user_reg(regs, 4, 0);
• set_user_reg(regs, 5, 0);
• set_user_reg(regs, 6, 0);
• set_user_reg(regs, 7, 0);

+}

+static void optee_domain_destroy(struct domain *d) +{

• struct arm_smccc_res resp;
• /* At this time all domain VCPUs should be stopped */
• /*

• * Inform OP-TEE that domain is shutting down. This is
  

• * also a fast SMC call, like OPTEE_SMC_VM_CREATED, so
  

• * it is also non-preemptible.
  

• */
  

• arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0,

•              &resp);
  

+}

+static bool optee_handle_call(struct cpu_user_regs *regs) +{

• switch ( get_user_reg(regs, 0) )
• {
• case OPTEE_SMC_CALLS_COUNT:
• case OPTEE_SMC_CALLS_UID:
• case OPTEE_SMC_CALLS_REVISION:
• case OPTEE_SMC_CALL_GET_OS_UUID:
• case OPTEE_SMC_FUNCID_GET_OS_REVISION:
• case OPTEE_SMC_ENABLE_SHM_CACHE:
• case OPTEE_SMC_DISABLE_SHM_CACHE:
• case OPTEE_SMC_GET_SHM_CONFIG:
• case OPTEE_SMC_EXCHANGE_CAPABILITIES:
• case OPTEE_SMC_CALL_WITH_ARG:
• case OPTEE_SMC_CALL_RETURN_FROM_RPC:

•    forward_call(regs);
  

•    return true;
  

• default:

•    return false;
  

• }

+}

+static const struct tee_mediator_ops optee_ops = +{

• .probe = optee_probe,
• .enable = optee_enable,
• .domain_destroy = optee_domain_destroy,
• .handle_call = optee_handle_call,

+};

+REGISTER_TEE_MEDIATOR(optee, "OP-TEE", &optee_ops);

+/*

• • Local variables:
• • mode: C
• • c-file-style: "BSD"
• • c-basic-offset: 4
• • indent-tabs-mode: nil
• • End:
• */

diff --git a/xen/include/asm-arm/tee/optee_smc.h b/xen/include/asm-arm/tee/optee_smc.h index 26d100e215..1c5a2479e9 100644 --- a/xen/include/asm-arm/tee/optee_smc.h +++ b/xen/include/asm-arm/tee/optee_smc.h @@ -304,6 +304,56 @@ struct optee_smc_disable_shm_cache_result { #define OPTEE_SMC_ENABLE_SHM_CACHE \ OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE)

+/*

• • Inform OP-TEE about a new virtual machine
• • Hypervisor issues this call during virtual machine (guest) creation.
• • OP-TEE records VM_ID of new virtual machine and makes self ready
• • to receive requests from it.
• • Call requests usage:
• • a0 SMC Function ID, OPTEE_SMC_VM_CREATED
• • a1 VM_ID of newly created virtual machine
• • a2-6 Not used
• • a7 Hypervisor Client ID register. Must be 0, because only hypervisor

• •  can issue this call
    

• • Normal return register usage:
• • a0 OPTEE_SMC_RETURN_OK
• • a1-7 Preserved
• • Error return:
• • a0 OPTEE_SMC_RETURN_ENOTAVAIL OP-TEE has no resources for

• • 			another VM
    

• • a1-7 Preserved
• */

+#define OPTEE_SMC_FUNCID_VM_CREATED 13 +#define OPTEE_SMC_VM_CREATED \

• OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_VM_CREATED)

+/*

• • Inform OP-TEE about shutdown of a virtual machine
• • Hypervisor issues this call during virtual machine (guest) destruction.
• • OP-TEE will clean up all resources associated with this VM.
• • Call requests usage:
• • a0 SMC Function ID, OPTEE_SMC_VM_DESTROYED
• • a1 VM_ID of virtual machine being shutted down
• • a2-6 Not used
• • a7 Hypervisor Client ID register. Must be 0, because only hypervisor

• •  can issue this call
    

• • Normal return register usage:
• • a0 OPTEE_SMC_RETURN_OK
• • a1-7 Preserved
• */

+#define OPTEE_SMC_FUNCID_VM_DESTROYED 14 +#define OPTEE_SMC_VM_DESTROYED \

• OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_VM_DESTROYED)
• /*
  • Resume from RPC (for example after processing a foreign interrupt)

Cheers,

-- Best regards,Volodymyr Babchuk

Hello Julien,

Julien Grall writes:

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

The main way to communicate with OP-TEE is to issue standard SMCCC call. "Standard" is a SMCCC term and it means that call can be interrupted and OP-TEE can return control to NW before completing the call.

In contrast with fast calls, where arguments and return values are passed in registers, standard calls use shared memory. Register pair a1,a2 holds 64-bit PA of command buffer, where all arguments are stored and which is used to return data. OP-TEE internally copies contents of this buffer into own secure memory before accessing and validating any data in command buffer. This is done to make sure that NW will not change contents of the validated parameters.

Mediator needs to do the same for number of reasons:

1. To make sure that guest will not change data after validation.
2. To translate IPAs to PAs in the command buffer (this is not done in this patch).
3. To hide translated address from guest, so it will not be able to do IPA->PA translation by misusing mediator.

During standard call OP-TEE can issue multiple "RPC returns", asking NW to do some work for OP-TEE. NW then issues special call OPTEE_SMC_CALL_RETURN_FROM_RPC to resume handling of the original call. Thus, mediator needs to maintain context for original standard call during multiple SMCCC calls.

Standard call is considered complete, when returned value is not a RPC request.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• renamed struct domain_ctx to struct optee_domain
• fixed coding style
• Now I use access_guest_memory_by_ipa() instead of mappings to read command buffer
• Added tracking for in flight calls, so guest can't resume the same call from two CPUs simultaniously

xen/arch/arm/tee/optee.c | 319 ++++++++++++++++++++++++++++++++++- xen/include/asm-arm/domain.h | 3 + 2 files changed, 320 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 584241b03a..dc90e2ed8e 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -12,6 +12,8 @@ */ #include <xen/device_tree.h> +#include <xen/domain_page.h> +#include <xen/guest_access.h> #include <xen/sched.h> #include <asm/smccc.h> #include <asm/tee/tee.h> @@ -22,11 +24,38 @@ /* Client ID 0 is reserved for hypervisor itself */ #define OPTEE_CLIENT_ID(domain) (domain->domain_id + 1) +/*

• • Maximal number of concurrent standard calls from one guest. This
• • corresponds to OPTEE configuration option CFG_NUM_THREADS, because
• • OP-TEE spawns a thread for every standard call.

Looking at OP-TEE, CFG_NUM_THREADS will vary depending on the platform. Is there any way to probe that number of threads from Xen?

Yes, this is per-platform configuration. Easiest way is to add Fast SMC to OP-TEE that will report this parameter. Jens, what do you think about adding additional call?

In any case, I think we should update the comment to reflect that this seems to be the maximum CFG_NUM_THREADS supported by any upstream platform.

Actually, OP-TEE protocol have possibility to handle limited number of threads correctly. OP-TEE can report that all threads are busy and client will wait for a free one. XEN can do the same, although this is not implemented in this patch series. But I can add this.

Basically this means that all can work correctly even with MAX_STD_CALLS==1. It just will be not so efficient.

...

• */

+#define MAX_STD_CALLS 16

• #define OPTEE_KNOWN_NSEC_CAPS OPTEE_SMC_NSEC_CAP_UNIPROCESSOR #define OPTEE_KNOWN_SEC_CAPS (OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM | \ OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM | \ OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) +/*
• • Call context. OP-TEE can issue multiple RPC returns during one call.
• • We need to preserve context during them.
• */

+struct optee_std_call {

• struct list_head list;
• struct optee_msg_arg *xen_arg;
• paddr_t guest_arg_ipa;
• int optee_thread_id;
• int rpc_op;
• bool in_flight;

+};

+/* Domain context */ +struct optee_domain {

• struct list_head call_list;
• atomic_t call_count;
• spinlock_t lock;

+};

• static bool optee_probe(void) { struct dt_device_node *node;

@@ -52,6 +81,11 @@ static bool optee_probe(void) static int optee_enable(struct domain *d) { struct arm_smccc_res resp;

• struct optee_domain *ctx;
• ctx = xzalloc(struct optee_domain);
• if ( !ctx )

•    return -ENOMEM;
    /*
   * Inform OP-TEE about a new guest.
  

@@ -69,9 +103,16 @@ static int optee_enable(struct domain *d) { gprintk(XENLOG_WARNING, "Unable to create OPTEE client: rc = 0x%X\n", (uint32_t)resp.a0);

•    xfree(ctx);
      return -ENODEV;
  }
  

  • INIT_LIST_HEAD(&ctx->call_list);
• atomic_set(&ctx->call_count, 0);
• spin_lock_init(&ctx->lock);
• d->arch.tee = ctx;

• return 0;
  

  } @@ -111,9 +152,86 @@ static void set_return(struct cpu_user_regs

*regs, uint32_t ret) set_user_reg(regs, 7, 0); } +static struct optee_std_call *allocate_std_call(struct optee_domain *ctx) +{

• struct optee_std_call *call;
• int count;
• /* Make sure that guest does not execute more than MAX_STD_CALLS */
• count = atomic_add_unless(&ctx->call_count, 1, MAX_STD_CALLS);
• if ( count == MAX_STD_CALLS )

•    return NULL;
  

• call = xzalloc(struct optee_std_call);
• if ( !call )
• {

•    atomic_dec(&ctx->call_count);
  

•    return NULL;
  

• }
• call->optee_thread_id = -1;
• call->in_flight = true;
• spin_lock(&ctx->lock);
• list_add_tail(&call->list, &ctx->call_list);
• spin_unlock(&ctx->lock);
• return call;

+}

+static void free_std_call(struct optee_domain *ctx,

•                      struct optee_std_call *call)
  

+{

• atomic_dec(&ctx->call_count);
• spin_lock(&ctx->lock);
• list_del(&call->list);
• spin_unlock(&ctx->lock);
• ASSERT(!call->in_flight);
• xfree(call->xen_arg);
• xfree(call);

+}

+static struct optee_std_call *get_std_call(struct optee_domain *ctx,

•                                       int thread_id)
  

+{

• struct optee_std_call *call;
• spin_lock(&ctx->lock);
• list_for_each_entry( call, &ctx->call_list, list )
• {

•    if ( call->optee_thread_id == thread_id )
  

•    {
  

•        if ( call->in_flight )
  

•        {
  

•            gprintk(XENLOG_WARNING, "Guest tries to execute call which is already in flight");
  

•            goto out;
  

•        }
  

•        call->in_flight = true;
  

•        spin_unlock(&ctx->lock);
  

•        return call;
  

•    }
  

• }

+out:

• spin_unlock(&ctx->lock);
• return NULL;

+}

+static void put_std_call(struct optee_domain *ctx, struct optee_std_call *call) +{

• spin_lock(&ctx->lock);
• ASSERT(call->in_flight);
• call->in_flight = false;
• spin_unlock(&ctx->lock);

+}

• static void optee_domain_destroy(struct domain *d) { struct arm_smccc_res resp;

• struct optee_std_call *call, *call_tmp;

• struct optee_domain *ctx = d->arch.tee;

  /* At this time all domain VCPUs should be stopped */ @@ -124,6 +242,199 @@ static void optee_domain_destroy(struct

domain *d) */ arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0, &resp);

This function can be called without enable and should be idempotent. So I woudld check d->arch.tee before and...

Nothing bad will happen if it called without call to enable.

But yes, I need to check for ctx != NULL.

...

• ASSERT(!spin_is_locked(&ctx->lock));
• list_for_each_entry_safe( call, call_tmp, &ctx->call_list, list )

•    free_std_call(ctx, call);
  

• ASSERT(!atomic_read(&ctx->call_count));
• xfree(d->arch.tee);

use XFREE here.

Oh, looks like I missed this macro introduction. Thank you for pointing out.

...

+}

+/*

• • Copy command buffer into xen memory to:
• • 1. Hide translated addresses from guest
• • 2. Make sure that guest wouldn't change data in command buffer during call
• */

+static bool copy_std_request(struct cpu_user_regs *regs,

•                         struct optee_std_call *call)
  

+{

• paddr_t xen_addr;
• call->guest_arg_ipa = (paddr_t)get_user_reg(regs, 1) << 32 |

•                        get_user_reg(regs, 2);
  

NIT: The indentation looks weird here.

...

• /*

• * Command buffer should start at page boundary.
  

• * This is OP-TEE ABI requirement.
  

• */
  

• if ( call->guest_arg_ipa & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )

•    return false;
  

• call->xen_arg = _xmalloc(OPTEE_MSG_NONCONTIG_PAGE_SIZE,

•                         OPTEE_MSG_NONCONTIG_PAGE_SIZE);
  

• if ( !call->xen_arg )

•    return false;
  

• BUILD_BUG_ON(OPTEE_MSG_NONCONTIG_PAGE_SIZE > PAGE_SIZE);

As you use _xmalloc, you should not need this. This is only necessary if you use alloc_xenheap_page.

Yes, right. This is leftover from time when I mapped guest page into XEN. I'll move it down, to place where I map that page.

I am wondering whether it is wise to allocate the memory from xenheap and not domheap. While on Arm64 (for now) xenheap and domheap are the same, on Arm32 they are different. The xenheap is at most 1GB, so pretty limited.

Honestly, I have no opinion there. What are limitations of domheap in this case?

Furthermore, using domheap would have the advantage to allow in the future accounting the allocation to the guest and add more safety (there are discussion to make domheap per domain).

...

• access_guest_memory_by_ipa(current->domain, call->guest_arg_ipa,

•                           call->xen_arg, OPTEE_MSG_NONCONTIG_PAGE_SIZE,
  

•                           false);
  

You need to check the return of access_guest_memory_by_ipa as this function can fail.

Will do.

...

• xen_addr = virt_to_maddr(call->xen_arg);
• set_user_reg(regs, 1, xen_addr >> 32);
• set_user_reg(regs, 2, xen_addr & 0xFFFFFFFF);
• return true;

+}

+static void copy_std_request_back(struct optee_domain *ctx,

•                              struct cpu_user_regs *regs,
  

•                              struct optee_std_call *call)
  

Can you add a comment on top of the function explaining what it does?

Yes, sure.

"Copy OP-TEE response back into guest's request buffer" will be sufficient?

...

+{

• struct optee_msg_arg *guest_arg;
• struct page_info *page;
• unsigned int i;
• uint32_t attr;
• /* copy_std_request() validated IPA for us */

Not really, the guest is free to modify the stage-2 mapping on another vCPU while this is happening. I agree that the guest will shoot himself, but we at least need to not have weird behavior happening.

In that case, I would check that the type is p2m_ram_rw as you don't want to write in read-only or foreign mapping.

How I can do this atomically? I.e. what if guest will mangle p2m right after the check?

Also, as copy_std_request() and copy_std_request_back may not be called in the same "thread" it would be useful if you specify a bit more the interaction.

I not sure what do you mean there.

...

• page = get_page_from_gfn(current->domain, paddr_to_pfn(call->guest_arg_ipa),

Please use gfn_x(gaddr_to_gfn(...)) to clarify this is a gfn. The gfn_x will be unnecessary soon with a cleanup that is currently under review.

So there are chances, that it will be removed when time will come to merge this patch series? :)

...

•                         NULL, P2M_ALLOC);
  

• if ( !page )

•    return;
  

• guest_arg = map_domain_page(page_to_mfn(page));

So here you assume that PAGE_SIZE == OPTEE_MSG_NONCONTIG_PAGE_SIZE. Can you add a BUILD_BUG_ON just above (with a comment) so we don't get some nasty surprise with 64K support.

Yes, sure.

Also, you should be able to use __map_domain_page(page) here.

Oh, thank you for pointing to this macro. Not the best descriptive name, I must say.

...

• guest_arg->ret = call->xen_arg->ret;
• guest_arg->ret_origin = call->xen_arg->ret_origin;
• guest_arg->session = call->xen_arg->session;

NIT: newline here please.

...

• for ( i = 0; i < call->xen_arg->num_params; i++ )
• {

•    attr = call->xen_arg->params[i].attr;
  

•    switch ( attr & OPTEE_MSG_ATTR_TYPE_MASK )
  

•    {
  

•    case OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT:
  

•    case OPTEE_MSG_ATTR_TYPE_TMEM_INOUT:
  

•        guest_arg->params[i].u.tmem.size =
  

•            call->xen_arg->params[i].u.tmem.size;
  

•        continue;
  

•    case OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT:
  

•    case OPTEE_MSG_ATTR_TYPE_VALUE_INOUT:
  

•        guest_arg->params[i].u.value.a =
  

•            call->xen_arg->params[i].u.value.a;
  

•        guest_arg->params[i].u.value.b =
  

•            call->xen_arg->params[i].u.value.b;
  

•        continue;
  

•    case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT:
  

•    case OPTEE_MSG_ATTR_TYPE_RMEM_INOUT:
  

•        guest_arg->params[i].u.rmem.size =
  

•            call->xen_arg->params[i].u.rmem.size;
  

•        continue;
  

•    case OPTEE_MSG_ATTR_TYPE_NONE:
  

•    case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT:
  

•    case OPTEE_MSG_ATTR_TYPE_TMEM_INPUT:
  

•        continue;
  

•    }
  

• }
• unmap_domain_page(guest_arg);
• put_page(page);

+}

+static void execute_std_call(struct optee_domain *ctx,

•                         struct cpu_user_regs *regs,
  

•                         struct optee_std_call *call)
  

+{

• register_t optee_ret;
• forward_call(regs);
• optee_ret = get_user_reg(regs, 0);
• if ( OPTEE_SMC_RETURN_IS_RPC(optee_ret) )
• {

•    call->optee_thread_id = get_user_reg(regs, 3);
  

•    call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(optee_ret);
  

•    put_std_call(ctx, call);
  

•    return;
  

• }
• copy_std_request_back(ctx, regs, call);
• put_std_call(ctx, call);
• free_std_call(ctx, call);

+}

Most of the code in this patch is self-explaining, which is quite nice :). However, I think this function would require explaining a bit the logic. For instance in which case the call will be freed.

Thank you :) Yes, this depends on if call was completed or it was interrupted due to RPC, in which case it will be resumed later. I'll add comment.

...

+static bool handle_std_call(struct optee_domain *ctx,

•                        struct cpu_user_regs *regs)
  

+{

• struct optee_std_call *call = allocate_std_call(ctx);
• if ( !call )

•    return false;
  

• if ( !copy_std_request(regs, call) )

•    goto err;
  

• /* Now we can safely examine contents of command buffer */
• if ( OPTEE_MSG_GET_ARG_SIZE(call->xen_arg->num_params) >

•     OPTEE_MSG_NONCONTIG_PAGE_SIZE )
  

•    goto err;
  

• switch ( call->xen_arg->cmd )
• {
• case OPTEE_MSG_CMD_OPEN_SESSION:
• case OPTEE_MSG_CMD_CLOSE_SESSION:
• case OPTEE_MSG_CMD_INVOKE_COMMAND:
• case OPTEE_MSG_CMD_CANCEL:
• case OPTEE_MSG_CMD_REGISTER_SHM:
• case OPTEE_MSG_CMD_UNREGISTER_SHM:

•    break;
  

• default:

•    goto err;
  

• }
• execute_std_call(ctx, regs, call);
• return true;

This function is a bit odd to read. I think it would be more clear if you move this code before the break.

Yes, you are right.

...

+err:

• put_std_call(ctx, call);
• free_std_call(ctx, call);
• return false;

+}

+static bool handle_rpc(struct optee_domain *ctx, struct cpu_user_regs *regs) +{

• struct optee_std_call *call;
• int optee_thread_id = get_user_reg(regs, 3);
• call = get_std_call(ctx, optee_thread_id);
• if ( !call )

•    return false;
  

• switch ( call->rpc_op )
• {
• case OPTEE_SMC_RPC_FUNC_ALLOC:

•    /* TODO: Add handling */
  

•    break;
  

• case OPTEE_SMC_RPC_FUNC_FREE:

•    /* TODO: Add handling */
  

•    break;
  

• case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR:

•    break;
  

• case OPTEE_SMC_RPC_FUNC_CMD:

•    /* TODO: Add handling */
  

•    break;
  

• }
• execute_std_call(ctx, regs, call);
• return true; } static bool handle_exchange_capabilities(struct cpu_user_regs

*regs) @@ -161,6 +472,8 @@ static bool handle_exchange_capabilities(struct cpu_user_regs *regs) static bool optee_handle_call(struct cpu_user_regs *regs) {

• struct optee_domain *ctx = current->domain->arch.tee;

• switch ( get_user_reg(regs, 0) )
  {
  case OPTEE_SMC_CALLS_COUNT:
  

@@ -170,8 +483,6 @@ static bool optee_handle_call(struct cpu_user_regs *regs) case OPTEE_SMC_FUNCID_GET_OS_REVISION: case OPTEE_SMC_ENABLE_SHM_CACHE: case OPTEE_SMC_DISABLE_SHM_CACHE:

• case OPTEE_SMC_CALL_WITH_ARG:
• case OPTEE_SMC_CALL_RETURN_FROM_RPC: forward_call(regs); return true; case OPTEE_SMC_GET_SHM_CONFIG:

@@ -180,6 +491,10 @@ static bool optee_handle_call(struct cpu_user_regs *regs) return true; case OPTEE_SMC_EXCHANGE_CAPABILITIES: return handle_exchange_capabilities(regs);

• case OPTEE_SMC_CALL_WITH_ARG:

•    return handle_std_call(ctx, regs);
  

• case OPTEE_SMC_CALL_RETURN_FROM_RPC:

•    return handle_rpc(ctx, regs);
  default:
      return false;
  }
  

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index 175de44927..88b48697bd 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -97,6 +97,9 @@ struct arch_domain struct vpl011 vpl011; #endif +#ifdef CONFIG_TEE

• void *tee;

+#endif

Did you look whether there are any hole in arch_domain that could be re-used?

I thought about that. But what are chances to find 64bit-wide, 64bit-aligned hole in a structure? If I remember C standard correctly, there are no reasons for compiler to leave such holes.

I'm talking about aarch64 there, but I assume, that this is true for aarch32/armv7.

...

} __cacheline_aligned; struct arch_vcpu

Cheers,

-- Best regards,Volodymyr Babchuk

Hi Julien,

Julien Grall writes:

Hi Volodymyr,

On 17/01/2019 15:21, Volodymyr Babchuk wrote:

...

Julien Grall writes:

...

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

The main way to communicate with OP-TEE is to issue standard SMCCC call. "Standard" is a SMCCC term and it means that call can be interrupted and OP-TEE can return control to NW before completing the call.

In contrast with fast calls, where arguments and return values are passed in registers, standard calls use shared memory. Register pair a1,a2 holds 64-bit PA of command buffer, where all arguments are stored and which is used to return data. OP-TEE internally copies contents of this buffer into own secure memory before accessing and validating any data in command buffer. This is done to make sure that NW will not change contents of the validated parameters.

Mediator needs to do the same for number of reasons:

1. To make sure that guest will not change data after validation.
2. To translate IPAs to PAs in the command buffer (this is not done in this patch).
3. To hide translated address from guest, so it will not be able to do IPA->PA translation by misusing mediator.

During standard call OP-TEE can issue multiple "RPC returns", asking NW to do some work for OP-TEE. NW then issues special call OPTEE_SMC_CALL_RETURN_FROM_RPC to resume handling of the original call. Thus, mediator needs to maintain context for original standard call during multiple SMCCC calls.

Standard call is considered complete, when returned value is not a RPC request.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2: - renamed struct domain_ctx to struct optee_domain - fixed coding style - Now I use access_guest_memory_by_ipa() instead of mappings to read command buffer - Added tracking for in flight calls, so guest can't resume the same call from two CPUs simultaniously

xen/arch/arm/tee/optee.c | 319 ++++++++++++++++++++++++++++++++++- xen/include/asm-arm/domain.h | 3 + 2 files changed, 320 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 584241b03a..dc90e2ed8e 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -12,6 +12,8 @@ */ #include <xen/device_tree.h> +#include <xen/domain_page.h> +#include <xen/guest_access.h> #include <xen/sched.h> #include <asm/smccc.h> #include <asm/tee/tee.h> @@ -22,11 +24,38 @@ /* Client ID 0 is reserved for hypervisor itself */ #define OPTEE_CLIENT_ID(domain) (domain->domain_id + 1) +/*

• • Maximal number of concurrent standard calls from one guest. This
• • corresponds to OPTEE configuration option CFG_NUM_THREADS, because
• • OP-TEE spawns a thread for every standard call.

Looking at OP-TEE, CFG_NUM_THREADS will vary depending on the platform. Is there any way to probe that number of threads from Xen?

Yes, this is per-platform configuration. Easiest way is to add Fast SMC to OP-TEE that will report this parameter. Jens, what do you think about adding additional call?

...

In any case, I think we should update the comment to reflect that this seems to be the maximum CFG_NUM_THREADS supported by any upstream platform.

Actually, OP-TEE protocol have possibility to handle limited number of threads correctly. OP-TEE can report that all threads are busy and client will wait for a free one. XEN can do the same, although this is not implemented in this patch series. But I can add this.

Could you expand by wait? Will it block in OP-TEE/Xen or does it return to the guest?

It returns to the guest with response code OPTEE_SMC_RETURN_ETHREAD_LIMIT. Linux driver blocks calling application thread until one of the calls to OP-TEE is finished. Then driver awakens one of the blocked threads, so it can perform the call.

...

Basically this means that all can work correctly even with MAX_STD_CALLS==1. It just will be not so efficient.

Given the OS is not aware of the number of threads, The problem would be the same without Xen between. Am I right?

Exactly.

[...]

...

...

...

• /*

• * Command buffer should start at page boundary.
  

• * This is OP-TEE ABI requirement.
  

• */
  

• if ( call->guest_arg_ipa & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )

•    return false;
  

• call->xen_arg = _xmalloc(OPTEE_MSG_NONCONTIG_PAGE_SIZE,

•                         OPTEE_MSG_NONCONTIG_PAGE_SIZE);
  

• if ( !call->xen_arg )

•    return false;
  

• BUILD_BUG_ON(OPTEE_MSG_NONCONTIG_PAGE_SIZE > PAGE_SIZE);

As you use _xmalloc, you should not need this. This is only necessary if you use alloc_xenheap_page.

Yes, right. This is leftover from time when I mapped guest page into XEN. I'll move it down, to place where I map that page.

...

I am wondering whether it is wise to allocate the memory from xenheap and not domheap. While on Arm64 (for now) xenheap and domheap are the same, on Arm32 they are different. The xenheap is at most 1GB, so pretty limited.

Honestly, I have no opinion there. What are limitations of domheap in this case?

domheap pages may not always be mapped in Xen page-tables. So you have to call map_domain_page/unmap_domain_page at every use.

In practice, on Arm64, those operations are today a NOP because the memory is always mapped. On Arm32, domheap is never mapped so those operations will require to modify the page-tables.

There would be potentially ways to optimize the Arm32 case. So I think this is not a big concern as it would allow to account the memory to the domain and take advantage of potential new safety feature around domheap.

BTW, I am not asking to implement the accounting :). You can still allocate domheap memory without a domain assigned. I am only giving the advantages of using domheap over xenheap :).

Actually, I considered using domheap in the beginning. But for some reason I though that domheap is limited by a total memory assigned for a domain. Looks like I was mistaken. So yes, I'll used domheap for a large allocations.

[...]

...

...

...

+{

• struct optee_msg_arg *guest_arg;
• struct page_info *page;
• unsigned int i;
• uint32_t attr;
• /* copy_std_request() validated IPA for us */

Not really, the guest is free to modify the stage-2 mapping on another vCPU while this is happening. I agree that the guest will shoot himself, but we at least need to not have weird behavior happening.

In that case, I would check that the type is p2m_ram_rw as you don't want to write in read-only or foreign mapping.

How I can do this atomically? I.e. what if guest will mangle p2m right after the check?

What you want to prevent is Xen writing to the wrong page. The guest should not play with page that are shared with an higher exception level.

get_page_from_gfn() takes a reference on the current page, that will be release by put_page(). Between that you are sure the page can not disappear under your feet.

Ahhh, right. Thank you.

Furthermore, AFAIK, there are no way for an Arm guest to modify the p2m type of a page once inserted. It can only remove or replace with a newly allocated page the mapping. If the guest instructs to

• remove the page, as you have a reference that page will not disappear.
• replace the page with a new one, then the guest will not be

able to see the result. Tough luck, but it was not meant to do that :).

...

...

Also, as copy_std_request() and copy_std_request_back may not be called in the same "thread" it would be useful if you specify a bit more the interaction.

I not sure what do you mean there.

What I meant is the following can happen:

 guest vCPU A         |   Xen

 Initiate call 1
                     copy_std_request()
                          call OP-TEE
		-> Call "preempted"
                 	      return to guest
 Resume call 1
	      resume call in OP-TEE
	      copy_std_back_request()

Yes, this is right.

AFAICT, the call could even resume from a different vCPU.

This is also true.

It is not entirely trivial to understand this from just reading the code and the comment "copy_std_request() validated IPA for us" leads to think copy_std_request() was called right before. This may not be the case. So can you detail a bit more the interaction in the code?

Yes, there can be an issue. My previous approach pined guest page for a call duration, so I was sure that IPA is still valid. But now this is not true anymore. So yes, this comment is misleading. I'll fix both the code and the comment.

[...]

...

...

...

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index 175de44927..88b48697bd 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -97,6 +97,9 @@ struct arch_domain struct vpl011 vpl011; #endif +#ifdef CONFIG_TEE

• void *tee;

+#endif

Did you look whether there are any hole in arch_domain that could be re-used?

I thought about that. But what are chances to find 64bit-wide, 64bit-aligned hole in a structure? If I remember C standard correctly, there are no reasons for compiler to leave such holes.

It depends on the alignment requested for each structure. Have a look at pahole to see the number (and size) of holes we have in some structures ;).

Wow, 108 bytes hole in rcu_ctrlblk :) And yes, only two 8 byte holes in the whole xen.

-- Best regards, Volodymyr Babchuk

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

From: Volodymyr Babchuk vlad.babchuk@gmail.com

Shared memory is widely used by NW to communicate with TAs in OP-TEE. NW can share part of own memory with TA or OP-TEE core, by registering it OP-TEE, or by providing a temporal reference. Anyways, information about such memory buffers are sent to OP-TEE as a list of pages. This mechanism is described in optee_msg.h.

Mediator should step in when NW tries to share memory with OP-TEE for two reasons:

1. Do address translation from IPA to PA.
2. Pin domain pages till they are mapped into OP-TEE or TA

Looking at the code, I think the page are mapped while OP-TEE is using them. If so, it should be s/till/while/.

address space, so domain can't transfer this pages to
other domain or balloon out them. >

Address translation is done by translate_noncontig(...) function. It allocates new buffer from xenheap and then walks on guest provided list of pages, translates addresses and stores PAs into newly allocated buffer. This buffer will be provided to OP-TEE instead of original buffer from the guest. This buffer will be free at the end of standard call.

In the same time this function pins pages and stores them in struct optee_shm_buf object. This object will live all the time, when given SHM buffer is known to OP-TEE. It will be freed after guest unregisters shared buffer. At this time pages will be unpinned.

We don't need to do any special reference counting because OP-TEE tracks buffer on its side. So, mediator will unpin pages only when OP-TEE returns successfully from OPTEE_MSG_CMD_UNREGISTER_SHM call.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Made sure that guest does not tries to register shared buffer with the same cookie twice
• Fixed coding style
• Use access_guest_memory_by_ipa() instead of direct memory mapping

xen/arch/arm/tee/optee.c | 274 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 274 insertions(+)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 771148e940..cfc3b34df7 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -37,6 +37,10 @@ */ #define MAX_RPC_SHMS MAX_STD_CALLS +/* Maximum total number of pages that guest can share with OP-TEE */ +#define MAX_TOTAL_SMH_BUF_PG 16384

Please explain in the commit message and code how you came up to this value.

+#define MAX_NONCONTIG_ENTRIES 5

If I understand correctly the code below, MAX_NONCONTIG_ENTIRES is basically linked to the number of parameters. The maximum number of parameters is 5.

I see in patch #6 you check have the following check

OPTEE_MSG_GET_ARG_SIZE(num_params) > OPTEE_MSG_NONCONTIG_PAGE_SIZE

It is not entirely obvious how this ensure you have no more than 5 parameters neither how you came up to this value. Can you please at least provide more documentation in the code explaining the origin of the value?

You might also want a

BUILD_BUG_ON(OPTEE_MSG_GET_ARG_SIZE(MAX_NONCONTIG_ENTRIES) == OPTEE_MSG_NONCONTIG_PAGE_SIZE).

• #define OPTEE_KNOWN_NSEC_CAPS OPTEE_SMC_NSEC_CAP_UNIPROCESSOR #define OPTEE_KNOWN_SEC_CAPS (OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM | \ OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM | \

@@ -50,6 +54,9 @@ struct optee_std_call { struct list_head list; struct optee_msg_arg *xen_arg; paddr_t guest_arg_ipa;

• /* Buffer for translated page addresses, shared with OP-TEE */
• void *non_contig[MAX_NONCONTIG_ENTRIES];
• int non_contig_order[MAX_NONCONTIG_ENTRIES]; int optee_thread_id; int rpc_op; bool in_flight;

@@ -63,12 +70,23 @@ struct shm_rpc { uint64_t cookie; }; +/* Shared memory buffer for arbitrary data */ +struct optee_shm_buf {

• struct list_head list;
• uint64_t cookie;
• unsigned int max_page_cnt;
• unsigned int page_cnt;

I am not convinced the two variables are useful. It actually adds more confusion because of the close naming.

Looking at the code, you add the page contiguously in the array. So I think page_cnt could easily be replaced by checking whether pages[N] is NULL .

• struct page_info *pages[];

+};

• /* Domain context */ struct optee_domain { struct list_head call_list; struct list_head shm_rpc_list;
• struct list_head optee_shm_buf_list; atomic_t call_count; atomic_t shm_rpc_count;
• atomic_t optee_shm_buf_pages; spinlock_t lock; };

@@ -125,9 +143,11 @@ static int optee_enable(struct domain *d) INIT_LIST_HEAD(&ctx->call_list); INIT_LIST_HEAD(&ctx->shm_rpc_list);

• INIT_LIST_HEAD(&ctx->optee_shm_buf_list);

atomic_set(&ctx->call_count, 0); atomic_set(&ctx->shm_rpc_count, 0);

• atomic_set(&ctx->optee_shm_buf_pages, 0);

spin_lock_init(&ctx->lock); @@ -325,12 +345,91 @@ static void free_shm_rpc(struct optee_domain *ctx, uint64_t cookie) xfree(shm_rpc); } +static struct optee_shm_buf *allocate_optee_shm_buf(struct optee_domain *ctx,

•                                                uint64_t cookie,
  

•                                                unsigned int pages_cnt)
  

+{

• struct optee_shm_buf *optee_shm_buf, *optee_shm_buf_tmp;
• while ( true )

I would prefer if we avoid while ( true ) and use

do { } while ( atomic...(...) != old)

• {

•    int old = atomic_read(&ctx->optee_shm_buf_pages);
  

•    int new = old + pages_cnt;
  

Newline here please.

•    if ( new >= MAX_TOTAL_SMH_BUF_PG )
  

•        return NULL;
  

The limitation is in number of page and quite high. What would prevent a guest to register shared memory page by page? If nothing, then I think you can end up to something interesting issue in Xen because of the growing list and memory used.

•    if ( likely(old == atomic_cmpxchg(&ctx->optee_shm_buf_pages,
  

•                                      old, new)) )
  

•        break;
  

• }
• optee_shm_buf = xzalloc_bytes(sizeof(struct optee_shm_buf) +

•                        pages_cnt * sizeof(struct page *));
  

Coding style: page_cnt should be aligned with sizeof.

• if ( !optee_shm_buf )

•    goto err;
  

• optee_shm_buf->cookie = cookie;
• optee_shm_buf->max_page_cnt = pages_cnt;
• spin_lock(&ctx->lock);
• /* Check if there is already SHM with the same cookie */
• list_for_each_entry( optee_shm_buf_tmp, &ctx->optee_shm_buf_list, list )
• {

•    if ( optee_shm_buf_tmp->cookie == cookie )
  

•    {
  

•        spin_unlock(&ctx->lock);
  

•        gprintk(XENLOG_WARNING, "Guest tries to use the same SHM buffer cookie");
  

I would use gdprintk(...) and add the cookie number for debug.

•        goto err;
  

•    }
  

• }
• list_add_tail(&optee_shm_buf->list, &ctx->optee_shm_buf_list);
• spin_unlock(&ctx->lock);
• return optee_shm_buf;

+err:

• atomic_sub(pages_cnt, &ctx->optee_shm_buf_pages);
• xfree(optee_shm_buf);
• return NULL;

+}

+static void free_optee_shm_buf(struct optee_domain *ctx, uint64_t cookie) +{

• struct optee_shm_buf *optee_shm_buf;
• bool found = false;
• spin_lock(&ctx->lock);
• list_for_each_entry( optee_shm_buf, &ctx->optee_shm_buf_list, list )
• {

•    if ( optee_shm_buf->cookie == cookie )
  

•    {
  

•        found = true;
  

•        list_del(&optee_shm_buf->list);
  

•        break;
  

•    }
  

• }
• spin_unlock(&ctx->lock);
• if ( !found )

•    return;
  

• for ( int i = 0; i < optee_shm_buf->page_cnt; i++ )

The variable should be declared at the beginning of the function. It should also be unsigned.

•    if ( optee_shm_buf->pages[i] )
  

•        put_page(optee_shm_buf->pages[i]);
  

• atomic_sub(optee_shm_buf->max_page_cnt, &ctx->optee_shm_buf_pages);
• xfree(optee_shm_buf);

+}

• static void optee_domain_destroy(struct domain *d) { struct arm_smccc_res resp; struct optee_std_call *call, *call_tmp; struct optee_domain *ctx = d->arch.tee; struct shm_rpc *shm_rpc, *shm_rpc_tmp;
• struct optee_shm_buf *optee_shm_buf, *optee_shm_buf_tmp;

/* At this time all domain VCPUs should be stopped */ @@ -349,12 +448,177 @@ static void optee_domain_destroy(struct domain *d) list_for_each_entry_safe( shm_rpc, shm_rpc_tmp, &ctx->shm_rpc_list, list ) free_shm_rpc(ctx, shm_rpc->cookie);

• list_for_each_entry_safe( optee_shm_buf, optee_shm_buf_tmp,

•                          &ctx->optee_shm_buf_list, list )
  

•    free_optee_shm_buf(ctx, optee_shm_buf->cookie);
  

• ASSERT(!atomic_read(&ctx->call_count));
  ASSERT(!atomic_read(&ctx->shm_rpc_count));
  

• ASSERT(!atomic_read(&ctx->optee_shm_buf_pages));

xfree(d->arch.tee); } +#define PAGELIST_ENTRIES_PER_PAGE \

• ((OPTEE_MSG_NONCONTIG_PAGE_SIZE / sizeof(u64)) - 1)

+static size_t get_pages_list_size(size_t num_entries) +{

• int pages = DIV_ROUND_UP(num_entries, PAGELIST_ENTRIES_PER_PAGE);
• return pages * OPTEE_MSG_NONCONTIG_PAGE_SIZE;

+}

+static bool translate_noncontig(struct optee_domain *ctx,

•                            struct optee_std_call *call,
  

•                            struct optee_msg_param *param,
  

•                            int idx)
  

The parameter idx should be unsigned int.

+{

• /*

• * Refer to OPTEE_MSG_ATTR_NONCONTIG description in optee_msg.h for details.
  

• */
  

• uint64_t size;
• unsigned int page_offset;
• unsigned int num_pages;
• unsigned int order;
• unsigned int entries_on_page = 0;
• paddr_t gaddr;

By the way you use this variable, I would prefer if you store a frame using gfn_t.

• struct page_info *guest_page;
• struct {

•    uint64_t pages_list[PAGELIST_ENTRIES_PER_PAGE];
  

•    uint64_t next_page_data;
  

• } *pages_data_guest, *pages_data_xen, *pages_data_xen_start;

The structure is the internal of OPTEE_MSG_ATTR_NONCONTIG, am I correct? If so, the comment at the beginning of the function should be on top of the structure with further clarification (i.e this is the layout of the memory).

• struct optee_shm_buf *optee_shm_buf;
• /* Offset of user buffer withing page */

NIT: s/withing/within/

• page_offset = param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1);
• /* Size of the user buffer in bytes */
• size = ROUNDUP(param->u.tmem.size + page_offset,

•               OPTEE_MSG_NONCONTIG_PAGE_SIZE);
  

• num_pages = DIV_ROUND_UP(size, OPTEE_MSG_NONCONTIG_PAGE_SIZE);
• order = get_order_from_bytes(get_pages_list_size(num_pages));
• pages_data_xen_start = alloc_xenheap_pages(order, 0);

By using alloc_xenheap_pages, you may end-up allocation more memory than necessary when the order is getting bigger. What is the bigger order you expect here?

[...]

/*

• Copy command buffer into xen memory to:
• 1. Hide translated addresses from guest

@@ -469,6 +733,14 @@ static void execute_std_call(struct optee_domain *ctx, copy_std_request_back(ctx, regs, call);

• /*

• * If guest successfully unregistered own shared memory,
  

• * then we can unpin it's pages
  

NIT: Missing full stop.

• */
  

• if ( call->xen_arg->cmd == OPTEE_MSG_CMD_UNREGISTER_SHM &&

•     call->xen_arg->ret == 0 )
  

•    free_optee_shm_buf(ctx, call->xen_arg->params[0].u.rmem.shm_ref);
  

• put_std_call(ctx, call);
  free_std_call(ctx, call);
  

  }

Cheers,

On 19/02/2019 15:59, Volodymyr Babchuk wrote:

Hello Julien,

Hi Volodymyr,

Julien Grall writes:

...

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

Shared memory is widely used by NW to communicate with TAs in OP-TEE. NW can share part of own memory with TA or OP-TEE core, by registering it OP-TEE, or by providing a temporal reference. Anyways, information about such memory buffers are sent to OP-TEE as a list of pages. This mechanism is described in optee_msg.h.

Mediator should step in when NW tries to share memory with OP-TEE for two reasons:

1. Do address translation from IPA to PA.
2. Pin domain pages till they are mapped into OP-TEE or TA

Looking at the code, I think the page are mapped while OP-TEE is using them. If so, it should be s/till/while/.

...

 address space, so domain can't transfer this pages to
 other domain or balloon out them. >

Address translation is done by translate_noncontig(...) function. It allocates new buffer from xenheap and then walks on guest provided list of pages, translates addresses and stores PAs into newly allocated buffer. This buffer will be provided to OP-TEE instead of original buffer from the guest. This buffer will be free at the end of standard call.

In the same time this function pins pages and stores them in struct optee_shm_buf object. This object will live all the time, when given SHM buffer is known to OP-TEE. It will be freed after guest unregisters shared buffer. At this time pages will be unpinned.

We don't need to do any special reference counting because OP-TEE tracks buffer on its side. So, mediator will unpin pages only when OP-TEE returns successfully from OPTEE_MSG_CMD_UNREGISTER_SHM call.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Made sure that guest does not tries to register shared buffer with the same cookie twice
• Fixed coding style
• Use access_guest_memory_by_ipa() instead of direct memory mapping

xen/arch/arm/tee/optee.c | 274 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 274 insertions(+)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 771148e940..cfc3b34df7 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -37,6 +37,10 @@ */ #define MAX_RPC_SHMS MAX_STD_CALLS +/* Maximum total number of pages that guest can share with OP-TEE */ +#define MAX_TOTAL_SMH_BUF_PG 16384

Please explain in the commit message and code how you came up to this value.

Basically it is taken from head. I just needed some number. You see, number of registered shared memory buffer solely depends on free heap in OP-TEE. But the same heap is used for other purposes, so it is hard to tell how much pages can be shared with OP-TEE. I assumed that 64M ought to be enough for anybody.

Such explanation would be fine for me in the commit message and the code. The goal is to log how we came up with the value (even if it is random). This would help us if we need to refine the value in the future.

Probably it is worth to make this configurable via domctl interface.

It is not strictly necessary for now. We can refine it in the future if needed.

[...]

...

...

• page_offset = param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1);
• /* Size of the user buffer in bytes */
• size = ROUNDUP(param->u.tmem.size + page_offset,

•               OPTEE_MSG_NONCONTIG_PAGE_SIZE);
  

• num_pages = DIV_ROUND_UP(size, OPTEE_MSG_NONCONTIG_PAGE_SIZE);
• order = get_order_from_bytes(get_pages_list_size(num_pages));
• pages_data_xen_start = alloc_xenheap_pages(order, 0);

By using alloc_xenheap_pages, you may end-up allocation more memory than necessary when the order is getting bigger. What is the bigger order you expect here?

It depend on MAX_TOTAL_SMH_BUF_PG. One page can contain up to 511 entries, plus reference to the next one. So, basically at max I will need about 32 pages, which gives order 5-6. I think, I can try xzalloc or domheap there. But looks like there is no xmem_pool for the domheap. So, I still will be forced to use alloc_domheap_pages().

xmem_pool is not used when you allocate buffer larger than PAGE_SIZE. Instead, xmalloc will allocate an order bigger than free unused page (see xmalloc_whole_pages).

It is not overly critical to allocate more for now, but it would be nice to add it as a TODO in the code.

Cheers,

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

From: Volodymyr Babchuk vlad.babchuk@gmail.com

OP-TEE can issue multiple RPC requests. We are interested mostly in request that asks NW to allocate/free shared memory for OP-TEE needs, because mediator need to do address translation in the same

NIT: the mediator needs

way as it was done for shared buffers registered by NW.

As mediator now accesses shared command buffer, we need to shadow it in the same way, as we shadow request buffers for STD calls.

This is a bit confusing, does it means patch #8 is not doing the right thing?

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Use access_guest_memory_by_ipa() instead of direct mapping

xen/arch/arm/tee/optee.c | 136 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 130 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index cfc3b34df7..bf3535946d 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -67,6 +67,8 @@ struct optee_std_call { struct shm_rpc { struct list_head list; struct page_info *guest_page;

• struct optee_msg_arg *xen_arg;
• paddr_t guest_ipa; uint64_t cookie; };

@@ -290,6 +292,11 @@ static struct shm_rpc *allocate_and_pin_shm_rpc(struct optee_domain *ctx, P2M_ALLOC); if ( !shm_rpc->guest_page ) goto err;

• shm_rpc->guest_ipa = gaddr;
• shm_rpc->xen_arg = alloc_xenheap_page();

Based on the discussion in patch #6, I think you want to use to allocate the memory from domheap.

• if ( !shm_rpc->xen_arg )

•    goto err;
  

shm_rpc->cookie = cookie; @@ -313,6 +320,7 @@ static struct shm_rpc *allocate_and_pin_shm_rpc(struct optee_domain *ctx, err: atomic_dec(&ctx->shm_rpc_count); put_page(shm_rpc->guest_page);

• free_xenheap_page(shm_rpc->xen_arg); xfree(shm_rpc);

return NULL; @@ -339,12 +347,32 @@ static void free_shm_rpc(struct optee_domain *ctx, uint64_t cookie) if ( !found ) return;

• free_xenheap_page(shm_rpc->xen_arg);

• ASSERT(shm_rpc->guest_page);
  put_page(shm_rpc->guest_page);
  

xfree(shm_rpc); } +static struct shm_rpc *find_shm_rpc(struct optee_domain *ctx, uint64_t cookie) +{

• struct shm_rpc *shm_rpc;
• spin_lock(&ctx->lock);
• list_for_each_entry( shm_rpc, &ctx->shm_rpc_list, list )
• {

•    if ( shm_rpc->cookie == cookie )
  

•    {
  

•            spin_unlock(&ctx->lock);
  

•            return shm_rpc;
  

•    }
  

• }
• spin_unlock(&ctx->lock);
• return NULL;

+}

• static struct optee_shm_buf *allocate_optee_shm_buf(struct optee_domain *ctx, uint64_t cookie, unsigned int pages_cnt)

@@ -712,6 +740,33 @@ static void copy_std_request_back(struct optee_domain *ctx, put_page(page); } +static void handle_rpc_return(struct optee_domain *ctx,

•                         struct cpu_user_regs *regs,
  

•                         struct optee_std_call *call)
  

+{

• call->rpc_params[0] = get_user_reg(regs, 1);
• call->rpc_params[1] = get_user_reg(regs, 2);
• call->optee_thread_id = get_user_reg(regs, 3);
• call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(get_user_reg(regs, 0));
• if ( call->rpc_op == OPTEE_SMC_RPC_FUNC_CMD )
• {

•    /* Copy RPC request from shadowed buffer to guest */
  

•    uint64_t cookie = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
  

I am afraid this is not going to work correctly. get_user_reg return a 64-bit value, so if the top bit are non-zero then the cookie value will actually be wrong. It is not clear to me whether the bits [63:32] should be 0, so the best is to ignore them.

Given you use similar construction in a few places in the code, I would introduce a new helper that take 2 register indexes and return the 64-bit value.

•    struct shm_rpc *shm_rpc = find_shm_rpc(ctx, cookie);
  

Newline here please.

•    if ( !shm_rpc )
  

•    {
  

•        gprintk(XENLOG_ERR, "Can't find SHM-RPC with cookie %lx\n", cookie);
  

•        return;
  

•    }
  

•    access_guest_memory_by_ipa(current->domain,
  

•                    shm_rpc->guest_ipa,
  

•                    shm_rpc->xen_arg,
  

•                    OPTEE_MSG_GET_ARG_SIZE(shm_rpc->xen_arg->num_params),
  

•                    true);
  

• }

+}

• static void execute_std_call(struct optee_domain *ctx, struct cpu_user_regs *regs, struct optee_std_call *call)

@@ -723,10 +778,7 @@ static void execute_std_call(struct optee_domain *ctx, optee_ret = get_user_reg(regs, 0); if ( OPTEE_SMC_RETURN_IS_RPC(optee_ret) ) {

•    call->rpc_params[0] = get_user_reg(regs, 1);
  

•    call->rpc_params[1] = get_user_reg(regs, 2);
  

•    call->optee_thread_id = get_user_reg(regs, 3);
  

•    call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(optee_ret);
  

•    handle_rpc_return(ctx, regs, call);
  

Please avoid code movement and introduce the function in the patch that was adding this code.

      put_std_call(ctx, call);
      return;
  }

@@ -787,6 +839,78 @@ err: return false; } +static void handle_rpc_cmd_alloc(struct optee_domain *ctx,

•                             struct cpu_user_regs *regs,
  

•                             struct optee_std_call *call,
  

•                             struct shm_rpc *shm_rpc)
  

+{

• if ( shm_rpc->xen_arg->params[0].attr != (OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT |

•                                        OPTEE_MSG_ATTR_NONCONTIG) )
  

• {

•    gprintk(XENLOG_WARNING, "Invalid attrs for shared mem buffer\n");
  

I would use gdprintk here and print the attributes to help the developer.

•    return;
  

• }
• /* Last entry in non_contig array is used to hold RPC-allocated buffer */
• if ( call->non_contig[MAX_NONCONTIG_ENTRIES - 1] )
• {

•    free_xenheap_pages(call->non_contig[MAX_NONCONTIG_ENTRIES - 1],
  

•                       call->non_contig_order[MAX_NONCONTIG_ENTRIES - 1]);
  

•    call->non_contig[MAX_NONCONTIG_ENTRIES - 1] = NULL;
  

• }
• translate_noncontig(ctx, call, shm_rpc->xen_arg->params + 0,

•                    MAX_NONCONTIG_ENTRIES - 1);
  

+}

+static void handle_rpc_cmd(struct optee_domain *ctx, struct cpu_user_regs *regs,

•                       struct optee_std_call *call)
  

+{

• struct shm_rpc *shm_rpc;
• uint64_t cookie;
• size_t arg_size;
• cookie = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);

See above.

• shm_rpc = find_shm_rpc(ctx, cookie);
• if ( !shm_rpc )
• {

•    gprintk(XENLOG_ERR, "Can't find SHM-RPC with cookie %lx\n", cookie);
  

•    return;
  

• }
• /* First, copy only header to read number of arguments */
• access_guest_memory_by_ipa(current->domain, shm_rpc->guest_ipa,

•                           shm_rpc->xen_arg, sizeof(struct optee_msg_arg),
  

•                           false);
  

This can return an error.

• arg_size = OPTEE_MSG_GET_ARG_SIZE(shm_rpc->xen_arg->num_params);
• if ( arg_size > OPTEE_MSG_NONCONTIG_PAGE_SIZE )

•    return;
  

• /* Read the whole command structure */
• access_guest_memory_by_ipa(current->domain, shm_rpc->guest_ipa,

•                           shm_rpc->xen_arg, arg_size, false);
  

Ditto.

• switch (shm_rpc->xen_arg->cmd)
• {
• case OPTEE_MSG_RPC_CMD_GET_TIME:

•    break;
  

• case OPTEE_MSG_RPC_CMD_WAIT_QUEUE:

•    break;
  

• case OPTEE_MSG_RPC_CMD_SUSPEND:

•    break;
  

• case OPTEE_MSG_RPC_CMD_SHM_ALLOC:

•    handle_rpc_cmd_alloc(ctx, regs, call, shm_rpc);
  

•    break;
  

• case OPTEE_MSG_RPC_CMD_SHM_FREE:

•    free_optee_shm_buf(ctx, shm_rpc->xen_arg->params[0].u.value.b);
  

•    break;
  

• default:

•    break;
  

• }

+}

• static void handle_rpc_func_alloc(struct optee_domain *ctx, struct cpu_user_regs *regs) {

@@ -807,7 +931,7 @@ static void handle_rpc_func_alloc(struct optee_domain *ctx, ptr = 0; } else

•        ptr = page_to_maddr(shm_rpc->guest_page);
  

•        ptr = virt_to_maddr(shm_rpc->xen_arg);
  

set_user_reg(regs, 1, ptr >> 32); set_user_reg(regs, 2, ptr & 0xFFFFFFFF); @@ -839,7 +963,7 @@ static bool handle_rpc(struct optee_domain *ctx, struct cpu_user_regs *regs) case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR: break; case OPTEE_SMC_RPC_FUNC_CMD:

•    /* TODO: Add handling */
  

•    handle_rpc_cmd(ctx, regs, call);
      break;
  }
  

Cheers,

Hi,

On 19/02/2019 16:14, Volodymyr Babchuk wrote:

Hi Julien,

Julien Grall writes:

...

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

OP-TEE can issue multiple RPC requests. We are interested mostly in request that asks NW to allocate/free shared memory for OP-TEE needs, because mediator need to do address translation in the same

NIT: the mediator needs

...

way as it was done for shared buffers registered by NW.

As mediator now accesses shared command buffer, we need to shadow it in the same way, as we shadow request buffers for STD calls.

This is a bit confusing, does it means patch #8 is not doing the right thing?

No, it was patch #6 :)

And I can't say that it did something wrong. Remember that prior to the last patch in series DomU can't use the mediator. And for Dom0 it is okay to map RPC command buffer directly. Description of patch #4 mentions that we need all patches in the series for a complete mediator.

Not all the memory in Dom0 is 1:1 mapped. So you may end up to use the wrong address here.

But, it is not very intuitive to have to read the commit message of patch #4 to understand that patch #8 is fixing a flaw in patch #6.

Technically, earlier patch should not have allowed to use shared command buffer until now. While I appreciate it is hard to split big series, we at least need to write clear commit message. In that case "now accesses" clear lead to think something wrong has been done before. So a reminder in the commit message would help the reviewer here.

...

...

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Use access_guest_memory_by_ipa() instead of direct mapping

xen/arch/arm/tee/optee.c | 136 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 130 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index cfc3b34df7..bf3535946d 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -67,6 +67,8 @@ struct optee_std_call { struct shm_rpc { struct list_head list; struct page_info *guest_page;

• struct optee_msg_arg *xen_arg;
• paddr_t guest_ipa; uint64_t cookie; }; @@ -290,6 +292,11 @@ static struct shm_rpc

*allocate_and_pin_shm_rpc(struct optee_domain *ctx, P2M_ALLOC); if ( !shm_rpc->guest_page ) goto err;

• shm_rpc->guest_ipa = gaddr;
• shm_rpc->xen_arg = alloc_xenheap_page();

Based on the discussion in patch #6, I think you want to use to allocate the memory from domheap.

Yes, will do. I already did it for #6 and now there is a lots of places where I am mapping/unmapping that page. So, it is somewhat inconvenient...

Well, security is always inconvenient until we found a flaw ;).

Cheers,

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

From: Volodymyr Babchuk vlad.babchuk@gmail.com

OP-TEE usually uses the same idea with command buffers (see previous commit) to issue RPC requests. Problem is that initially it has no buffer, where it can write request. So the first RPC request it makes is special: it requests NW to allocate shared buffer for other RPC requests. Usually this buffer is allocated only once for every OP-TEE thread and it remains allocated all the time until shutdown.

By shutdown you mean for the OS or the thread?

Mediator needs to pin this buffer(s) to make sure that domain can't transfer it to someone else.

Life cycle of this buffer is controlled by OP-TEE. It asks guest to create buffer and it asks it to free it.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2:

• Added check to ensure that guests does not return two SHM buffers with the same cookie
• Fixed coding style
• Storing RPC parameters during RPC return to make sure, that guest will not change them during call continuation

xen/arch/arm/tee/optee.c | 140 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 138 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index dc90e2ed8e..771148e940 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -30,6 +30,12 @@

• OP-TEE spawns a thread for every standard call.

*/ #define MAX_STD_CALLS 16 +/*

• • Maximal number of pre-allocated SHM buffers. OP-TEE generally asks
• • for one SHM buffer per thread, so this also corresponds to OP-TEE
• • option CFG_NUM_THREADS
• */

Same as patch #6 regarding CFG_NUM_THREADS.

NIT: Missing full stop

+#define MAX_RPC_SHMS MAX_STD_CALLS #define OPTEE_KNOWN_NSEC_CAPS OPTEE_SMC_NSEC_CAP_UNIPROCESSOR #define OPTEE_KNOWN_SEC_CAPS (OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM | \ @@ -47,12 +53,22 @@ struct optee_std_call { int optee_thread_id; int rpc_op; bool in_flight;

• register_t rpc_params[2];

+};

+/* Pre-allocated SHM buffer for RPC commands */ +struct shm_rpc {

• struct list_head list;
• struct page_info *guest_page;
• uint64_t cookie; };

/* Domain context */ struct optee_domain { struct list_head call_list;

• struct list_head shm_rpc_list; atomic_t call_count;
• atomic_t shm_rpc_count; spinlock_t lock; };

@@ -108,7 +124,11 @@ static int optee_enable(struct domain *d) } INIT_LIST_HEAD(&ctx->call_list);

• INIT_LIST_HEAD(&ctx->shm_rpc_list);

• atomic_set(&ctx->call_count, 0);
  

• atomic_set(&ctx->shm_rpc_count, 0);

• spin_lock_init(&ctx->lock);
  

d->arch.tee = ctx; @@ -227,11 +247,90 @@ static void put_std_call(struct optee_domain *ctx, struct optee_std_call *call) spin_unlock(&ctx->lock); } +static struct shm_rpc *allocate_and_pin_shm_rpc(struct optee_domain *ctx,

•                                            paddr_t gaddr,
  

As I said on v3, I would prefer if you use gfn_t here. This would introduce more safety.

•                                            uint64_t cookie)
  

+{

• struct shm_rpc *shm_rpc, *shm_rpc_tmp;
• int count;
• /* Make sure that guest does not allocate more than MAX_RPC_SHMS */

NIT: Missing full stop.

• count = atomic_add_unless(&ctx->shm_rpc_count, 1, MAX_RPC_SHMS);
• if ( count == MAX_RPC_SHMS )

•    return NULL;
  

• shm_rpc = xzalloc(struct shm_rpc);
• if ( !shm_rpc )

•    goto err;
  

• /* This page will be shared with OP-TEE, so we need to pin it */

Ditto.

• shm_rpc->guest_page = get_page_from_gfn(current->domain,

•                                        paddr_to_pfn(gaddr),
  

•                                        NULL,
  

•                                        P2M_ALLOC);
  

I think it would be wrong to share any page other than p2m_ram_rw with OP-TEE.

• if ( !shm_rpc->guest_page )

•    goto err;
  

• shm_rpc->cookie = cookie;
• spin_lock(&ctx->lock);
• /* Check if there is already SHM with the same cookie */

"already a SHM"

NIT: Missing full stop.

• list_for_each_entry( shm_rpc_tmp, &ctx->shm_rpc_list, list )
• {

•    if ( shm_rpc_tmp->cookie == cookie )
  

•    {
  

•        spin_unlock(&ctx->lock);
  

•        gprintk(XENLOG_WARNING, "Guest tries to use the same RPC SHM cookie");
  

I would use gdprintk(...) and add the cookie number for debug.

•        goto err;
  

•    }
  

• }
• list_add_tail(&shm_rpc->list, &ctx->shm_rpc_list);
• spin_unlock(&ctx->lock);
• return shm_rpc;

+err:

• atomic_dec(&ctx->shm_rpc_count);
• put_page(shm_rpc->guest_page);
• xfree(shm_rpc);
• return NULL;

+}

+static void free_shm_rpc(struct optee_domain *ctx, uint64_t cookie) +{

• struct shm_rpc *shm_rpc;
• bool found = false;
• spin_lock(&ctx->lock);
• list_for_each_entry( shm_rpc, &ctx->shm_rpc_list, list )
• {

•    if ( shm_rpc->cookie == cookie )
  

•    {
  

•        found = true;
  

•        list_del(&shm_rpc->list);
  

•        break;
  

•    }
  

• }
• spin_unlock(&ctx->lock);

I think you are missing an atomic_dec(&ctx->shm_rpc_count) here.

• if ( !found )

•    return;
  

• ASSERT(shm_rpc->guest_page);
• put_page(shm_rpc->guest_page);
• xfree(shm_rpc);

+}

• static void optee_domain_destroy(struct domain *d) { struct arm_smccc_res resp; struct optee_std_call *call, *call_tmp; struct optee_domain *ctx = d->arch.tee;
• struct shm_rpc *shm_rpc, *shm_rpc_tmp;

/* At this time all domain VCPUs should be stopped */ @@ -247,7 +346,11 @@ static void optee_domain_destroy(struct domain *d) list_for_each_entry_safe( call, call_tmp, &ctx->call_list, list ) free_std_call(ctx, call);

• list_for_each_entry_safe( shm_rpc, shm_rpc_tmp, &ctx->shm_rpc_list, list )

•    free_shm_rpc(ctx, shm_rpc->cookie);
  

• ASSERT(!atomic_read(&ctx->call_count));
  

• ASSERT(!atomic_read(&ctx->shm_rpc_count));

xfree(d->arch.tee); } @@ -356,6 +459,8 @@ static void execute_std_call(struct optee_domain *ctx, optee_ret = get_user_reg(regs, 0); if ( OPTEE_SMC_RETURN_IS_RPC(optee_ret) ) {

•    call->rpc_params[0] = get_user_reg(regs, 1);
  

•    call->rpc_params[1] = get_user_reg(regs, 2);
      call->optee_thread_id = get_user_reg(regs, 3);
      call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(optee_ret);
      put_std_call(ctx, call);
  

@@ -408,6 +513,33 @@ err: return false; } +static void handle_rpc_func_alloc(struct optee_domain *ctx,

•                              struct cpu_user_regs *regs)
  

+{

• paddr_t ptr = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
• if ( ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )

•    gprintk(XENLOG_WARNING, "Domain returned invalid RPC command buffer\n");
  

Should not you bail-out in that case? Also, I would turn it to a gdprintk.

• if ( ptr )
• {

•    uint64_t cookie = get_user_reg(regs, 4) << 32 | get_user_reg(regs, 5);
  

•    struct shm_rpc *shm_rpc;
  

•    shm_rpc = allocate_and_pin_shm_rpc(ctx, ptr, cookie);
  

•    if ( !shm_rpc )
  

•    {
  

•        gprintk(XENLOG_WARNING, "Failed to allocate shm_rpc object\n");
  

•        ptr = 0;
  

•    }
  

•    else
  

•        ptr = page_to_maddr(shm_rpc->guest_page);
  

•    set_user_reg(regs, 1, ptr >> 32);
  

•    set_user_reg(regs, 2, ptr & 0xFFFFFFFF);
  

• }

+}

• static bool handle_rpc(struct optee_domain *ctx, struct cpu_user_regs *regs) { struct optee_std_call *call;

@@ -421,11 +553,15 @@ static bool handle_rpc(struct optee_domain *ctx, struct cpu_user_regs *regs) switch ( call->rpc_op ) { case OPTEE_SMC_RPC_FUNC_ALLOC:

•    /* TODO: Add handling */
  

•    handle_rpc_func_alloc(ctx, regs);
      break;
  case OPTEE_SMC_RPC_FUNC_FREE:
  

•    /* TODO: Add handling */
  

• {

•    uint64_t cookie = call->rpc_params[0] << 32 |
  

•                        (uint32_t)call->rpc_params[1];
  

The indentation looks weird here.

•    free_shm_rpc(ctx, cookie);
      break;
  

• } case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR: break; case OPTEE_SMC_RPC_FUNC_CMD:

Cheers,

HI,

On 1/17/19 7:48 PM, Volodymyr Babchuk wrote:

Julien Grall writes:

...

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

OP-TEE usually uses the same idea with command buffers (see previous commit) to issue RPC requests. Problem is that initially it has no buffer, where it can write request. So the first RPC request it makes is special: it requests NW to allocate shared buffer for other RPC requests. Usually this buffer is allocated only once for every OP-TEE thread and it remains allocated all the time until shutdown.

By shutdown you mean for the OS or the thread?

Shutdown of OP-TEE actually. But guest can ask OP-TEE to de-allocate this buffers. And this is what linux drivers does when it unloads. So, basically, linux drivers says "I want to disable RPC buffer caching" and then OP-TEE issues number of RPCs to free those buffers.

...

...

Mediator needs to pin this buffer(s) to make sure that domain can't transfer it to someone else.

Life cycle of this buffer is controlled by OP-TEE. It asks guest to create buffer and it asks it to free it.

Signed-off-by: Volodymyr Babchuk vlad.babchuk@gmail.com

Changes from v2: - Added check to ensure that guests does not return two SHM buffers with the same cookie - Fixed coding style - Storing RPC parameters during RPC return to make sure, that guest will not change them during call continuation xen/arch/arm/tee/optee.c | 140 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 138 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index dc90e2ed8e..771148e940 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -30,6 +30,12 @@ * OP-TEE spawns a thread for every standard call. */ #define MAX_STD_CALLS 16 +/*

• • Maximal number of pre-allocated SHM buffers. OP-TEE generally asks
• • for one SHM buffer per thread, so this also corresponds to OP-TEE
• • option CFG_NUM_THREADS
• */

Same as patch #6 regarding CFG_NUM_THREADS.

Right now OP-TEE will not allocate more than one buffer per OP-TEE thread. And I can see no reason why it would change. So, basically I can remove this MAX_RPC_SHMS at all and use MAX_STD_CALLS instead. But then it will be not so obvious, why I compare number of SHM buffers with number of std calls. Thus, I think it is good to have separate define and comment.

I am not against have the 2 defines, what I was pointed out with the documentation on top is incorrect as patch #6.

If you happen to make MAX_STD_CALLS dynamic, then this should also be dynamic.

[...]

...

...

@@ -227,11 +247,90 @@ static void put_std_call(struct optee_domain *ctx, struct optee_std_call *call) spin_unlock(&ctx->lock); } +static struct shm_rpc *allocate_and_pin_shm_rpc(struct optee_domain *ctx,

•                                            paddr_t gaddr,
  

As I said on v3, I would prefer if you use gfn_t here. This would introduce more safety.

Sure, will do.

[...]

...

...

• shm_rpc->guest_page = get_page_from_gfn(current->domain,

•                                        paddr_to_pfn(gaddr),
  

•                                        NULL,
  

•                                        P2M_ALLOC);
  

I think it would be wrong to share any page other than p2m_ram_rw with OP-TEE.

So it should be like this:

 shm_rpc->guest_page = get_page_from_gfn(current->domain,
                                         paddr_to_pfn(gaddr),
                                         &p2m,
                                         P2M_ALLOC);
 if ( !shm_rpc->guest_page || p2m != p2m_ram_rw)
     goto err;

?

Sounds good to me.

[...]

...

...

+static void free_shm_rpc(struct optee_domain *ctx, uint64_t cookie) +{

• struct shm_rpc *shm_rpc;
• bool found = false;
• spin_lock(&ctx->lock);
• list_for_each_entry( shm_rpc, &ctx->shm_rpc_list, list )
• {

•    if ( shm_rpc->cookie == cookie )
  

•    {
  

•        found = true;
  

•        list_del(&shm_rpc->list);
  

•        break;
  

•    }
  

• }
• spin_unlock(&ctx->lock);

I think you are missing an atomic_dec(&ctx->shm_rpc_count) here.

Good catch. Thank you.

[...]

...

...

+static void handle_rpc_func_alloc(struct optee_domain *ctx,

•                              struct cpu_user_regs *regs)
  

+{

• paddr_t ptr = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
• if ( ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )

•    gprintk(XENLOG_WARNING, "Domain returned invalid RPC command buffer\n");
  

Should not you bail-out in that case? Also, I would turn it to a gdprintk.

OP-TEE does own checks and that check will fail also. Then OP-TEE will issue request to free this SHM.

I think it is better if we go on the safe-side. I.e if we know there would be an error (like here), then you need to return an error in from Xen rather than calling OP-TEE. Otherwise, you may end up to nasty problem.

Also, I think you want a comment (maybe in the commit message) explaining that OPTEE_MSG_NONCONTIG_PAGE_SIZE will always be equal to PAGE_SIZE.

But you have a point. I need to rework error path there.

[...]

...

...

   case OPTEE_SMC_RPC_FUNC_FREE:

•    /* TODO: Add handling */
  

• {

•    uint64_t cookie = call->rpc_params[0] << 32 |
  

•                        (uint32_t)call->rpc_params[1];
  

The indentation looks weird here.

You are right. How it should look? Would this be okay?

     uint64_t cookie = call->rpc_params[0] << 32 |
             (uint32_t)call->rpc_params[1];

call and (uint32_t) should be aligned:

uint64_t cookie = call->rcp... | (uint32_t)call..

Cheers,

On 17/01/2019 21:01, Volodymyr Babchuk wrote:

Hi,

Hi Volodymyr,

Julien Grall writes:

...

HI,

On 1/17/19 7:48 PM, Volodymyr Babchuk wrote:

...

Julien Grall writes:

...

Hi Volodymyr,

On 18/12/2018 21:11, Volodymyr Babchuk wrote:

...

From: Volodymyr Babchuk vlad.babchuk@gmail.com

[...]

...

...

...

...

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index dc90e2ed8e..771148e940 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -30,6 +30,12 @@ * OP-TEE spawns a thread for every standard call. */ #define MAX_STD_CALLS 16 +/*

• • Maximal number of pre-allocated SHM buffers. OP-TEE generally asks
• • for one SHM buffer per thread, so this also corresponds to OP-TEE
• • option CFG_NUM_THREADS
• */

Same as patch #6 regarding CFG_NUM_THREADS.

Right now OP-TEE will not allocate more than one buffer per OP-TEE thread. And I can see no reason why it would change. So, basically I can remove this MAX_RPC_SHMS at all and use MAX_STD_CALLS instead. But then it will be not so obvious, why I compare number of SHM buffers with number of std calls. Thus, I think it is good to have separate define and comment.

I am not against have the 2 defines, what I was pointed out with the documentation on top is incorrect as patch #6.

I'm sorry, I don't quite understand. In patch #6 your concern was that CFG_NUM_THREADS depends on platform, right?

My first concern was the documentation does not reflect the reality because CFG_NUM_THREADS is not always equal to 16.

Ideally we should be able to know the number of threads supported. But that could be a follow-up patch (or potentially ignored) if nothing bad can happen when Xen handles more thread than OP-TEE does.

In any case, the documentation in Xen should reflect the reality.

...

If you happen to make MAX_STD_CALLS dynamic, then this should also be dynamic.

Of course.

[...]

...

...

...

...

+static void handle_rpc_func_alloc(struct optee_domain *ctx,

•                              struct cpu_user_regs *regs)
  

+{

• paddr_t ptr = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
• if ( ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )

•    gprintk(XENLOG_WARNING, "Domain returned invalid RPC command buffer\n");
  

Should not you bail-out in that case? Also, I would turn it to a gdprintk.

OP-TEE does own checks and that check will fail also. Then OP-TEE will issue request to free this SHM.

I think it is better if we go on the safe-side. I.e if we know there would be an error (like here), then you need to return an error in from Xen rather than calling OP-TEE. Otherwise, you may end up to nasty problem.

Actually, I don't see how I can do this. This is an RPC response. I can't return error to RPC response. All I can do is to mangle RPC response in a such way, that OP-TEE surely will treat it as an error and act accordingly.

I am not sure to understand what you mean here. Surely if the address is not aligned, then OP-TEE will return an error too, right? So can't you emulate OP-TEE behavior in that case?

...

Also, I think you want a comment (maybe in the commit message) explaining that OPTEE_MSG_NONCONTIG_PAGE_SIZE will always be equal to PAGE_SIZE.

It is always equal to 4096 bytes. But, AFAIK, XEN can work with other PAGE_SIZEs, isn't? Actually, linux driver support other page sizes, it just splits those pages into 4k chunks. The same can be done in XEN, but I don't want to introduce this logic right now. The patches are complex enough. Right now we have BUILD_BUG_ON(PAGE_SIZE != OPTEE_MSG_NONCONTIG_PAGE_SIZE) and this is enough, I hope.

Xen only support 4KB page, but I wouldn't bet that in the future on Arm as we will require 64KB page for some features (i.e 52-bit support).

I wasn't asking you to handle a different PAGE_SIZE, just to clarify in a comment on top that you expect the both defined to be valid. Another BUILD_BUG_ON is not necessary assuming you add the one in patch #6.

Cheers,