[v3,0/7] dma-buf: heaps: Add secure heap

  This patchset is for secure video playback and enables other potential
uses in the future. The 'secure dma-heap' will be used to allocate dma_buf
objects that reference memory in the secure world that is inaccessible/
unmappable by the non-secure (i.e.kernel/userspace) world.  That memory
will be used by the secure world to store secure information (i.e.
decrypted media content). The dma_bufs allocated from the kernel will be
passed to V4L2 for video decoding (as input and output). They will also be
used by the drm system for rendering of the content.

This patchset adds two secure heaps and they will be used v4l2[1] and drm[2].
1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
   The buffer is reserved for the secure world after bootup and it is used
   for vcodec's ES/working buffer;
2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
   dynamically reserved for the secure world and will be got when we start
   playing secure videos, Once the security video playing is complete, the
   CMA will be released. This heap is used for the vcodec's frame buffer.

[1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@mediatek.com/
[2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin@mediatek.com/

Change note:
v3: Base on v6.7-rc1.
    1) Separate the secure heap into a common file(secure_heap.c) and a mtk special file
       (secure_heap_mtk.c), and put all tee related code into our special file.
    2) About dt-binding,
       a) Add "mediatek," prefix since this is Mediatek TEE firmware definition.
       b) Mute dt-binding check waring.
    3) Remove the normal CMA heap which is a draft for qcom.

v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediatek.com/
    1) Move John's patches into the vcodec patchset since they use the new
       dma heap interface directly.
       https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@mediatek.com/
    2) Reword the dt-binding description.
    3) Rename the heap name from mtk_svp to secure_mtk_cm.
       This means the current vcodec/DRM upstream code doesn't match this.
    4) Add a normal CMA heap. currently it should be a draft version.
    5) Regarding the UUID, I still use hard code, but put it in a private
    data which allow the others could set their own UUID. What's more, UUID
    is necessary for the session with TEE. If we don't have it, we can't
    communicate with the TEE, including the get_uuid interface, which tries
    to make uuid more generic, not working. If there is other way to make
    UUID more general, please free to tell me.
    
v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@mediatek.com/
    Base on v6.6-rc1.

Yong Wu (7):
  dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region
  dma-buf: heaps: Initialize a secure heap
  dma-buf: heaps: secure_heap: Add private heap ops
  dma-buf: heaps: secure_heap: Add dma_ops
  dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init
  dma-buf: heaps: secure_heap_mtk: Add tee memory service call
  dma_buf: heaps: secure_heap_mtk: Add a new CMA heap

 .../mediatek,dynamic-secure-region.yaml       |  43 +++
 drivers/dma-buf/heaps/Kconfig                 |  13 +
 drivers/dma-buf/heaps/Makefile                |   2 +
 drivers/dma-buf/heaps/secure_heap.c           | 234 +++++++++++++
 drivers/dma-buf/heaps/secure_heap.h           |  43 +++
 drivers/dma-buf/heaps/secure_heap_mtk.c       | 321 ++++++++++++++++++
 6 files changed, 656 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
 create mode 100644 drivers/dma-buf/heaps/secure_heap.c
 create mode 100644 drivers/dma-buf/heaps/secure_heap.h
 create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c
  

Is there a chance to pick a better name than "secure" here?

"Secure" is super overloaded, it's not clear at all what it means from
just the name. Something like "restricted" would be an improvement.
  

On Tue, 12 Dec 2023 16:36:35 +0000
Simon Ser <contact@emersion.fr> wrote:

> Is there a chance to pick a better name than "secure" here?
> 
> "Secure" is super overloaded, it's not clear at all what it means from
> just the name. Something like "restricted" would be an improvement.
> 

My thoughts exactly. Every time I see "secure" used for something that
either gives you garbage, refuses to work, or crashes your whole machine
*intentionally* when you try to do normal usual things to it in
userspace (like use it for GL texturing, or try to use KMS writeback), I
get an unscratchable itch.

There is nothing "secure" from security perspective there for end users
and developers. It's just inaccessible buffers.

I've been biting my lip until now, thinking it's too late.


Thanks,
pq
  

