From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02CFFC433B4 for ; Tue, 20 Apr 2021 12:50:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B6C9F613C7 for ; Tue, 20 Apr 2021 12:50:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232087AbhDTMut (ORCPT ); Tue, 20 Apr 2021 08:50:49 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:16144 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230408AbhDTMus (ORCPT ); Tue, 20 Apr 2021 08:50:48 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FPk3R0lJvzpZfN; Tue, 20 Apr 2021 20:47:15 +0800 (CST) Received: from [10.67.102.118] (10.67.102.118) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Tue, 20 Apr 2021 20:50:12 +0800 Subject: Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio To: Jason Gunthorpe CC: , , , References: <1618284983-55581-1-git-send-email-liulongfang@huawei.com> <1618284983-55581-3-git-send-email-liulongfang@huawei.com> <20210415220137.GA1672608@nvidia.com> <10d53c5d-e6d5-a165-84b2-eaf8a3b7dcce@huawei.com> <20210419123314.GT1370958@nvidia.com> From: liulongfang Message-ID: <00c4fa43-21fa-a48b-b95d-a2310ffab725@huawei.com> Date: Tue, 20 Apr 2021 20:50:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210419123314.GT1370958@nvidia.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.118] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/4/19 20:33, Jason Gunthorpe wrote: > On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote: > >>> I'm also confused how this works securely at all, as a general rule a >>> VFIO PCI driver cannot access the MMIO memory of the function it is >>> planning to assign to the guest. There is a lot of danger that the >>> guest could access that MMIO space one way or another. >> >> VF's MMIO memory is divided into two parts, one is the guest part, >> and the other is the live migration part. They do not affect each other, >> so there is no security problem. > > AFAIK there are several scenarios where a guest can access this MMIO > memory using DMA even if it is not mapped into the guest for CPU > access. > The hardware divides VF's MMIO memory into two parts. The live migration driver in the host uses the live migration part, and the device driver in the guest uses the guest part. They obtain the address of VF's MMIO memory in their respective drivers, although these two parts The memory is continuous on the hardware device, but due to the needs of the drive function, they will not perform operations on another part of the memory, and the device hardware also independently responds to the operation commands of the two parts. So, I still don't understand what the security risk you are talking about is, and what do you think the security design should look like? Can you elaborate on it? >> If pci_release_mem_regions() is not added here, >> The guests using pci_request_mem_regions() will return an error. >> Then, the guest will not be able to obtain the MMIO address of the VF. > > Which is why VFIO has this protection to prevent sharing MMIO regions > on the VF assigned to the guest > > Jason > . > Thanks. Longfang.