Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e90caaaa-cae9-c6d1-bfb6-dc56aa559681@amd.com>
Date:   Mon, 8 Aug 2022 13:22:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Add ioctl to query mmap info
Content-Language: en-US
To:     Rob Clark <robdclark@gmail.com>,
        =?UTF-8?Q?Christian_K=c3=b6nig?= <ckoenig.leichtzumerken@gmail.com>
Cc:     dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
        freedreno@lists.freedesktop.org,
        Rob Clark <robdclark@chromium.org>,
        Sumit Semwal <sumit.semwal@linaro.org>,
        =?UTF-8?B?SsOpcsO0bWUgUG91aWxsZXI=?= <jerome.pouiller@silabs.com>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@vger.kernel.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@lists.linaro.org>,
        open list <linux-kernel@vger.kernel.org>
References: <20220729170744.1301044-1-robdclark@gmail.com>
 <20220729170744.1301044-2-robdclark@gmail.com>
 <3d2083aa-fc6c-6875-3daf-e5abe45fb762@gmail.com>
 <CAF6AEGvKdM3vyCvBZK=ZcdGmak7tsrP1b8ANyyaMjVfNDViqyw@mail.gmail.com>
 <973de2f8-75e4-d4c7-a13a-c541a6cf7c77@amd.com>
 <CAF6AEGuhQT6A_jh8kLWh5xMoUGc1osdewyBk-8NoprtWOHseaQ@mail.gmail.com>
 <2fc74efe-220f-b57a-e804-7d2b3880d14f@gmail.com>
 <CAF6AEGv9H+fSFKPNqwPxYUjkgj05AimpXbp-p_JL8nKLnzON=w@mail.gmail.com>
 <e2423bd7-ef73-8d43-c661-a19c80ad1a26@gmail.com>
 <CAF6AEGsoYaXe2+qug_TfT99KXuXh9Ez2L2HjQZroE6c6GSW4SQ@mail.gmail.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <CAF6AEGsoYaXe2+qug_TfT99KXuXh9Ez2L2HjQZroE6c6GSW4SQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OWtsK1RPbVFQRHdpZEEyZWZWTVEzcW1KY0d5L0pXd3BTZkNuWlIrbkJUdU5I?=
 =?utf-8?B?WWFBc2hVVnM2ZVBVWWtTNHVZQWw5Ymp5OWROY2M5bVh4TjVLQkgzcHp5T3hN?=
 =?utf-8?B?WG40R0p3R3lKVjRGbjAwdnFnOXFwTVRFa1FvMXArZGV3MUNmbkp2YnRLNWZL?=
 =?utf-8?B?RHc5Z2lROGUyTHdYZEh4ZmRyVlpDN1lPME9MZW9lV3lQQTFzZ3dWSHIrWits?=
 =?utf-8?B?QWZrb3BLakNRWVljaTVZOE1yR0dlK2NjZE1oVm1XMFN5L0JGTTEwUFNrajRk?=
 =?utf-8?B?ajJBSFZ3aEZRdG8zQXpDQU9Mc3kxcWsrNFZKQmpzVlMzcVRMNE1tQWVGdkdj?=
 =?utf-8?B?amN4VUpQbldJNW5jN1cvSFJDcmhXbmtNbjlZWmMyc09IOGFpZ2xnamNKemNE?=
 =?utf-8?B?ZTFnd1B5Nmxmak5Tb2h3TzhZUkpVMGFWZDA0VmR1Sy8wb2c2aTEwRjROSnJy?=
 =?utf-8?B?ZStMc3QrWU1OYlRnR2NjaFFlU2dLRjY1YlRmYklXVEpvRDRxS3J1NHZEeERq?=
 =?utf-8?B?YUhzVklnU1lTQVlaYy90cjhsNEJkWjBiOFhFNkExNjlmdmZ5OG5LVDR4V0Fw?=
 =?utf-8?B?Rmh4am0rZm9sV3cvV2UzYlEyZ3FFQVdyUTF1QXI3WDBCVU1lN2FXUTZ5ZHlR?=
 =?utf-8?B?Unl6Z3lld2xmeXFRaHBwSFh4ckNCMW9uKzlhenpCcDZ0aWR3dUxsYkhjYW9L?=
 =?utf-8?B?MTQxN1gyQXZHRGprZUtJdmFnTXRuamxmVVNZelU2VGZ0QTFtM3hjbGNUUWZt?=
 =?utf-8?B?QlJsZlcreXhkcGRGT291cmNoN0FOeHRnWnVMOU9oK0NYOHVTUU0rU0pKRDdt?=
 =?utf-8?B?a2Q5UXJWaGhmalpIak03c2pOYVZkVTBaTy9EOEN3aVVNNklwckpTeHAzTDdE?=
 =?utf-8?B?TitBUGdVaVdkZ0RxeXkzWDlJZGd4TnFGTzhHQ3NUOVhCVnh2R3NkZU1FOFF1?=
 =?utf-8?B?eExDdTNXYjRJaXZSejU5NEpINU9qank3QWgwR25oVXdKMnFVWGdvUXV0OWE5?=
 =?utf-8?B?NTVkNlRFSXBVWkdhSnMySGlpd3JSR3NUbDlCanpaQmpZMGxvc1NVelNmVFl4?=
 =?utf-8?B?UklRcnlaUVFBTHVOdXhVS2Vaa240ZHpPdTc1WkFyN2lWdWs2VEJhcHQ0QWpR?=
 =?utf-8?B?aFIrNUZKMEo0L01VclBRd3htRmtlOEZsZXRnU3RaVUhCMGt1Wm5KTm9CVnNP?=
 =?utf-8?B?S3AxZ2FRQjVPWEI5TzkzejhiVWw5OG45RWt4S0I5eDg0VHRoMnVYUkllZkpq?=
 =?utf-8?B?VDdMTklWTDI1Z2srb0MvbGs2MXJwYTVmSk1oVlQ3S0M4bkw5QzdQdXRDRVhi?=
 =?utf-8?B?MFJGd3NrQmJidENkZ2IrLzRtQmQ4WWlncmlzTGVTNGNyaW1ST0RxSndRd0RW?=
 =?utf-8?B?Zm1tQVBtR0x0Q2Z3NGNVSkN5eUUrYUIyOGJJN3RLb1c1RnJzOGNPZk1UV0ZL?=
 =?utf-8?B?bWxJdHlqQVI3WjhDTFNNYjhtRTJnL0FBYzBDeERzaWF1MVEwTDBBZnVCMW5O?=
 =?utf-8?B?NHZLUFA5NVNxMm9aL3JIQkU2ZlV0cHZKbmQ2NmJhYlFlbUQxakduSThpV2NM?=
 =?utf-8?B?T1ZMTnNyWDZFdkp6N2k4MCszczB0blNVeEZhSVJPbDhQZUtuRkZickpZa0xx?=
 =?utf-8?B?Nm5SN2duQWpBYWNQd3JqUFppVXA4Vkl5ZWxqNVprdFk0bUloNlExVXg4bjdU?=
 =?utf-8?B?Z29vVDhUY2xWWWhKTXF6V0ZXZEkwS1crUjBZdGVpOGtvY3RtZXgxajljeWF0?=
 =?utf-8?B?aEg2anFwb0FXK0NqSGc0Wm5yRU9NQ3VjK1BKRkZvRjdWMHNLbnNTUHdNeFJV?=
 =?utf-8?B?amdUMU9DQ3JWL084eDJhQ0lodGNlUEV2Q2N4ZnVSclZGcUtuaXdURTducnZx?=
 =?utf-8?B?NTRiTzdyZjFqZnVXYU00VjhzbThjREFObEkvOEJOdmNVS1pia3JQY2J4WGJa?=
 =?utf-8?B?S3lEQUF6TTdJZU0rUFB3YnAwREx1ZnhYODJGdjZkbWNROElOd0VZQ1piM3Bn?=
 =?utf-8?B?Y3RweHpMWlJKeUd0TjF0OWVKM2habkhjdktMUCtJTlVKVFloUk5GaXhLekJu?=
 =?utf-8?B?TGJyRk5jN2s0UlhjQXVJaS9IbE9sRUNjM1hteERLNTMwdzBSSkhKeUs5ZDJC?=
 =?utf-8?B?K1BYRlY0NzhsOFVzSmNoQjRWQUd0NGJlMU9SZC9xejhWWDRnYk1vbEMybVRJ?=
 =?utf-8?Q?ySkCAu0IcpbOq+I0/3h9JvumiZKqUA2nV24hCeHgki2l?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a0dc593-2441-4ce0-305c-08da79303c22
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2022 11:22:10.1861
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dGmu1rm43Ddd2kR/Ugy+qnzRg+rYMaRSW+WQMRTAlB+0Xq0h8dbXdL0hsn2WP9wb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR12MB2836
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 07.08.22 um 21:10 schrieb Rob Clark:
> On Sun, Aug 7, 2022 at 11:05 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Am 07.08.22 um 19:56 schrieb Rob Clark:
>>> On Sun, Aug 7, 2022 at 10:38 AM Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>> [SNIP]
>>>> And exactly that was declared completely illegal the last time it came
>>>> up on the mailing list.
>>>>
>>>> Daniel implemented a whole bunch of patches into the DMA-buf layer to
>>>> make it impossible for KVM to do this.
>>> This issue isn't really with KVM, it is not making any CPU mappings
>>> itself.  KVM is just making the pages available to the guest.
>> Well I can only repeat myself: This is strictly illegal.
>>
>> Please try this approach with CONFIG_DMABUF_DEBUG set. I'm pretty sure
>> you will immediately run into a crash.
>>
>> See this here as well
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.19%2Fsource%2Fdrivers%2Fdma-buf%2Fdma-buf.c%23L653&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7Cc1392f76994f4fef7c7f08da78a86283%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637954961892996770%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=T3g9ICZizCWXkIn5vEnhFYs38Uj37jCwHjMb1s3UtOw%3D&amp;reserved=0
>>
>> Daniel intentionally added code to mangle the page pointers to make it
>> impossible for KVM to do this.
> I don't believe KVM is using the sg table, so this isn't going to stop
> anything ;-)