On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> On Tue, 12 Dec 2023 16:36:35 +0000
> Simon Ser <contact@emersion.fr> wrote:
> 
> > Is there a chance to pick a better name than "secure" here?
> > 
> > "Secure" is super overloaded, it's not clear at all what it means from
> > just the name. Something like "restricted" would be an improvement.
> > 
> 
> My thoughts exactly. Every time I see "secure" used for something that
> either gives you garbage, refuses to work, or crashes your whole machine
> *intentionally* when you try to do normal usual things to it in
> userspace (like use it for GL texturing, or try to use KMS writeback), I
> get an unscratchable itch.
> 
> There is nothing "secure" from security perspective there for end users
> and developers. It's just inaccessible buffers.
> 
> I've been biting my lip until now, thinking it's too late.
> 
The characteristics we're looking for here is a buffer where the content
is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
EL2. I.e, the content of the buffer is meant to be used and accessible
primarily by the secure side and other devices that has been granted
access to it (for example decoders, display controllers if we're talking
about video use cases). However, since the use cases for this exercises
the whole stack, from non-secure user space (EL0) all the way to secure
user space (S-EL0), with various devices needing access to the buffer at
various times, it makes sense to let Linux manage the buffers, although
it still cannot access the content. That's the overall context.

As for the name, it's always difficult to find a name suitable precisely
describing what it is. "Secure" is perhaps vague, but it might still a
good choice, if you carefully describe what secure means for this
particular heap (in the source code and the documentation for it). For
example, the definition of "secure" for a secure heap as here could mean
that buffer content is inaccessible to the host OS and user space
running in normal world (using Arm nomenclature). I wouldn't have any
problems with calling it secure if, as said it's defined what we mean by
saying so. But I'm all ears for other suggestions as well.

Safe, protected, shielded, unreachable, isolated, inaccessible,
unaccessible, fortified, ... would any of these make more sense?

> 
> Thanks,
> pq
  

On Wed, 13 Dec 2023 11:15:49 +0100
Joakim Bech <joakim.bech@linaro.org> wrote:

> On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > On Tue, 12 Dec 2023 16:36:35 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >   
> > > Is there a chance to pick a better name than "secure" here?
> > > 
> > > "Secure" is super overloaded, it's not clear at all what it means from
> > > just the name. Something like "restricted" would be an improvement.
> > >   
> > 
> > My thoughts exactly. Every time I see "secure" used for something that
> > either gives you garbage, refuses to work, or crashes your whole machine
> > *intentionally* when you try to do normal usual things to it in
> > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > get an unscratchable itch.
> > 
> > There is nothing "secure" from security perspective there for end users
> > and developers. It's just inaccessible buffers.
> > 
> > I've been biting my lip until now, thinking it's too late.
> >   
> The characteristics we're looking for here is a buffer where the content
> is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> EL2. I.e, the content of the buffer is meant to be used and accessible
> primarily by the secure side and other devices that has been granted

s/secure side/proprietary side/

I presume nothing of the other side can ever be in any way open?

Maybe the other side is even less secure than the FOSS side...

> access to it (for example decoders, display controllers if we're talking
> about video use cases). However, since the use cases for this exercises
> the whole stack, from non-secure user space (EL0) all the way to secure
> user space (S-EL0), with various devices needing access to the buffer at
> various times, it makes sense to let Linux manage the buffers, although
> it still cannot access the content. That's the overall context.

Yes, we know all this (except for the exact meaning of EL0 etc.).

> As for the name, it's always difficult to find a name suitable precisely
> describing what it is. "Secure" is perhaps vague, but it might still a
> good choice, if you carefully describe what secure means for this
> particular heap (in the source code and the documentation for it). For

Carefully describe, as in, re-define.

> example, the definition of "secure" for a secure heap as here could mean
> that buffer content is inaccessible to the host OS and user space
> running in normal world (using Arm nomenclature). I wouldn't have any
> problems with calling it secure if, as said it's defined what we mean by
> saying so. But I'm all ears for other suggestions as well.
> 
> Safe, protected, shielded, unreachable, isolated, inaccessible,
> unaccessible, fortified, ... would any of these make more sense?

"Restricted" sounds like a good compromise to me. The buffers' usage is
severely restricted.

It is the opposite of "safe", because accessing the contents the wrong
way can return garbage or intentionally crash the whole system,
depending on the hardware implementation. One example is attempting to
put such a buffer on a KMS plane while the connector HDCP state is not
high enough, or a writeback connector is connected to the CRTC. It is
really fragile. (Do KMS drivers fail an atomic commit that would
violate the heap rules? Somehow I doubt that, who'd even know what the
rules are.)

