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?
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",
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 b
On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen
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
On Wed, 13 Dec 2023 14:22:29 +0100
Joakim Bech 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 wrote:
> >
> > > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > > > On Tue, 12 Dec 2023 16:36:3
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 wrote:
On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
On Tue, 12 Dec 2023 16:36:35 +
Simon Ser wrote:
Is there a
On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
> On Wed, 13 Dec 2023 11:15:49 +0100
> Joakim Bech wrote:
>
> > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > > On Tue, 12 Dec 2023 16:36:35 +
> > > Simon Ser wrote:
> > >
> > > > Is there a chance to pi
On Wed, 13 Dec 2023 11:15:49 +0100
Joakim Bech wrote:
> On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > On Tue, 12 Dec 2023 16:36:35 +
> > Simon Ser wrote:
> >
> > > Is there a chance to pick a better name than "secure" here?
> > >
> > > "Secure" is super overloaded,
On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> On Tue, 12 Dec 2023 16:36:35 +
> Simon Ser 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 li
On Tue, 12 Dec 2023 16:36:35 +
Simon Ser 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
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.
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 u
12 matches
Mail list logo
