On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
On Wed, 13 Dec 2023 11:15:49 +0100I'm using the nomenclature as written by Arm (other architectures have
Joakim Bech <joakim.bech@xxxxxxxxxx> wrote:
On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:s/secure side/proprietary side/
On Tue, 12 Dec 2023 16:36:35 +0000The characteristics we're looking for here is a buffer where the content
Simon Ser <contact@xxxxxxxxxxx> wrote:
Is there a chance to pick a better name than "secure" here?My thoughts exactly. Every time I see "secure" used for something that
"Secure" is super overloaded, it's not clear at all what it means from
just the name. Something like "restricted" would be an improvement.
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.
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
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...Great!
access to it (for example decoders, display controllers if we're talkingYes, we know all this (except for the exact meaning of EL0 etc.).
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, restricted isn't a bad choice. We would still need to describe whatAs for the name, it's always difficult to find a name suitable preciselyCarefully describe, as in, re-define.
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"Restricted" sounds like a good compromise to me. The buffers' usage is
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?
severely restricted.
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 wrongI believe one of the goals with reviewing the patches is to highlight
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.)
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,I hear what you are saying and DoS is a known problem and attack vector,
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.
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