It is protected/shielded/fortified from all the kernel and userspace,
but a more familiar word to describe that is inaccessible.
"Inaccessible buffer" per se OTOH sounds like a useless concept.

It is not secure, because it does not involve security in any way. In
fact, given it's so fragile, I'd classify it as mildly opposite of
secure, as e.g. clients of a Wayland compositor can potentially DoS the
compositor with it by simply sending such a dmabuf. Or DoS the whole
system.

"Poisonous heap" would be fitting but politically inappropriate I
guess. After all, "poison" is data that is not meant to be read by
anything normal.


Thanks,
pq
  

On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
> On Wed, 13 Dec 2023 11:15:49 +0100
> Joakim Bech <joakim.bech@linaro.org> wrote:
> 
> > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > > On Tue, 12 Dec 2023 16:36:35 +0000
> > > Simon Ser <contact@emersion.fr> wrote:
> > >   
> > > > Is there a chance to pick a better name than "secure" here?
> > > > 
> > > > "Secure" is super overloaded, it's not clear at all what it means from
> > > > just the name. Something like "restricted" would be an improvement.
> > > >   
> > > 
> > > My thoughts exactly. Every time I see "secure" used for something that
> > > either gives you garbage, refuses to work, or crashes your whole machine
> > > *intentionally* when you try to do normal usual things to it in
> > > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > > get an unscratchable itch.
> > > 
> > > There is nothing "secure" from security perspective there for end users
> > > and developers. It's just inaccessible buffers.
> > > 
> > > I've been biting my lip until now, thinking it's too late.
> > >   
> > The characteristics we're looking for here is a buffer where the content
> > is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> > EL2. I.e, the content of the buffer is meant to be used and accessible
> > primarily by the secure side and other devices that has been granted
> 
> s/secure side/proprietary side/
> 
I'm using the nomenclature as written by Arm (other architectures have
other names for their secure execution states).

> I presume nothing of the other side can ever be in any way open?
> 
I'm sure there are lots of examples of things running on the secure side
that are open. The OP-TEE project where I'm a maintainer has been fully
open source since 2014, to give one example that I'm familiar with
myself.

> Maybe the other side is even less secure than the FOSS side...
> 
> > access to it (for example decoders, display controllers if we're talking
> > about video use cases). However, since the use cases for this exercises
> > the whole stack, from non-secure user space (EL0) all the way to secure
> > user space (S-EL0), with various devices needing access to the buffer at
> > various times, it makes sense to let Linux manage the buffers, although
> > it still cannot access the content. That's the overall context.
> 
> Yes, we know all this (except for the exact meaning of EL0 etc.).
> 
Great!

> > As for the name, it's always difficult to find a name suitable precisely
> > describing what it is. "Secure" is perhaps vague, but it might still a
> > good choice, if you carefully describe what secure means for this
> > particular heap (in the source code and the documentation for it). For
> 
> Carefully describe, as in, re-define.
> 
> > example, the definition of "secure" for a secure heap as here could mean
> > that buffer content is inaccessible to the host OS and user space
> > running in normal world (using Arm nomenclature). I wouldn't have any
> > problems with calling it secure if, as said it's defined what we mean by
> > saying so. But I'm all ears for other suggestions as well.
> > 
> > Safe, protected, shielded, unreachable, isolated, inaccessible,
> > unaccessible, fortified, ... would any of these make more sense?
> 
> "Restricted" sounds like a good compromise to me. The buffers' usage is
> severely restricted.
> 
Yes, restricted isn't a bad choice. We would still need to describe what
we mean by saying it's restricted, i.e., what is it restricted from,
since I'd guess that "restricted" by itself also could be a bit open
ended for a lot of people.

> It is the opposite of "safe", because accessing the contents the wrong
> way can return garbage or intentionally crash the whole system,
> depending on the hardware implementation. One example is attempting to
> put such a buffer on a KMS plane while the connector HDCP state is not
> high enough, or a writeback connector is connected to the CRTC. It is
> really fragile. (Do KMS drivers fail an atomic commit that would
> violate the heap rules? Somehow I doubt that, who'd even know what the
> rules are.)
> 
I believe one of the goals with reviewing the patches is to highlight
issues like this and try to figure out how to avoid ending up in
situations like what you described by suggesting alternative solutions
and ideas.

