lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dbcd9a16-4e4b-42c8-ba7f-d6c1dfd9dccb@gmail.com>
Date: Mon, 1 Jul 2024 10:41:04 +0200
From: Christian König <ckoenig.leichtzumerken@...il.com>
To: Nicolas Dufresne <nicolas@...fresne.ca>,
 Christian König <christian.koenig@....com>,
 Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>,
 "daniel@...ll.ch" <daniel@...ll.ch>
Cc: "quic_vjitta@...cinc.com" <quic_vjitta@...cinc.com>,
 "angelogioacchino.delregno@...labora.com"
 <angelogioacchino.delregno@...labora.com>,
 "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "jkardatzke@...gle.com" <jkardatzke@...gle.com>,
 "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
 "joakim.bech@...aro.org" <joakim.bech@...aro.org>,
 Youlin Pei (裴友林) <youlin.pei@...iatek.com>,
 "logang@...tatee.com" <logang@...tatee.com>,
 "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
 Kuohong Wang (王國鴻) <kuohong.wang@...iatek.com>,
 Jianjiao Zeng (曾健姣)
 <Jianjiao.Zeng@...iatek.com>, "contact@...rsion.fr" <contact@...rsion.fr>,
 "benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>,
 "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
 "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
 "willy@...radead.org" <willy@...radead.org>, "pavel@....cz" <pavel@....cz>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "Brian.Starkey@....com" <Brian.Starkey@....com>,
 "robh+dt@...nel.org" <robh+dt@...nel.org>,
 "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "tjmercier@...gle.com" <tjmercier@...gle.com>,
 "jstultz@...gle.com" <jstultz@...gle.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "mripard@...nel.org" <mripard@...nel.org>,
 "robin.murphy@....com" <robin.murphy@....com>,
 Yong Wu (吴勇) <Yong.Wu@...iatek.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "ppaalanen@...il.com" <ppaalanen@...il.com>
Subject: Re: [Linaro-mm-sig] Re: [PATCH v5 2/9] scatterlist: Add a flag for
 the restricted memory

Am 28.06.24 um 22:16 schrieb Nicolas Dufresne:
> [SNIP]
>>>>> Why can't you get this information from userspace?
>>>> Same reason amd and i915/xe also pass this around internally in the
>>>> kernel, it's just that for those gpus the render and kms node are the
>>>> same
>>>> driver so this is easy.
>>>>
>> The reason I ask is that encryption here looks just like another
>> parameter for the buffer, e.g. like format, stride, tilling etc..
> I'm mostly a reader of the thread here, but I'd like to avoid basic mistakes.
> The buffer in question are "protected", meaning that the CPU HW does not have
> access to the underlying pages (or zone in the case of Meditatek).
>
> This is different from encrypted buffers, which don't need this level of
> protection, as without the security key to decrypt them, their content is close
> to random data.

Thanks for that clarification, this difference was absolutely not obvious.

In that case having a separate heap for this memory is indeed the 
easiest approach.

My question is still what would happen if the CPU tries to access this 
protected buffer? Or does the CPU not even have an address to do that?

Just out of curiosity, I mean the exporting heap should then somehow 
reject any attempt to mmap() or vmap() the buffer content.

Thanks,
Christian.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