linux-kernel - Re: [PATCH v3] drm/ttm: Make sure the mapped tt pages are decrypted when needed

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]

Date: Fri, 26 Jan 2024 14:38:16 +0100
From: Christian König <christian.koenig@....com>
To: Zack Rusin <zack.rusin@...adcom.com>, dri-devel@...ts.freedesktop.org
Cc: Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
 Huang Rui <ray.huang@....com>, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH v3] drm/ttm: Make sure the mapped tt pages are decrypted
 when needed

Am 26.01.24 um 06:10 schrieb Zack Rusin:
> On Fri, Jan 5, 2024 at 8:51 AM Zack Rusin <zack.rusin@...adcom.com> wrote:
>> Some drivers require the mapped tt pages to be decrypted. In an ideal
>> world this would have been handled by the dma layer, but the TTM page
>> fault handling would have to be rewritten to able to do that.
>>
>> A side-effect of the TTM page fault handling is using a dma allocation
>> per order (via ttm_pool_alloc_page) which makes it impossible to just
>> trivially use dma_mmap_attrs. As a result ttm has to be very careful
>> about trying to make its pgprot for the mapped tt pages match what
>> the dma layer thinks it is. At the ttm layer it's possible to
>> deduce the requirement to have tt pages decrypted by checking
>> whether coherent dma allocations have been requested and the system
>> is running with confidential computing technologies.
>>
>> This approach isn't ideal but keeping TTM matching DMAs expectations
>> for the page properties is in general fragile, unfortunately proper
>> fix would require a rewrite of TTM's page fault handling.
>>
>> Fixes vmwgfx with SEV enabled.
>>
>> v2: Explicitly include cc_platform.h
>> v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
>> limit the scope to guests and log when memory decryption is enabled.
> Hi, Christian.
>
> Gentle ping on that one. This is probably the cleanest we can get this
> code. Can we land this or is there anything else you'd like to see?

Sorry for the delay.

I'm not too familiar with the technical background, so I can't 100% 
judge if this is correct or not.

But if it works for you I think we should give it a try, feel free to 
add my Acked-by and push upstream through whatever branch you like.

Regards,
Christian.

>
> z