> It is protected/shielded/fortified from all the kernel and userspace,
> but a more familiar word to describe that is inaccessible.
> "Inaccessible buffer" per se OTOH sounds like a useless concept.
> 
> It is not secure, because it does not involve security in any way. In
> fact, given it's so fragile, I'd classify it as mildly opposite of
> secure, as e.g. clients of a Wayland compositor can potentially DoS the
> compositor with it by simply sending such a dmabuf. Or DoS the whole
> system.
> 
I hear what you are saying and DoS is a known problem and attack vector,
but regardless, we have use cases where we don't want to expose
information in the clear and where we also would like to have some
guarantees about correctness. That is where various secure elements and
more generally security is needed.

So, it sounds like we have two things here, the first is the naming and
the meaning behind it. I'm pretty sure the people following and
contributing to this thread can agree on a name that makes sense. Would
you personally be OK with "restricted" as the name? It sounds like that.

The other thing is the feature and functionality itself offered by this
patch series. My impression from reading your replies is that you think
this is the wrong approach. If my impression is correct, what would you
suggest as an alternative approach?

> "Poisonous heap" would be fitting but politically inappropriate I
> guess. After all, "poison" is data that is not meant to be read by
> anything normal.
> 
> 
> Thanks,
> pq
  

Am 13.12.23 um 14:22 schrieb Joakim Bech:
> On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
>> On Wed, 13 Dec 2023 11:15:49 +0100
>> Joakim Bech <joakim.bech@linaro.org> wrote:
>>
>>> On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
>>>> On Tue, 12 Dec 2023 16:36:35 +0000
>>>> Simon Ser <contact@emersion.fr> wrote:
>>>>    
>>>>> Is there a chance to pick a better name than "secure" here?
>>>>>
>>>>> "Secure" is super overloaded, it's not clear at all what it means from
>>>>> just the name. Something like "restricted" would be an improvement.
>>>>>    
>>>> My thoughts exactly. Every time I see "secure" used for something that
>>>> either gives you garbage, refuses to work, or crashes your whole machine
>>>> *intentionally* when you try to do normal usual things to it in
>>>> userspace (like use it for GL texturing, or try to use KMS writeback), I
>>>> get an unscratchable itch.
>>>>
>>>> There is nothing "secure" from security perspective there for end users
>>>> and developers. It's just inaccessible buffers.
>>>>
>>>> I've been biting my lip until now, thinking it's too late.
>>>>    
>>> The characteristics we're looking for here is a buffer where the content
>>> is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
>>> EL2. I.e, the content of the buffer is meant to be used and accessible
>>> primarily by the secure side and other devices that has been granted
>> s/secure side/proprietary side/
>>
> I'm using the nomenclature as written by Arm (other architectures have
> other names for their secure execution states).

AMDs GPUs call that "trusted" which is only minimal better than secure I 
think.

>
>> I presume nothing of the other side can ever be in any way open?
>>
> I'm sure there are lots of examples of things running on the secure side
> that are open. The OP-TEE project where I'm a maintainer has been fully
> open source since 2014, to give one example that I'm familiar with
> myself.

On AMDs GPUs you can actually write shaders which works with the trusted 
data and can read and write.

What is prevented is that you copy the data outside of the trusted zone, 
e.g. to the CPU. When you do this you only get garbage.

Only engines which have the proper decryption key can send out the data 
(for example) to a display device which has authenticated itself using HDCP.

Just a few infos how this is done elsewhere.

Cheers,
Christian.

