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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGQfszAGGKhCp20q@nvidia.com>
Date:   Tue, 16 May 2023 21:28:35 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     ankita@...dia.com, aniketa@...dia.com, cjia@...dia.com,
        kwankhede@...dia.com, targupta@...dia.com, vsethi@...dia.com,
        acurrid@...dia.com, apopple@...dia.com, jhubbard@...dia.com,
        danw@...dia.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        yishaih@...dia.com, shameerali.kolothum.thodi@...wei.com,
        kevin.tian@...el.com
Subject: Re: [PATCH v2 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper

On Tue, May 16, 2023 at 03:09:14PM -0600, Alex Williamson wrote:

> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config NVGPU_VFIO_PCI
> > +	tristate "VFIO support for the GPU in the NVIDIA Grace Hopper Superchip"
> > +	depends on ARM64 || (COMPILE_TEST && 64BIT)
> > +	select VFIO_PCI_CORE
> 
> I think this should be a 'depends on' as well, that's what we have for
> the other vfio-pci variant drivers.

It should be removed completely, AFAICT:

config VFIO_PCI
        tristate "Generic VFIO support for any PCI device"
        select VFIO_PCI_CORE

Ensures it is turned on

if VFIO_PCI
source "drivers/vfio/pci/mlx5/Kconfig"
endif

Autoamtically injects a 'depends on VFIO_PCI' to all the enclosed
kconfig statements (and puts them nicely in the menu)

So we have everything needed already

SELECT is the correct action since it doesn't have a config text.

> Is our test for vm_end < vm_start in vfio-pci-core just paranoia?  I
> don't see an equivalent here.

Yes, mm core will not invoke the op with something incorrect.
 
> Can we also get a comment in the code outlining the various reasons
> that this "BAR" doesn't need the disabled access protections that
> vfio-pci-core implements?  For example outlining the behavior relative
> to BAR access while the memory enable bit is disabled, the bus being in
> reset, or the device being in a low-power state.

The HW has some "isolation" feature that kicks in and safely
disconnects the GPU from the CPU.

A lot of work has been done to make things like VFIO and KVM safe
against machine checks/etc under basically all circumstances.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