All of lore.kernel.org
 help / color / mirror / Atom feed
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Julien Grall <julien.grall@arm.com>
Cc: "tee-dev@lists.linaro.org" <tee-dev@lists.linaro.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Volodymyr Babchuk <vlad.babchuk@gmail.com>
Subject: Re: [PATCH v4 03/10] xen/arm: optee: add OP-TEE mediator skeleton
Date: Fri, 15 Mar 2019 19:00:56 +0000	[thread overview]
Message-ID: <87y35g7yjc.fsf@epam.com> (raw)
In-Reply-To: <3d22a401-36d7-59f0-e928-7c9bd1778dae@arm.com>


Hello Julien,

Thank you for the review.

Julien Grall writes:

>> + */
>> +
>> +#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>
>> +
>> +#define OPTEE_ENABLED ((void*)0x1)
>
> Please don't do that. Introduce a dummy structure instead and fill it
> up when needed.
>

It will be removed in the patch #5. But probably yes, I can
create empty optee_domain structure in this patch.

>> +
>> +/* Client ID 0 is reserved for hypervisor itself */
>
> s/for/for the/
>
>> +#define OPTEE_CLIENT_ID(domain) ((domain)->domain_id + 1)
>> +
>> +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_domain_init(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.
>
> This does not really make sense to describe Linux here. Can't you just
> make the wording OS agnostic?
>
It was just as an example. But okay, I'll remove mention of Linux.


>> +     * Also, interrupts are disabled.
>> +     *
>> +     * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc()
>> +     */
>> +    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",
>
> gprintk will print the current vCPU and not the domain created. This
> is not very useful to know the current domain. So it would be better
> to use:
>
> printk(XENLOG_G_WARNING, "%pd: Unable to create OPTEE client: rc ...", d);
>
Good point, thank you.

>> +                (uint32_t)resp.a0);
>> +
>> +        return -ENODEV;
>> +    }
>> +
>> +    d->arch.tee = OPTEE_ENABLED;
>> +
>> +    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 int optee_relinquish_resources(struct domain *d)
>> +{
>> +    return 0;
>> +}
>> +
>> +static void optee_domain_destroy(struct domain *d)
>> +{
>> +    struct arm_smccc_res resp;
>> +
>> +    if ( !d->arch.tee )
>> +        return;
>> +
>> +    /*
>> +     * 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.
>> +     * At this time all domain VCPUs should be stopped. OP-TEE
>> +     * relies on this.
>> +     *
>> +     * a7 should be 0, so we can't skip last 6 parameters od arm_smccc_smc()
>
> NIT: s/od/of/
>
>> +     */
>> +    arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0,
>> +                  &resp);
>
> Your split between domain_destroy and relinquish_resources looks
> wrong. If you relinquish resources before telling OP-TEE then you are
> at risk that OP-TEE will use those resources.
>
> Instead you should first tell OP-TEE the domain is shutting down, then
> release the resources.

Both this calls are supposed to be called after all guest's VCPUs are
stopped, so OP-TEE will be not able to use any resources allocated to
the domain, because OP-TEE is schedule by the Normal World. I assume,
this is true for any other TEE.

[...]


-- 
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-03-15 19:01 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07 21:04 [PATCH v4 00/10] TEE mediator (and OP-TEE) support in XEN Volodymyr Babchuk
2019-03-07 21:04 ` [PATCH v4 01/10] xen/arm: add generic TEE mediator framework Volodymyr Babchuk
2019-03-15 15:03   ` Julien Grall
2019-03-07 21:04 ` [PATCH v4 04/10] xen/arm: optee: add fast calls handling Volodymyr Babchuk
2019-03-15 15:46   ` Julien Grall
2019-03-07 21:04 ` [PATCH v4 03/10] xen/arm: optee: add OP-TEE mediator skeleton Volodymyr Babchuk
2019-03-15 15:24   ` Julien Grall
2019-03-15 19:00     ` Volodymyr Babchuk [this message]
2019-03-15 20:18       ` Julien Grall
2019-03-15 15:47   ` Julien Grall
2019-03-07 21:04 ` [PATCH v4 02/10] xen/arm: optee: add OP-TEE header files Volodymyr Babchuk
2019-03-07 21:04 ` [PATCH v4 07/10] xen/arm: optee: add support for arbitrary shared memory Volodymyr Babchuk
2019-03-18 15:27   ` Julien Grall
2019-03-20 16:39     ` Volodymyr Babchuk
2019-03-20 17:47       ` Julien Grall
2019-03-20 19:37         ` Volodymyr Babchuk
2019-03-21 10:39           ` Julien Grall
2019-03-07 21:04 ` [PATCH v4 06/10] xen/arm: optee: add support for RPC SHM buffers Volodymyr Babchuk
2019-03-18 14:21   ` Julien Grall
2019-03-20 16:21     ` Volodymyr Babchuk
2019-03-20 16:52       ` Julien Grall
2019-03-20 17:09         ` Volodymyr Babchuk
2019-03-07 21:04 ` [PATCH v4 05/10] xen/arm: optee: add std call handling Volodymyr Babchuk
2019-03-18 13:50   ` Julien Grall
2019-03-20 16:14     ` Volodymyr Babchuk
2019-03-20 16:48       ` Julien Grall
2019-03-20 17:42         ` Volodymyr Babchuk
2019-03-20 18:08           ` Julien Grall
2019-03-07 21:04 ` [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg Volodymyr Babchuk
2019-03-18 15:49   ` Julien Grall
2019-03-18 21:04     ` Achin Gupta
2019-03-20 16:18       ` Julien Grall
2019-03-20 15:27     ` Volodymyr Babchuk
2019-03-20 16:06       ` Julien Grall
2019-03-20 17:01         ` Volodymyr Babchuk
2019-03-20 18:35           ` Julien Grall
2019-04-05 10:25             ` Volodymyr Babchuk
2019-04-05 10:25               ` [Xen-devel] " Volodymyr Babchuk
2019-04-08 10:47               ` Julien Grall
2019-04-08 10:47                 ` [Xen-devel] " Julien Grall
2019-03-07 21:04 ` [PATCH v4 08/10] xen/arm: optee: add support for RPC commands Volodymyr Babchuk
2019-03-18 15:38   ` Julien Grall
2019-03-20 15:36     ` Volodymyr Babchuk
2019-03-20 16:27       ` Julien Grall
2019-03-20 16:47         ` Volodymyr Babchuk
2019-03-07 21:04 ` [PATCH v4 10/10] tools/arm: optee: create optee firmware node in DT if tee=native Volodymyr Babchuk
2019-03-18 15:50   ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y35g7yjc.fsf@epam.com \
    --to=volodymyr_babchuk@epam.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=tee-dev@lists.linaro.org \
    --cc=vlad.babchuk@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.