>
>> Maybe the other side is even less secure than the FOSS side...
>>
>>> access to it (for example decoders, display controllers if we're talking
>>> about video use cases). However, since the use cases for this exercises
>>> the whole stack, from non-secure user space (EL0) all the way to secure
>>> user space (S-EL0), with various devices needing access to the buffer at
>>> various times, it makes sense to let Linux manage the buffers, although
>>> it still cannot access the content. That's the overall context.
>> Yes, we know all this (except for the exact meaning of EL0 etc.).
>>
> Great!
>
>>> As for the name, it's always difficult to find a name suitable precisely
>>> describing what it is. "Secure" is perhaps vague, but it might still a
>>> good choice, if you carefully describe what secure means for this
>>> particular heap (in the source code and the documentation for it). For
>> Carefully describe, as in, re-define.
>>
>>> example, the definition of "secure" for a secure heap as here could mean
>>> that buffer content is inaccessible to the host OS and user space
>>> running in normal world (using Arm nomenclature). I wouldn't have any
>>> problems with calling it secure if, as said it's defined what we mean by
>>> saying so. But I'm all ears for other suggestions as well.
>>>
>>> Safe, protected, shielded, unreachable, isolated, inaccessible,
>>> unaccessible, fortified, ... would any of these make more sense?
>> "Restricted" sounds like a good compromise to me. The buffers' usage is
>> severely restricted.
>>
> Yes, restricted isn't a bad choice. We would still need to describe what
> we mean by saying it's restricted, i.e., what is it restricted from,
> since I'd guess that "restricted" by itself also could be a bit open
> ended for a lot of people.
>
>> It is the opposite of "safe", because accessing the contents the wrong
>> way can return garbage or intentionally crash the whole system,
>> depending on the hardware implementation. One example is attempting to
>> put such a buffer on a KMS plane while the connector HDCP state is not
>> high enough, or a writeback connector is connected to the CRTC. It is
>> really fragile. (Do KMS drivers fail an atomic commit that would
>> violate the heap rules? Somehow I doubt that, who'd even know what the
>> rules are.)
>>
> I believe one of the goals with reviewing the patches is to highlight
> issues like this and try to figure out how to avoid ending up in
> situations like what you described by suggesting alternative solutions
> and ideas.
>
>> It is protected/shielded/fortified from all the kernel and userspace,
>> but a more familiar word to describe that is inaccessible.
>> "Inaccessible buffer" per se OTOH sounds like a useless concept.
>>
>> It is not secure, because it does not involve security in any way. In
>> fact, given it's so fragile, I'd classify it as mildly opposite of
>> secure, as e.g. clients of a Wayland compositor can potentially DoS the
>> compositor with it by simply sending such a dmabuf. Or DoS the whole
>> system.
>>
> I hear what you are saying and DoS is a known problem and attack vector,
> but regardless, we have use cases where we don't want to expose
> information in the clear and where we also would like to have some
> guarantees about correctness. That is where various secure elements and
> more generally security is needed.
>
> So, it sounds like we have two things here, the first is the naming and
> the meaning behind it. I'm pretty sure the people following and
> contributing to this thread can agree on a name that makes sense. Would
> you personally be OK with "restricted" as the name? It sounds like that.
>
> The other thing is the feature and functionality itself offered by this
> patch series. My impression from reading your replies is that you think
> this is the wrong approach. If my impression is correct, what would you
> suggest as an alternative approach?
>
>> "Poisonous heap" would be fitting but politically inappropriate I
>> guess. After all, "poison" is data that is not meant to be read by
>> anything normal.
>>
>>
>> Thanks,
>> pq
  

On Wed, 13 Dec 2023 14:22:29 +0100
Joakim Bech <joakim.bech@linaro.org> wrote:

> On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
> > On Wed, 13 Dec 2023 11:15:49 +0100
> > Joakim Bech <joakim.bech@linaro.org> wrote:
> >   
> > > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:  
> > > > On Tue, 12 Dec 2023 16:36:35 +0000
> > > > Simon Ser <contact@emersion.fr> wrote:
> > > >     
> > > > > Is there a chance to pick a better name than "secure" here?
> > > > > 
> > > > > "Secure" is super overloaded, it's not clear at all what it means from
> > > > > just the name. Something like "restricted" would be an improvement.
> > > > >     
> > > > 
> > > > My thoughts exactly. Every time I see "secure" used for something that
> > > > either gives you garbage, refuses to work, or crashes your whole machine
> > > > *intentionally* when you try to do normal usual things to it in
> > > > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > > > get an unscratchable itch.
> > > > 
> > > > There is nothing "secure" from security perspective there for end users
> > > > and developers. It's just inaccessible buffers.
> > > > 
> > > > I've been biting my lip until now, thinking it's too late.
> > > >     
> > > The characteristics we're looking for here is a buffer where the content
> > > is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> > > EL2. I.e, the content of the buffer is meant to be used and accessible
> > > primarily by the secure side and other devices that has been granted  
> > 
> > s/secure side/proprietary side/
> >   
> I'm using the nomenclature as written by Arm (other architectures have
> other names for their secure execution states).
> 
> > I presume nothing of the other side can ever be in any way open?
> >   
> I'm sure there are lots of examples of things running on the secure side
> that are open. The OP-TEE project where I'm a maintainer has been fully
> open source since 2014, to give one example that I'm familiar with
> myself.

Oh, I didn't realise there were FOSS implementations of the other side
that tie in with this secure/restricted heap here. Sorry.

I think the patch series cover letter should point to those to give a
view of the other side to the reviewers, just like DRM requires
userspace to be open for new UAPI.

