All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>,
	Devicetree List <devicetree@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jerome Forissier <jerome@forissier.org>,
	Etienne Carriere <etienne.carriere@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2 0/7] Asynchronous notifications from secure world
Date: Thu, 8 Jul 2021 18:26:30 +0530	[thread overview]
Message-ID: <CAFA6WYNF_GkRiqn+H5UO6O4ZEkZ16xO=JkV6LOvgvvaVqwFtxw@mail.gmail.com> (raw)
In-Reply-To: <20210707175123.xdotr3lsy3e32plm@bogus>

Hi Sudeep,

On Wed, 7 Jul 2021 at 23:22, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Hi Sumit,
>
> I was holding off you reply as I didn't have all the background on this.
> Achin did mention that this is preparatory work for FFA notifications.
> I did mention to him that this is more than that, it is custom extension
> to address what FF-A notification is trying to in standard way.
>
> I share same opinion as Marc Z.
>
> On Wed, Jul 07, 2021 at 11:22:23AM +0530, Sumit Garg wrote:
> > On Tue, 6 Jul 2021 at 18:16, Marc Zyngier <maz@kernel.org> wrote:
>
> [...]
>
> > >
> > > I don't care about OP-TEE. If you are proposing a contract between S
> > > and NS, it has to be TEE and OS independent. That's how the
> > > architecture works.
> > >
> >
> > Agree, here we are not proposing a common contract among the S and NS
> > world that every TEE (based on Arm TrustZone) will use to communicate
> > with REE (Linux in our case) but rather an OP-TEE specific
> > notifications feature that is built on top of OP-TEE specific ABIs.
> >
> > And I can see your arguments coming from an FFA perspective but there
> > are platforms like the ones based on Armv7 which don't support FFA
> > ABI. Maybe Jens can elaborate how this feature will fit in when FFA
> > comes into picture?
> >
>
> I can understand that but won't those platforms add the support both in
> the kernel(current series) and secure world to address notifications.

Agree.

> While you could argue that it is small extension to what is already present
> but I prefer they support FF-A is they need such a support instead of adding
> custom mechanisms. It is hard to maintain and each vendor will deviate
> from this custom mechanism and soon we will have bunch of them to handle.
>

I haven't had a deep dive into FF-A spec, maybe you can clarify on the
following queries regarding Armv7 compatibility:
- As you may be aware, secure monitor implementation on Armv7 is
tightly coupled to trusted OS (part of the same code base), so would
you like each trusted OS vendor to implement a common FF-A interface?
- IIRC, FF-A spec has the notion of multiple secure partitions, are
those supported on Armv7? If yes then how?

> > > > >
> > > > > In general, cross world SGIs are a really bad idea. Yes, some people
> > > > > like them. I still think they are misguided, and I don't intend to
> > > > > provide a generic request interface for this.
> > > >
> > > > Okay, as I mentioned above having it specific to OP-TEE driver
> > > > requesting secure world donated SGI would work for you?
> > >
> > > No. I want a proper architecture between secure and non-secure that
> > > explain how messages are conveyed between the two world, how
> > > signalling is done, how CPU PM is handled, how targeting is
> > > negotiated. And at the end of the day, this is starting to look a lot
> > > like FFA.
> >
> > AFAIK when FFA comes in picture than OP-TEE will use the standard
> > interface provided by FFA ABIs but if FFA isn't supported by a
> > particular platform (eg. based on Armv7) then we need to rely on TEE
> > specific ABI like what OP-TEE currently provides:
> >
>
> Who are asking for this ? Can we ask them to migrate to FF-A if this
> (new) notification support is needed on their platforms ? It is help to
> know the requesters so that they can be included in FF-A spec discussions.
>

I would let Jens answer that.

> > > that. You'll even get to keep the pieces once it breaks. But if you
> > > are going to invent a new universal way of signalling things across
> > > world, you'd better start specifying things the right way, taking into
> > > considerations systems where the interrupt controller doesn't allow
> > > cross-world signalling.
> >
> > As I mentioned above, this patch-set adds an OP-TEE specific
> > notifications feature. AFAIK, the interrupt controllers supported by
> > OP-TEE (GICv2, GICv3 etc.) don't restrict cross-world signaling.
> >
> > So given the explanation above, if you still think requesting an SGI
> > as an IRQ by drivers isn't allowed then I am fine with the approach
> > that Jens has already implemented in this patch-set to use platform
> > specific SPI.
> >
>
> And I assume these platforms in question have SPI to spare and way to
> trigger it from secure world ?
>

