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:   Sun, 12 Jun 2022 10:58:20 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     "Michael S. Tsirkin" <mst@...hat.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>
Cc:     Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        kernel@...s.com, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
        Jason Wang <jasowang@...hat.com>, linux-um@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] um: virt-pci: set device ready in probe()

On Fri, 2022-06-10 at 20:34 -0400, Michael S. Tsirkin wrote:
> 
> Also fixes this commit:
> 
> commit 68f5d3f3b6543266b29e047cfaf9842333019b4c
> Author: Johannes Berg <johannes.berg@...el.com>
> Date:   Fri Mar 5 13:19:58 2021 +0100
> 
>     um: add PCI over virtio emulation driver

Hm, why? It worked before the harden change.

> BTW Johannes I think you need to spec this device and get
> an ID - what's the plan for that? Current hack of punting
> this to userspace isn't really any good long term.

Yeah, agree, it dropped off my radar (and the process is a bit
cumbersome IMHO).

But I'm not quite sure what you mean wrt. "punting to userspace", here
in the virt-pci code I'm punting to the Kconfig :-)

Did you just mix that up, or was there some additional userspace thing
you're thinking of?

The only userspace thing I can think of it is in virtio_uml where you
have the ID on the command-line, but that's because it implements the
virtio device bus over vhost-user which doesn't have ID discoverability
in the protocol. That could also be fixed I guess, but it's a bit of a
chicken & egg problem, if you don't have the ID and discovering it were
not supported, you'd end up with an unusable device unless you specified
the ID, in which case you don't need to discover it...

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