> > Maybe the other side is even less secure than the FOSS side...
> >   
> > > access to it (for example decoders, display controllers if we're talking
> > > about video use cases). However, since the use cases for this exercises
> > > the whole stack, from non-secure user space (EL0) all the way to secure
> > > user space (S-EL0), with various devices needing access to the buffer at
> > > various times, it makes sense to let Linux manage the buffers, although
> > > it still cannot access the content. That's the overall context.  
> > 
> > Yes, we know all this (except for the exact meaning of EL0 etc.).
> >   
> Great!
> 
> > > As for the name, it's always difficult to find a name suitable precisely
> > > describing what it is. "Secure" is perhaps vague, but it might still a
> > > good choice, if you carefully describe what secure means for this
> > > particular heap (in the source code and the documentation for it). For  
> > 
> > Carefully describe, as in, re-define.
> >   
> > > example, the definition of "secure" for a secure heap as here could mean
> > > that buffer content is inaccessible to the host OS and user space
> > > running in normal world (using Arm nomenclature). I wouldn't have any
> > > problems with calling it secure if, as said it's defined what we mean by
> > > saying so. But I'm all ears for other suggestions as well.
> > > 
> > > Safe, protected, shielded, unreachable, isolated, inaccessible,
> > > unaccessible, fortified, ... would any of these make more sense?  
> > 
> > "Restricted" sounds like a good compromise to me. The buffers' usage is
> > severely restricted.
> >   
> Yes, restricted isn't a bad choice. We would still need to describe what
> we mean by saying it's restricted, i.e., what is it restricted from,
> since I'd guess that "restricted" by itself also could be a bit open
> ended for a lot of people.

Yes, but "restricted" also does not give out an immediate wrong
impression. Label something as "secure", and it immediately raises the
questions of what kind of attacks it prevents and how can I make use of
it.

Is there any use of restricted buffers outside of Digital Rights
Management though? Could a private person somehow make use of it to
protect their own contents? Like a photographer sending drafts to a
customer while not wanting give out any digital copies?

If not, then restricted buffers are something people would generally
like to avoid, not embrace. "Secure" gives a positive impression,
"restricted" a negative impression.

> > It is the opposite of "safe", because accessing the contents the wrong
> > way can return garbage or intentionally crash the whole system,
> > depending on the hardware implementation. One example is attempting to
> > put such a buffer on a KMS plane while the connector HDCP state is not
> > high enough, or a writeback connector is connected to the CRTC. It is
> > really fragile. (Do KMS drivers fail an atomic commit that would
> > violate the heap rules? Somehow I doubt that, who'd even know what the
> > rules are.)
> >   
> I believe one of the goals with reviewing the patches is to highlight
> issues like this and try to figure out how to avoid ending up in
> situations like what you described by suggesting alternative solutions
> and ideas.
> 
> > It is protected/shielded/fortified from all the kernel and userspace,
> > but a more familiar word to describe that is inaccessible.
> > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > 
> > It is not secure, because it does not involve security in any way. In
> > fact, given it's so fragile, I'd classify it as mildly opposite of
> > secure, as e.g. clients of a Wayland compositor can potentially DoS the
> > compositor with it by simply sending such a dmabuf. Or DoS the whole
> > system.
> >   
> I hear what you are saying and DoS is a known problem and attack vector,
> but regardless, we have use cases where we don't want to expose
> information in the clear and where we also would like to have some
> guarantees about correctness. That is where various secure elements and
> more generally security is needed.
> 
> So, it sounds like we have two things here, the first is the naming and
> the meaning behind it. I'm pretty sure the people following and
> contributing to this thread can agree on a name that makes sense. Would
> you personally be OK with "restricted" as the name? It sounds like that.

I would. I'm also just a by-stander, not a maintainer of kernel
anything. I have no power to accept nor reject anything here.

> The other thing is the feature and functionality itself offered by this
> patch series. My impression from reading your replies is that you think
> this is the wrong approach. If my impression is correct, what would you
> suggest as an alternative approach?

I just generally dislike locking people out of what their systems hold,
but I also understand why extremely big companies want this Digital
Rights Management technology for their business model. If Linux does
not support that business model, they and the whole broadcast industry
might use something else. At least it pays for kernel developers who
can hopefully do some genuinely useful work on the side as well,
benefiting the community.

Let's just be honest about what is what.


Thanks,
pq
  