Yeah, that is the requirement on the platform if we rely on SPI (Qemu
test example [1]) which wouldn't be the case if we use secure world
donated SGI.

BTW, is this notification mechanism discussed in the case of FF-A? If
yes, can you throw some light on that?

[1] https://github.com/jenswi-linaro/optee_os/commit/9007f8184deb9b7995da8d590779cb3ba2783394

-Sumit

> --
> Regards,
> Sudeep

WARNING: multiple messages have this Message-ID
From: Sumit Garg <sumit.garg@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>,
	 Devicetree List <devicetree@vger.kernel.org>,
	 Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jerome Forissier <jerome@forissier.org>,
	 Etienne Carriere <etienne.carriere@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	 Rob Herring <robh+dt@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2 0/7] Asynchronous notifications from secure world
Date: Thu, 8 Jul 2021 18:26:30 +0530	[thread overview]
Message-ID: <CAFA6WYNF_GkRiqn+H5UO6O4ZEkZ16xO=JkV6LOvgvvaVqwFtxw@mail.gmail.com> (raw)
In-Reply-To: <20210707175123.xdotr3lsy3e32plm@bogus>

Hi Sudeep,

On Wed, 7 Jul 2021 at 23:22, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Hi Sumit,
>
> I was holding off you reply as I didn't have all the background on this.
> Achin did mention that this is preparatory work for FFA notifications.
> I did mention to him that this is more than that, it is custom extension
> to address what FF-A notification is trying to in standard way.
>
> I share same opinion as Marc Z.
>
> On Wed, Jul 07, 2021 at 11:22:23AM +0530, Sumit Garg wrote:
> > On Tue, 6 Jul 2021 at 18:16, Marc Zyngier <maz@kernel.org> wrote:
>
> [...]
>
> > >
> > > I don't care about OP-TEE. If you are proposing a contract between S
> > > and NS, it has to be TEE and OS independent. That's how the
> > > architecture works.
> > >
> >
> > Agree, here we are not proposing a common contract among the S and NS
> > world that every TEE (based on Arm TrustZone) will use to communicate
> > with REE (Linux in our case) but rather an OP-TEE specific
> > notifications feature that is built on top of OP-TEE specific ABIs.
> >
> > And I can see your arguments coming from an FFA perspective but there
> > are platforms like the ones based on Armv7 which don't support FFA
> > ABI. Maybe Jens can elaborate how this feature will fit in when FFA
> > comes into picture?
> >
>
> I can understand that but won't those platforms add the support both in
> the kernel(current series) and secure world to address notifications.

Agree.

> While you could argue that it is small extension to what is already present
> but I prefer they support FF-A is they need such a support instead of adding
> custom mechanisms. It is hard to maintain and each vendor will deviate
> from this custom mechanism and soon we will have bunch of them to handle.
>

I haven't had a deep dive into FF-A spec, maybe you can clarify on the
following queries regarding Armv7 compatibility:
- As you may be aware, secure monitor implementation on Armv7 is
tightly coupled to trusted OS (part of the same code base), so would
you like each trusted OS vendor to implement a common FF-A interface?
- IIRC, FF-A spec has the notion of multiple secure partitions, are
those supported on Armv7? If yes then how?

> > > > >
> > > > > In general, cross world SGIs are a really bad idea. Yes, some people
> > > > > like them. I still think they are misguided, and I don't intend to
> > > > > provide a generic request interface for this.
> > > >
> > > > Okay, as I mentioned above having it specific to OP-TEE driver
> > > > requesting secure world donated SGI would work for you?
> > >
> > > No. I want a proper architecture between secure and non-secure that
> > > explain how messages are conveyed between the two world, how
> > > signalling is done, how CPU PM is handled, how targeting is
> > > negotiated. And at the end of the day, this is starting to look a lot
> > > like FFA.
> >
> > AFAIK when FFA comes in picture than OP-TEE will use the standard
> > interface provided by FFA ABIs but if FFA isn't supported by a
> > particular platform (eg. based on Armv7) then we need to rely on TEE
> > specific ABI like what OP-TEE currently provides:
> >
>
> Who are asking for this ? Can we ask them to migrate to FF-A if this
> (new) notification support is needed on their platforms ? It is help to
> know the requesters so that they can be included in FF-A spec discussions.
>

I would let Jens answer that.

