linux-kernel - Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation

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]

Message-ID: <20120905191657.GA15868@redhat.com>
Date:	Wed, 5 Sep 2012 22:16:57 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Sjur Brændeland <sjurbren@...il.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Amit Shah <amit.shah@...hat.com>, linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>,
	virtualization@...ts.linux-foundation.org,
	Sjur Brændeland 
	<sjur.brandeland@...ricsson.com>
Subject: Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation

On Wed, Sep 05, 2012 at 08:15:36PM +0200, Sjur Brændeland wrote:
> Hi Michael.
> 
> >> If the device then asks for VIRTIO_CONSOLE_F_DMA_MEM
> >> when DMA is not supported, virtio will do BUG_ON() from
> >> virtio_check_driver_offered_feature().
> >>
> >> Is this acceptable or should we add a check in virtcons_probe()
> >> and let the probing fail instead?
> >>
> >> E.g:
> >>       /* Refuse to bind if F_DMA_MEM request cannot be met */
> >>       if (!VIRTIO_CONSOLE_HAS_DMA &&
> >>           (vdev->config->get_features(vdev) & (1 << VIRTIO_CONSOLE_F_DMA_MEM))){
> >>               dev_err(&vdev->dev,
> >>                       "DMA_MEM requested, but arch does not support DMA\n");
> >>               err = -EINVAL;
> >>               goto fail;
> >>       }
> >>
> >> Regards,
> >> Sjur
> >
> > Failing probe would be cleaner. But there is still a problem:
> > old driver will happily bind to that device and then
> > fail to work, right?
> 
> Not just fail to work, the kernel will panic on the BUG_ON().
> Remoteproc gets the virtio configuration from firmware loaded
> from user space. So this type of problem might be triggered
> for other virtio drivers as well.

how?

> 
> > virtio pci has revision id for this, but remoteproc doesn't
> > seem to have anything similar. Or did I miss it?
> 
> No there are currently no sanity check of
> virtio type and feature bits in remoteproc.
> One option may be to add this...

you can not fix the past.

> > If not -
> > we probably need to use a different
> > device id, and not a feature bit.
> 
> But if I create a new virtio console type, remoteproc
> could still call the existing virtio_console with random
> bad feature bits, causing kernel panic.

cirtio core checks device id - this should not happen.


> Even if we fix this particular problem, the general problem
> still exists: bogus virtio declarations in remoteproc's firmware
> may cause BUG_ON().

which BUG_ON exactly?

> (Note the fundamental difference
> between visualizations and remoteproc. For remoteproc
> the virtio configuration comes from binaries loaded from
> user space).
> 
> So maybe we should look for a more generic solution, e.g.
> changing virtio probe functionality so that devices with
> bad feature bits will not trigger BUG_ON(), but rather refuse
> to bind the driver.
> 
> Regards,
> Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/