linux-kernel - RE: [RFC PATCH 1/5] nvme-pci: add function nvme_submit_vf_cmd to issue admin commands for VF driver.

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:   Fri, 9 Dec 2022 02:11:21 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Christoph Hellwig <hch@....de>, Max Gurtovoy <mgurtovoy@...dia.com>
CC:     Jason Gunthorpe <jgg@...pe.ca>, "Rao, Lei" <lei.rao@...el.com>,
        "kbusch@...nel.org" <kbusch@...nel.org>,
        "axboe@...com" <axboe@...com>, "kch@...dia.com" <kch@...dia.com>,
        "sagi@...mberg.me" <sagi@...mberg.me>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "yishaih@...dia.com" <yishaih@...dia.com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        "mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Dong, Eddie" <eddie.dong@...el.com>,
        "Li, Yadong" <yadong.li@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Wilk, Konrad" <konrad.wilk@...cle.com>,
        "stephen@...eticom.com" <stephen@...eticom.com>,
        "Yuan, Hang" <hang.yuan@...el.com>
Subject: RE: [RFC PATCH 1/5] nvme-pci: add function nvme_submit_vf_cmd to
 issue admin commands for VF driver.

> From: Christoph Hellwig <hch@....de>
> Sent: Wednesday, December 7, 2022 3:59 PM
> 
> On Wed, Dec 07, 2022 at 04:30:20AM +0200, Max Gurtovoy wrote:
> > I'm not sure how awkward is for migration driver to ask the controlling
> > device driver to operate a migration action.
> 
> It can't.  That's the whole point.  The controlled function that is
> being migrate must be absolutely unaware of that (except for things
> like quiescing access or FLRs that could happen anyway), because
> otherwise your have a fundamental information leak.
> 

Can you elaborate which information is leaked?

No matter who provides the uAPI (controlling or controlled), end of
the day it's the same cmd invoked on the controlling device to save/
restore the state of the controlled device itself.