Then I have no idea how KVM actually works. Can you please briefly 
describe that?

>> If the virtio/virtgpu UAPI was build around the idea that this is
>> possible then it is most likely fundamental broken.
> How else can you envision mmap'ing to guest userspace working?

Well long story short: You can't.

See userspace mappings are not persistent, but rather faulted in on 
demand. The exporter is responsible for setting those up to be able to 
add reverse tracking and so can invalidate those mappings when the 
backing store changes.

> The guest kernel is the one that controls the guest userspace pagetables,
> not the host kernel.  I guess your complaint is about VMs in general,
> but unfortunately I don't think you'll convince the rest of the
> industry to abandon VMs ;-)

I'm not arguing against the usefulness of VM, it's just that what you 
describe here technically is just utterly nonsense as far as I can tell.

I have to confess that I'm totally lacking how this KVM mapping works, 
but when the struct pages pointers from the sg_table are not used I see 
two possibilities what was implemented here:

1. KVM is somehow walking the page tables to figure out what to map into 
the guest VM.

     This would be *HIGHLY* illegal and not just with DMA-buf, but with 
pretty much a whole bunch of other drivers/subsystems as well.
     In other words it would be trivial for the guest to take over the 
host with that because it doesn't take into account that the underlying 
backing store of DMA-buf and other mmaped() areas can change at any time.

