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@xxxxxxxxxxx> > wrote: > >> On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen < > ppaalanen@xxxxxxxxx> 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. >
