linux-kernel - Re: [qemu-s390x] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

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, 11 Jun 2018 18:00:50 +0200
From:   Cornelia Huck <cohuck@...hat.com>
To:     Halil Pasic <pasic@...ux.ibm.com>
Cc:     Pierre Morel <pmorel@...ux.ibm.com>, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        qemu-devel@...gnu.org, qemu-s390x@...gnu.org,
        Dong Jia Shi <bjsdjshi@...ux.ibm.com>
Subject: Re: [qemu-s390x] [PATCH RFC 2/2] vfio-ccw: support for halt/clear
 subchannel

On Fri, 8 Jun 2018 22:40:39 +0200
Halil Pasic <pasic@...ux.ibm.com> wrote:

[I'm trying to not make the discussion branch out too much. Just
replying one more time here (and I'll add something to the wiki).]

> One can probably argue that setting cc 0 even if the host device
> responds to the host ssch with cc 3 because the device is not any more
> on the given subchannel or simply just disabled. It is probably true
> that the guest would not have any means to prove that we were 'lying'
> to it.

I would not frame this as 'lying'. We have an additional layer
inbetween, adding additional complications. As long as we reflect
something to the guest that (a) is covered by the architecture, and (b)
enables the guest to make reasonable decisions, we're fine.

> 
> But AFAIR this is not how the current implementation works. The pwrite
> in qemu basically depends on the cc of the host ssch. So if the host
> ssch completes with cc 3 the vfio-ccw kernel module map ist to pwrite
> reporting -ENODEV and vfio_ccw_handle_request makes sure that the
> guest instruction completes with cc 3 by mapping it to return code
> IOINST_CC_NOT_OPERATIONAL.

Will need to review the code again. But this behaviour is fine as well
by my reasoning above :)

> 
> I mentioned xsch in the other thread. I don't think we can tell if
> cc 0 or cc 2. In my reading xsch in simple words xsch completes with
> cc 2 and does nothing else if the channel subsystem already started talking
> to the cu/device. If in time it makes sure we don't start talking to the
> device, and clear away stuff. So if we don't consider cc of the xsch
> to be issued by the host the only safe bet seems to be cc 2. But that's
> effectively getting around implementing the desired functionality of
> xsch and still staying architecturally correct. Which however might
> be good enough for vfio-ccw. But I think I demonstrated it's kinda
> tricky business.

I'm wondering if we should simply give the guest a cc 2 in any case as
well.
> 
> I prefer to avoid tricky if there is no good reason not to.