From: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>,
Jiang Liu <jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
James Smart <jsmart2021-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: kernel BUG at drivers/iommu/intel-iommu.c:608
Date: Mon, 08 Apr 2019 08:30:27 -0700 [thread overview]
Message-ID: <1554737427.118779.271.camel@acm.org> (raw)
In-Reply-To: <20190408092345.01751472-hfcDOgR9qeA@public.gmane.org>
On Mon, 2019-04-08 at 09:23 -0600, Alex Williamson wrote:
> Loading modules is privileged:
>
> $ modprobe vfio-pci
> modprobe: ERROR: could not insert 'vfio_pci': Operation not permitted
>
> Granting a device to a user for device assignment purposes is also a
> privileged operation. Can you describe a scenario where this is
> reachable without elevated privileges? The driver core maintainer has
> indicated previously that manipulation of driver binding is effectively
> at your own risk. It's entirely possible to bind devices to the wrong
> driver creating all sorts of bad behavior. In this case, it appears
> that the system has been improperly configured if devices from a user
> owned group can accidentally be bound to host drivers.
No user space action should ever crash the kernel, whether or not it
is a privileged action and whether or not a configuration mistake is
involved. The only exception are actions that are intended to crash
the kernel, e.g. SysRq-c. I'm surprised that I have to explain this.
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <bvanassche@acm.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: iommu@lists.linux-foundation.org, Joerg Roedel <jroedel@suse.de>,
Jiang Liu <jiang.liu@linux.intel.com>,
James Smart <jsmart2021@gmail.com>
Subject: Re: kernel BUG at drivers/iommu/intel-iommu.c:608
Date: Mon, 08 Apr 2019 08:30:27 -0700 [thread overview]
Message-ID: <1554737427.118779.271.camel@acm.org> (raw)
Message-ID: <20190408153027.4JWySmZaP8DT3Lfe-RoXcXaGgn4S9p8YQxOP9FhZbbw@z> (raw)
In-Reply-To: <20190408092345.01751472@x1.home>
On Mon, 2019-04-08 at 09:23 -0600, Alex Williamson wrote:
> Loading modules is privileged:
>
> $ modprobe vfio-pci
> modprobe: ERROR: could not insert 'vfio_pci': Operation not permitted
>
> Granting a device to a user for device assignment purposes is also a
> privileged operation. Can you describe a scenario where this is
> reachable without elevated privileges? The driver core maintainer has
> indicated previously that manipulation of driver binding is effectively
> at your own risk. It's entirely possible to bind devices to the wrong
> driver creating all sorts of bad behavior. In this case, it appears
> that the system has been improperly configured if devices from a user
> owned group can accidentally be bound to host drivers.
No user space action should ever crash the kernel, whether or not it
is a privileged action and whether or not a configuration mistake is
involved. The only exception are actions that are intended to crash
the kernel, e.g. SysRq-c. I'm surprised that I have to explain this.
Bart.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-04-08 15:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-07 19:10 kernel BUG at drivers/iommu/intel-iommu.c:608 Bart Van Assche
2019-04-07 19:10 ` Bart Van Assche
[not found] ` <a523ea10-3dab-fa2c-1ecf-5cf32077565f-HInyCGIudOg@public.gmane.org>
2019-04-07 21:06 ` Alex Williamson
2019-04-07 21:06 ` Alex Williamson
[not found] ` <20190407150650.060cc508-hfcDOgR9qeA@public.gmane.org>
2019-04-07 23:02 ` Bart Van Assche
2019-04-07 23:02 ` Bart Van Assche
[not found] ` <8d876549-21da-e027-0157-8737b10e26f8-HInyCGIudOg@public.gmane.org>
2019-04-07 23:31 ` Alex Williamson
2019-04-07 23:31 ` Alex Williamson
[not found] ` <20190407173132.24032810-hfcDOgR9qeA@public.gmane.org>
2019-04-08 15:13 ` Bart Van Assche
2019-04-08 15:13 ` Bart Van Assche
[not found] ` <1554736414.118779.265.camel-HInyCGIudOg@public.gmane.org>
2019-04-08 15:23 ` Alex Williamson
2019-04-08 15:23 ` Alex Williamson
[not found] ` <20190408092345.01751472-hfcDOgR9qeA@public.gmane.org>
2019-04-08 15:30 ` Bart Van Assche [this message]
2019-04-08 15:30 ` Bart Van Assche
2019-04-08 15:55 ` Christoph Hellwig
2019-04-08 15:55 ` Christoph Hellwig
2019-04-08 17:10 ` Robin Murphy
2019-04-08 17:10 ` Robin Murphy
[not found] ` <c5511683-9739-9c74-418b-cf2aed6b294a-5wv7dgnIgG8@public.gmane.org>
2019-04-08 18:05 ` Alex Williamson
2019-04-08 18:05 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1554737427.118779.271.camel@acm.org \
--to=bvanassche-hinycgiudog@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=jroedel-l3A5Bk7waGM@public.gmane.org \
--cc=jsmart2021-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.