linux-kernel - Re: [PATCH] drm/ttm: provide default page protection for UML

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Sep 2021 10:56:36 +0200
From:   Christian König <christian.koenig@....com>
To:     Johannes Berg <johannes@...solutions.net>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-kernel@...r.kernel.org
Cc:     Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>, Huang Rui <ray.huang@....com>,
        dri-devel@...ts.freedesktop.org, Jeff Dike <jdike@...toit.com>,
        Richard Weinberger <richard@....at>,
        linux-um@...ts.infradead.org, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] drm/ttm: provide default page protection for UML

Am 02.09.21 um 09:43 schrieb Johannes Berg:
> On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
>>>> I have a question though - why all of DRM is not !UML in config. Not
>>>> like we can use them.
>>> I have no idea about that.
>>> Hopefully one of the (other) UML maintainers can answer you.
>> Touche.
>>
>> We will discuss that and possibly push a patch to !UML that part of the
>> tree. IMHO it is not applicable.
> As I just said on the other patch, all of this is fallout from my commit
> 68f5d3f3b654 ("um: add PCI over virtio emulation driver") which is the
> first time that you could have PCI on UML.
>
> Without having checked, in this particular case it's probably something
> like
>
> 	depends on PCI && X86_64
>
> as we've seen in other drivers (idxd, ioat).
>
> The biggest problem is probably that UML internally uses X86_64
> (arch/x86/um/Kconfig), which is ... unexpected ... since CONFIG_X86_64
> is typically considered the ARCH, and now the ARCH is actually um.

Yeah, as TTM maintainer I was about to NAK that approach here.

Basically you are claiming to be X86_64, but then you don't use the 
X86_64 architecture and are surprised that it things break somewhere else.

This is not something you can blame on subsystems or even drivers, but 
rather just a broken architectural design and so needs to be fixed there.

Regards,
Christian.

>
> I think we can just fix that and get rid of this entire class of
> problems? Something like
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp.sipsolutions.net%2Ffbac19d86637e286.txt&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7Cd773b1e8b66643874d1308d96de56a86%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637661654674393046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xBT%2Fj%2FbEgltQfvE%2B7%2FGRV7IctGn3sDvy8ycmBvTTSXU%3D&amp;reserved=0
>
> johannes
>
>