2. The guest VM triggers the fault handler for the mappings to fill in 
their page tables on demand.

     That would actually work with DMA-buf, but then the guest needs to 
somehow use the caching attributes from the host side and not use it's own.
     Because otherwise you can't accommodate that the exporter is 
changing those caching attributes.

> But more seriously, let's take a step back here.. what scenarios are
> you seeing this being problematic for?  Then we can see how to come up
> with solutions.  The current situation of host userspace VMM just
> guessing isn't great.

Well "isn't great" is a complete understatement. When KVM/virtio/virtgpu 
is doing what I guess they are doing here then that is a really major 
security hole.

>    And sticking our heads in the sand and
> pretending VMs don't exist isn't great.  So what can we do?  I can
> instead add a msm ioctl to return this info and solve the problem even
> more narrowly for a single platform.  But then the problem still
> remains on other platforms.

Well once more: This is *not* MSM specific, you just absolutely *can't 
do that* for any driver!

I'm just really wondering what the heck is going on here, because all of 
this was discussed in lengthy before on the mailing list and very 
bluntly rejected.

Either I'm missing something (that's certainly possible) or we have a 
strong case of somebody implementing something without thinking about 
all the consequences.

Regards,
Christian.


>
> Slightly implicit in this is that mapping dma-bufs to the guest won't
> work for anything that requires DMA_BUF_IOCTL_SYNC for coherency.. we
> could add a possible return value for DMA_BUF_INFO_VM_PROT indicating
> that the buffer does not support mapping to guest or CPU access
> without DMA_BUF_IOCTL_SYNC.  Then at least the VMM can fail gracefully
> instead of subtly.
>
> BR,
> -R