> > > that. You'll even get to keep the pieces once it breaks. But if you
> > > are going to invent a new universal way of signalling things across
> > > world, you'd better start specifying things the right way, taking into
> > > considerations systems where the interrupt controller doesn't allow
> > > cross-world signalling.
> >
> > As I mentioned above, this patch-set adds an OP-TEE specific
> > notifications feature. AFAIK, the interrupt controllers supported by
> > OP-TEE (GICv2, GICv3 etc.) don't restrict cross-world signaling.
> >
> > So given the explanation above, if you still think requesting an SGI
> > as an IRQ by drivers isn't allowed then I am fine with the approach
> > that Jens has already implemented in this patch-set to use platform
> > specific SPI.
> >
>
> And I assume these platforms in question have SPI to spare and way to
> trigger it from secure world ?
>

Yeah, that is the requirement on the platform if we rely on SPI (Qemu
test example [1]) which wouldn't be the case if we use secure world
donated SGI.

BTW, is this notification mechanism discussed in the case of FF-A? If
yes, can you throw some light on that?

[1] https://github.com/jenswi-linaro/optee_os/commit/9007f8184deb9b7995da8d590779cb3ba2783394

-Sumit

> --
> Regards,
> Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-08 12:56 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 10:36 Jens Wiklander
2021-06-16 10:36 ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 1/7] docs: staging/tee.rst: add a section on OP-TEE notifications Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 2/7] dt-bindings: arm: Convert optee binding to json-schema Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 16:03   ` Rob Herring
2021-06-16 16:03     ` Rob Herring
2021-06-16 16:05   ` Rob Herring
2021-06-16 16:05     ` Rob Herring
2021-06-22  8:38     ` Jens Wiklander
2021-06-22  8:38       ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 3/7] dt-bindings: arm: optee: add interrupt property Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 16:05   ` Rob Herring
2021-06-16 16:05     ` Rob Herring
2021-06-22  8:41     ` Jens Wiklander
2021-06-22  8:41       ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 4/7] tee: fix put order in teedev_close_context() Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 5/7] tee: add tee_dev_open_helper() primitive Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 6/7] optee: separate notification functions Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 10:36 ` [PATCH v2 7/7] optee: add asynchronous notifications Jens Wiklander
2021-06-16 10:36   ` Jens Wiklander
2021-06-16 14:08   ` Ard Biesheuvel
2021-06-16 14:08     ` Ard Biesheuvel
2021-06-17  4:33 ` [PATCH v2 0/7] Asynchronous notifications from secure world Sumit Garg
2021-06-17  4:33   ` Sumit Garg
2021-06-17  6:10   ` Jens Wiklander
2021-06-17  6:10     ` Jens Wiklander
2021-07-06  7:25     ` Sumit Garg
2021-07-06  7:25       ` Sumit Garg
2021-07-06 10:36       ` Marc Zyngier
2021-07-06 10:36         ` Marc Zyngier
2021-07-06 11:39         ` Sumit Garg
2021-07-06 11:39           ` Sumit Garg
2021-07-06 12:46           ` Marc Zyngier
2021-07-06 12:46             ` Marc Zyngier
2021-07-07  5:52             ` Sumit Garg
2021-07-07  5:52               ` Sumit Garg
2021-07-07  6:54               ` Jens Wiklander
2021-07-07  6:54                 ` Jens Wiklander
2021-07-07 17:51               ` Sudeep Holla
2021-07-07 17:51                 ` Sudeep Holla
2021-07-08 12:56                 ` Sumit Garg [this message]
2021-07-08 12:56                   ` Sumit Garg
2021-07-09  8:05 Etienne CARRIERE
2021-07-13 11:11 ` Sudeep Holla
2021-07-13 11:11   ` Sudeep Holla
2021-07-20  6:45   ` Jens Wiklander
2021-07-20  6:45     ` Jens Wiklander
2021-07-20  7:50     ` Sudeep Holla
2021-07-20  7:50       ` Sudeep Holla
2021-07-20  9:59       ` Jens Wiklander
2021-07-20  9:59         ` Jens Wiklander

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='CAFA6WYNF_GkRiqn+H5UO6O4ZEkZ16xO=JkV6LOvgvvaVqwFtxw@mail.gmail.com' \
    --to=sumit.garg@linaro.org \
    --cc=ardb@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=etienne.carriere@linaro.org \
    --cc=jens.wiklander@linaro.org \
    --cc=jerome@forissier.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --subject='Re: [PATCH v2 0/7] Asynchronous notifications from secure world' \
    /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

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.