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.