On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <ppaalanen@gmail.com> wrote:

> > > It is protected/shielded/fortified from all the kernel and userspace,
> > > but a more familiar word to describe that is inaccessible.
> > > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > > 
> > > It is not secure, because it does not involve security in any way. In
> > > fact, given it's so fragile, I'd classify it as mildly opposite of
> > > secure, as e.g. clients of a Wayland compositor can potentially DoS the
> > > compositor with it by simply sending such a dmabuf. Or DoS the whole
> > > system.
> > 
> > I hear what you are saying and DoS is a known problem and attack vector,
> > but regardless, we have use cases where we don't want to expose
> > information in the clear and where we also would like to have some
> > guarantees about correctness. That is where various secure elements and
> > more generally security is needed.
> > 
> > So, it sounds like we have two things here, the first is the naming and
> > the meaning behind it. I'm pretty sure the people following and
> > contributing to this thread can agree on a name that makes sense. Would
> > you personally be OK with "restricted" as the name? It sounds like that.
> 
> I would. I'm also just a by-stander, not a maintainer of kernel
> anything. I have no power to accept nor reject anything here.

I'd also personally be OK with "restricted", I think it's a lot better
than "secure".

In general I agree with everything Pekka said.
  

Any feedback from maintainers on what their preference is?  I'm fine
with 'restricted' as well, but the main reason we chose secure was
because of its use in ARM nomenclature and this is more for ARM usage
than x86.

The main difference with similar buffers on AMD/Intel is that with
AMD/Intel the buffers are mappable and readable by the CPU in the
kernel. The problem is their contents are encrypted so you get junk
back if you do that. On ARM, the buffers are completely inaccessible
by the kernel and the memory controller prevents access to them
completely from the kernel.

There are also other use cases for this where the hypervisor is what
is controlling access (second stage in the MMU is providing
isolation)....and in that case I do agree that 'secure' would not be
the right terminology for those types of buffers.   So I do agree
something other than 'secure' is probably a better option overall.


On Fri, Dec 22, 2023 at 1:40 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> > > > It is protected/shielded/fortified from all the kernel and userspace,
> > > > but a more familiar word to describe that is inaccessible.
> > > > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > > >
> > > > It is not secure, because it does not involve security in any way. In
> > > > fact, given it's so fragile, I'd classify it as mildly opposite of
> > > > secure, as e.g. clients of a Wayland compositor can potentially DoS the
> > > > compositor with it by simply sending such a dmabuf. Or DoS the whole
> > > > system.
> > >
> > > I hear what you are saying and DoS is a known problem and attack vector,
> > > but regardless, we have use cases where we don't want to expose
> > > information in the clear and where we also would like to have some
> > > guarantees about correctness. That is where various secure elements and
> > > more generally security is needed.
> > >
> > > So, it sounds like we have two things here, the first is the naming and
> > > the meaning behind it. I'm pretty sure the people following and
> > > contributing to this thread can agree on a name that makes sense. Would
> > > you personally be OK with "restricted" as the name? It sounds like that.
> >
> > I would. I'm also just a by-stander, not a maintainer of kernel
> > anything. I have no power to accept nor reject anything here.
>
> I'd also personally be OK with "restricted", I think it's a lot better
> than "secure".
>
> In general I agree with everything Pekka said.
  

Am 04.01.24 um 20:50 schrieb Jeffrey Kardatzke:
> Any feedback from maintainers on what their preference is?  I'm fine
> with 'restricted' as well, but the main reason we chose secure was
> because of its use in ARM nomenclature and this is more for ARM usage
> than x86.

Well AMD calls this "trusted", but I think that's just slightly better 
than "secure".

+1 for using "restricted" cause that seems to match the technical 
consequences.

Regards,
Christian.

