linux-kernel - RE: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed

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:   Mon, 9 Dec 2019 12:01:38 +0000
From:   "Durrant, Paul" <pdurrant@...zon.com>
To:     Roger Pau Monné <roger.pau@...rix.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "Juergen Gross" <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "Boris Ostrovsky" <boris.ostrovsky@...cle.com>
Subject: RE: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to
 closed

> -----Original Message-----
> From: Roger Pau Monné <roger.pau@...rix.com>
> Sent: 09 December 2019 11:39
> To: Durrant, Paul <pdurrant@...zon.com>
> Cc: linux-kernel@...r.kernel.org; xen-devel@...ts.xenproject.org; Juergen
> Gross <jgross@...e.com>; Stefano Stabellini <sstabellini@...nel.org>;
> Boris Ostrovsky <boris.ostrovsky@...cle.com>
> Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to
> closed
> 
> On Thu, Dec 05, 2019 at 02:01:21PM +0000, Paul Durrant wrote:
> > Only force state to closed in the case when the toolstack may need to
> > clean up. This can be detected by checking whether the state in xenstore
> > has been set to closing prior to device removal.
> 
> I'm not sure I see the point of this, I would expect that a failure to
> probe or the removal of the device would leave the xenbus state as
> closed, which is consistent with the actual driver state.
> 
> Can you explain what's the benefit of leaving a device without a
> driver in such unknown state?
> 

If probe fails then I think it should leave the state alone. If the state is moved to closed then basically you just killed that connection to the guest (as the frontend will normally close down when it sees this change) so, if the probe failure was due to a bug in blkback or, e.g., a transient resource issue then it's game over as far as that guest goes.
The ultimate goal here is PV backend re-load that is completely transparent to the guest. Modifying anything in xenstore compromises that so we need to be careful.

  Paul