>
> The main difference with similar buffers on AMD/Intel is that with
> AMD/Intel the buffers are mappable and readable by the CPU in the
> kernel. The problem is their contents are encrypted so you get junk
> back if you do that. On ARM, the buffers are completely inaccessible
> by the kernel and the memory controller prevents access to them
> completely from the kernel.
>
> There are also other use cases for this where the hypervisor is what
> is controlling access (second stage in the MMU is providing
> isolation)....and in that case I do agree that 'secure' would not be
> the right terminology for those types of buffers.   So I do agree
> something other than 'secure' is probably a better option overall.
>
>
> On Fri, Dec 22, 2023 at 1:40 AM Simon Ser <contact@emersion.fr> wrote:
>> On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>
>>>>> It is protected/shielded/fortified from all the kernel and userspace,
>>>>> but a more familiar word to describe that is inaccessible.
>>>>> "Inaccessible buffer" per se OTOH sounds like a useless concept.
>>>>>
>>>>> It is not secure, because it does not involve security in any way. In
>>>>> fact, given it's so fragile, I'd classify it as mildly opposite of
>>>>> secure, as e.g. clients of a Wayland compositor can potentially DoS the
>>>>> compositor with it by simply sending such a dmabuf. Or DoS the whole
>>>>> system.
>>>> I hear what you are saying and DoS is a known problem and attack vector,
>>>> but regardless, we have use cases where we don't want to expose
>>>> information in the clear and where we also would like to have some
>>>> guarantees about correctness. That is where various secure elements and
>>>> more generally security is needed.
>>>>
>>>> So, it sounds like we have two things here, the first is the naming and
>>>> the meaning behind it. I'm pretty sure the people following and
>>>> contributing to this thread can agree on a name that makes sense. Would
>>>> you personally be OK with "restricted" as the name? It sounds like that.
>>> I would. I'm also just a by-stander, not a maintainer of kernel
>>> anything. I have no power to accept nor reject anything here.
>> I'd also personally be OK with "restricted", I think it's a lot better
>> than "secure".
>>
>> In general I agree with everything Pekka said.
  

On Fri, 2024-01-05 at 10:35 +0100, Christian König wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Am 04.01.24 um 20:50 schrieb Jeffrey Kardatzke:
> > Any feedback from maintainers on what their preference is?  I'm
> fine
> > with 'restricted' as well, but the main reason we chose secure was
> > because of its use in ARM nomenclature and this is more for ARM
> usage
> > than x86.
> 
> Well AMD calls this "trusted", but I think that's just slightly
> better 
> than "secure".
> 
> +1 for using "restricted" cause that seems to match the technical 
> consequences.

Thanks you all for the discussion and the conclusion. I will send v4 in
this week with "restricted".

> 
> Regards,
> Christian.
> 
> >
> > The main difference with similar buffers on AMD/Intel is that with
> > AMD/Intel the buffers are mappable and readable by the CPU in the
> > kernel. The problem is their contents are encrypted so you get junk
> > back if you do that. On ARM, the buffers are completely
> inaccessible
> > by the kernel and the memory controller prevents access to them
> > completely from the kernel.
> >
> > There are also other use cases for this where the hypervisor is
> what
> > is controlling access (second stage in the MMU is providing
> > isolation)....and in that case I do agree that 'secure' would not
> be
> > the right terminology for those types of buffers.   So I do agree
> > something other than 'secure' is probably a better option overall.
> >
> >
> > On Fri, Dec 22, 2023 at 1:40 AM Simon Ser <contact@emersion.fr>
> wrote:
> >> On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <
> ppaalanen@gmail.com> wrote:
> >>
> >>>>> It is protected/shielded/fortified from all the kernel and
> userspace,
> >>>>> but a more familiar word to describe that is inaccessible.
> >>>>> "Inaccessible buffer" per se OTOH sounds like a useless
> concept.
> >>>>>
> >>>>> It is not secure, because it does not involve security in any
> way. In
> >>>>> fact, given it's so fragile, I'd classify it as mildly opposite
> of
> >>>>> secure, as e.g. clients of a Wayland compositor can potentially
> DoS the
> >>>>> compositor with it by simply sending such a dmabuf. Or DoS the
> whole
> >>>>> system.
> >>>> I hear what you are saying and DoS is a known problem and attack
> vector,
> >>>> but regardless, we have use cases where we don't want to expose
> >>>> information in the clear and where we also would like to have
> some
> >>>> guarantees about correctness. That is where various secure
> elements and
> >>>> more generally security is needed.
> >>>>
> >>>> So, it sounds like we have two things here, the first is the
> naming and
> >>>> the meaning behind it. I'm pretty sure the people following and
> >>>> contributing to this thread can agree on a name that makes
> sense. Would
> >>>> you personally be OK with "restricted" as the name? It sounds
> like that.
> >>> I would. I'm also just a by-stander, not a maintainer of kernel
> >>> anything. I have no power to accept nor reject anything here.
> >> I'd also personally be OK with "restricted", I think it's a lot
> better
> >> than "secure".
> >>
> >> In general I agree with everything Pekka said.
>