On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote:
> >and read/write the config space.
> >This means that a single userspace bug is enough to corrupt kernel
> >memory.
>
> Could u, pls., provide and example of this simple bug? Because it's
> absolutely not obvious...
Stick a value th
On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote:
> btw, (2) doesn't really add any insecurity. The user could already poke at
> the msix tables (as well as perform DMA); they just couldn't get a useful
> interrupt out of them.
Poking at msix tables won't cause memory corruption unless
On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote:
> Michael, how this or any other related patch is related to the problem u r
> describing?
> The above ability is there for years and if memory serves me
> well it was u who wrote uio_pci_generic with this "security flaw". ;)
I answe
On Tue, Oct 06, 2015 at 08:33:56AM +0100, Stephen Hemminger wrote:
> Other than implementation objections, so far the two main arguments
> against this reduce to:
> 1. If you allow UIO ioctl then it opens an API hook for all the crap out
> of tree UIO drivers to do what they want.
> 2. If
On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote:
> How about instead of trying to invent the wheel just go and attack the problem
> directly just like i've proposed already a few times in the last days: instead
> of limiting the UIO limit the users that are allowed to use UIO to
On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote:
> Just forwarding events is not enough to make a valid driver.
> What is missing is a way to access the device in a safe way.
Thinking about it some more, maybe some devices don't do DMA, and merely
signal events wit
On Mon, Oct 05, 2015 at 01:08:52PM +, Xie, Huawei wrote:
> On 9/30/2015 5:36 AM, Michael S. Tsirkin wrote:
> > On Tue, Sep 29, 2015 at 05:50:00PM +, shesha Sreenivasamurthy (shesha)
> > wrote:
> >> Sure. Then, is there any real reason why the backing files sho
On Fri, Oct 02, 2015 at 03:07:24PM +0100, Bruce Richardson wrote:
> On Fri, Oct 02, 2015 at 05:00:14PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 01, 2015 at 02:02:24PM -0700, Alexander Duyck wrote:
> > > validation and translation would add 10s if not 100s of nanoseconds
On Thu, Oct 01, 2015 at 02:02:24PM -0700, Alexander Duyck wrote:
> validation and translation would add 10s if not 100s of nanoseconds to the
> time needed to process each packet. In addition we are talking about doing
> this in kernel space which means we wouldn't really be able to take
> advanta
On Thu, Oct 01, 2015 at 02:17:49PM -0700, Alexander Duyck wrote:
> On 10/01/2015 02:42 AM, Michael S. Tsirkin wrote:
> >On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
> >>even when they are some users
> >>prefer to avoid the performance penalty.
> >I
On Thu, Oct 01, 2015 at 10:26:19AM -0700, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 19:31:08 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Ste
On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote:
> > This driver allows using PCI device with Message Signalled Interrupt
> > from userspace. The API is similar to the igb_uio driver used by th
On Thu, Oct 01, 2015 at 01:37:12PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote:
> > > This driver allows using PCI device with Message Signalled In
On Thu, Oct 01, 2015 at 04:14:33PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote:
> > > > This in itself is going to use up
> > > > a good proportion of the processing time, as well as that we have to
> > >
On Thu, Oct 01, 2015 at 11:42:23AM +0200, Vincent JARDIN wrote:
> There were some tentative to get it for other (older) drivers, named
> 'bifurcated drivers', but it is stalled.
That approach also has the advantage that userspace bugs can't do
silly things like reprogram device's EEPROM by mistake
On Thu, Oct 01, 2015 at 07:55:20AM -0700, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 13:14:08 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote:
> > > >There were some tentative to get it for other (old
On Thu, Oct 01, 2015 at 08:01:00AM -0700, Stephen Hemminger wrote:
> The per-driver ring method is what netmap did.
IIUC netmap has a standard format for descriptors, so was slower: it
still had to do all networking in kernel (it only bypasses
part of the networking stack), and to have a thread to
On Thu, Oct 01, 2015 at 06:19:33PM +0300, Avi Kivity wrote:
> On 10/01/2015 06:11 PM, Michael S. Tsirkin wrote:
> >On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote:
> >>> We already agreed this kernel
> >>>is going to be tainted, and unsupportable.
>
On Thu, Oct 01, 2015 at 07:50:37AM -0700, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 11:33:06 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote:
> > > This driver allows using PCI device with Mess
On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote:
> > We already agreed this kernel
> >is going to be tainted, and unsupportable.
>
> Yes. So your only motivation in rejecting the patch is to get the author to
> write the ring translation patch and port it to all relevant drivers
> ins
On Thu, Oct 01, 2015 at 01:07:13PM +0100, Bruce Richardson wrote:
> > > This in itself is going to use up
> > > a good proportion of the processing time, as well as that we have to
> > > spend cycles
> > > copying the descriptors from one ring in memory to another. Given that
> > > right now
> >
On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
>
>
> On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote:
> >On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote:
> >>>>It's not just the lack of system calls, of course, the archite
On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
> People will just use out of tree drivers (dpdk has several already). It's a
> pain, but nowhere near what you are proposing.
What's the issue with that? We already agreed this kernel
is going to be tainted, and unsupportable.
On Thu, Oct 01, 2015 at 12:08:07PM +0100, Bruce Richardson wrote:
> On Thu, Oct 01, 2015 at 01:38:37PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote:
> > >
> > >
> > > On 10/01/2015 12:55 PM, Michael S. Tsirki
On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote:
> >
> >>It's not just the lack of system calls, of course, the architecture is
> >>completely different.
> >Absolutely - I'm not saying move all of DPDK into kernel.
> >We just need to protect the RX rings so hardware does
> >not corrupt k
On Thu, Oct 01, 2015 at 01:25:17PM +0300, Avi Kivity wrote:
> Why use a VF on a non-virtualized system?
1. So a userspace bug does not destroy your hardware
(PFs generally assume trusted non-buggy drivers, VFs
generally don't).
2. So you can use a PF or another VF for regular networking.
3.
On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote:
>
>
> On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote:
> >On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
> >>It's easy to claim that
> >>a solution is around the corner, only no one w
On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote:
> > This driver allows using PCI device with Message Signalled Interrupt
> > from userspace. The API is similar to the igb_uio driver used by th
On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote:
> Non-virtualized setups have an iommu available, but they can also use
> pci_uio_generic without patching if they like.
Not with VFs, they can't.
--
MST
On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote:
> >There were some tentative to get it for other (older) drivers, named
> >'bifurcated drivers', but it is stalled.
>
> IIRC they still exposed the ring to userspace.
How much would a ring write syscall cost? 1-2 microseconds, isn't it?
On Thu, Oct 01, 2015 at 12:38:51PM +0300, Avi Kivity wrote:
> The sad thing is that you can do this since forever on a non-virtualized
> system, or on a virtualized system if you don't need interrupt support. All
> you're doing is blocking interrupt support on virtualized systems.
True, Linux cou
On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
> It's easy to claim that
> a solution is around the corner, only no one was looking for it, but the
> reality is that kernel bypass has been a solution for years for high
> performance users,
I never said that it's trivial.
It's probabl
On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
> even when they are some users
> prefer to avoid the performance penalty.
I don't think there's a measureable penalty from passing through the
IOMMU, as long as mappings are mostly static (i.e. iommu=pt). I sure
never saw any numbers th
On Thu, Oct 01, 2015 at 12:15:49PM +0300, Avi Kivity wrote:
> What userspace can't be allowed to do:
>
> access BAR
> write rings
>
>
>
>
> It can access the BAR by mmap()ing the resourceN files under sysfs.? You're
> not
> denying userspace the ability to oops the
On Thu, Oct 01, 2015 at 11:44:28AM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote:
> > > And for what, to prevent
> > > root from touching memory via dma that they can access in a million other
> > > ways?
>
On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote:
> I still don't understand your objection to the patch:
>
>
> MSI messages are memory writes so any generic device capable
> of MSI is capable of corrupting kernel memory.
> This means that a bug in userspace will lead to ker
On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote:
> > And for what, to prevent
> > root from touching memory via dma that they can access in a million other
> > ways?
>
> So one can be reasonably sure a kernel oops is not a result of a
> userspace bug.
On Wed, Sep 30, 2015 at 03:28:56PM -0700, Stephen Hemminger wrote:
> This is a new UIO device driver to allow supporting MSI-X and MSI devices
> in userspace. It has been used in environments like VMware and older versions
> of QEMU/KVM where no IOMMU support is available.
>
> Stephen Hemminger (
On Wed, Sep 30, 2015 at 03:28:58PM -0700, Stephen Hemminger wrote:
> This driver allows using PCI device with Message Signalled Interrupt
> from userspace. The API is similar to the igb_uio driver used by the DPDK.
> Via ioctl it provides a mechanism to map MSI-X interrupts into event
> file descri
On Wed, Sep 30, 2015 at 02:36:48PM -0700, Stephen Hemminger wrote:
> On Wed, 30 Sep 2015 23:09:33 +0300
> Vlad Zolotarov wrote:
>
> >
> >
> > On 09/30/15 22:39, Michael S. Tsirkin wrote:
> > > On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolot
On Wed, Sep 30, 2015 at 06:36:17PM +0300, Avi Kivity wrote:
> As it happens, you're removing the functionality from the users who have no
> other option. They can't use vfio because it doesn't work on virtualized
> setups.
...
> Root can already do anything.
I think there's a contradiction betw
On Wed, Sep 30, 2015 at 11:00:49PM +0300, Gleb Natapov wrote:
> > You are increasing interrupt latency by a huge factor by channeling
> > interrupts through a scheduler. Let user install an
> > interrupt handler function, and be done with it.
> >
> Interrupt latency is not always hugely important
On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote:
> >>How would iommu
> >>virtualization change anything?
> >Kernel can use an iommu to limit device access to memory of
> >the controlling application.
>
> Ok, this is obvious but what it has to do with enabling using MSI/MSI-X
> inter
On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote:
>
>
> On 09/30/15 18:26, Michael S. Tsirkin wrote:
> >On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote:
> >>How not virtualizing iommu forces "all or nothing" approach?
> >Looks
On Wed, Sep 30, 2015 at 10:43:04AM -0700, Stephen Hemminger wrote:
> On Wed, 30 Sep 2015 20:39:43 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Sep 30, 2015 at 10:28:07AM -0700, Stephen Hemminger wrote:
> > > On Wed, 30 Sep 2015 13:37:22
On Wed, Sep 30, 2015 at 10:28:07AM -0700, Stephen Hemminger wrote:
> On Wed, 30 Sep 2015 13:37:22 +0300
> Vlad Zolotarov wrote:
>
> >
> >
> > On 09/30/15 00:49, Michael S. Tsirkin wrote:
> > > On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wro
On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote:
> How not virtualizing iommu forces "all or nothing" approach?
Looks like you can't limit an assigned device to only access part of
guest memory that belongs to a given process. Either let it access all
of guest memory ("all") or don
On Wed, Sep 30, 2015 at 05:53:54PM +0300, Avi Kivity wrote:
> On 09/30/2015 05:39 PM, Michael S. Tsirkin wrote:
> >On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote:
> >>
> >>On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote:
> >>>On Wed, Sep 30, 2
On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote:
>
>
> On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote:
> >On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote:
> >>
> >>On 09/30/15 15:03, Michael S. Tsirkin wrote:
> >>>O
On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote:
>
>
> On 09/30/15 15:03, Michael S. Tsirkin wrote:
> >On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote:
> >>
> >>On 09/30/15 14:41, Michael S. Tsirkin wrote:
> >>>O
On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote:
>
>
> On 09/30/15 14:41, Michael S. Tsirkin wrote:
> >On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote:
> >>The whole idea is to bypass kernel. Especially for networking...
> >... on dumb
On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote:
> The whole idea is to bypass kernel. Especially for networking...
... on dumb hardware that doesn't support doing that securely.
Colour me unimpressed.
--
MST
On Wed, Sep 30, 2015 at 01:37:22PM +0300, Vlad Zolotarov wrote:
>
>
> On 09/30/15 00:49, Michael S. Tsirkin wrote:
> >On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote:
> >>On Tue, 29 Sep 2015 23:54:54 +0300
> >>"Michael S. Tsirkin" wro
On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote:
> On Tue, 29 Sep 2015 23:54:54 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrote:
> > > The security breach motivation u brought in "
On Tue, Sep 29, 2015 at 05:50:00PM +, shesha Sreenivasamurthy (shesha)
wrote:
> Sure. Then, is there any real reason why the backing files should not be
> unlinked ?
AFAIK qemu unlinks them already.
--
MST
On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrote:
> The security breach motivation u brought in "[RFC PATCH] uio:
> uio_pci_generic: Add support for MSI interrupts" thread seems a bit weak
> since one u let the userland access to the bar it may do any funny thing
> using the DMA engin
On Tue, Sep 29, 2015 at 03:48:08PM +, shesha Sreenivasamurthy (shesha)
wrote:
> If huge pages are allocated for the guest and if the guest crashes there may
> be
> a chance that the new guest may not be able to get huge pages again as some
> other guest or process on the host used it. But I a
On Sun, Sep 27, 2015 at 10:05:11AM +0300, Vlad Zolotarov wrote:
> Hi,
> I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
> Amazon EC2 instances with Enhanced Networking enabled.
> The idea is to create a DPDK environment that doesn't require compiling
> kernel modules (igb_uio
On Sun, Sep 20, 2015 at 04:58:42PM +0300, Marcel Apfelbaum wrote:
> On 09/18/2015 06:10 PM, Yuanhan Liu wrote:
> >All queue pairs, including the default (the first) queue pair,
> >are allocated dynamically, when a vring_call message is received
> >first time for a specific queue pair.
> >
> >This i
On Mon, Sep 21, 2015 at 10:25:18AM +0800, Yuanhan Liu wrote:
> On Sun, Sep 20, 2015 at 12:29:17PM +0300, Michael S. Tsirkin wrote:
> > On Fri, Sep 18, 2015 at 11:10:53PM +0800, Yuanhan Liu wrote:
> > > From: Changchun Ouyang
> > >
> > > Do not use VIRTI
On Mon, Sep 21, 2015 at 10:22:52AM +0800, Yuanhan Liu wrote:
> On Sun, Sep 20, 2015 at 12:37:35PM +0300, Michael S. Tsirkin wrote:
> > On Fri, Sep 18, 2015 at 11:10:54PM +0800, Yuanhan Liu wrote:
> > > From: Changchun Ouyang
> > >
> > > This message is use
On Fri, Sep 18, 2015 at 11:10:54PM +0800, Yuanhan Liu wrote:
> From: Changchun Ouyang
>
> This message is used to enable/disable a specific vring queue pair.
> The first queue pair is enabled by default.
>
> Signed-off-by: Changchun Ouyang
> Signed-off-by: Yuanhan Liu
> ---
> lib/librte_vhost
On Fri, Sep 18, 2015 at 11:10:53PM +0800, Yuanhan Liu wrote:
> From: Changchun Ouyang
>
> Do not use VIRTIO_RXQ or VIRTIO_TXQ anymore; use the queue_id,
> instead, which will be set to a proper value for a specific queue
> when we have multiple queue support enabled.
>
> For now, queue_id is sti
On Fri, Sep 18, 2015 at 11:10:56PM +0800, Yuanhan Liu wrote:
> From: Changchun Ouyang
>
> Fix the max virtio queue pair read issue.
>
> Control queue can't work for vhost-user mulitple queue mode,
> so introduce a counter to void the dead loop when polling
> the control queue.
>
> Signed-off-by
On Thu, Sep 10, 2015 at 06:32:35AM +, Xie, Huawei wrote:
> On 9/9/2015 3:34 PM, Michael S. Tsirkin wrote:
> > On Fri, Sep 04, 2015 at 08:25:05AM +, Xie, Huawei wrote:
> >> Hi:
> >>
> >> Recently I have done one virtio optimization proof of concept. The
| ... | 127 || 0 | 1 | ... | 127 | desc ring
> for tx dat
>
> +-+-+-+--+--+--+--+
>
>
This one came out corrupted.
>
> /huawei
Please Cc virtio related discussion mor
On Tue, Jun 09, 2015 at 03:04:02PM +0800, Linhaifeng wrote:
>
>
> On 2015/4/24 15:27, Luke Gorrie wrote:
> > On 24 April 2015 at 03:01, Linhaifeng wrote:
> >
> >> If not add memory fence what would happen? Packets loss or interrupt
> >> loss?How to test it ?
> >>
> >
> > You should be able to
On Fri, May 15, 2015 at 04:43:33PM +0300, Nikita Kalyazin wrote:
> Hi,
>
>
> Maybe I missed a part of the discussion, but is there any special purpose for
> using rte_mb (both read and write fence) here rather than rte_wmb (write
> fence only)?
The fence is between write of used->idx and read
On Tue, Apr 07, 2015 at 04:22:42PM +0200, Luke Gorrie wrote:
> Hi Michael,
>
> I'm writing to follow up the previous discussion about memory barriers in
> virtio-net device implementations, and Cc'ing the DPDK list because I believe
> this is relevant to them too.
>
> First, thanks again for gett
On Tue, Jan 27, 2015 at 03:57:13PM +0800, Linhaifeng wrote:
> Hi,all
>
> I use vhost-user to send data to VM at first it cant work well but after many
> hours VM can not receive data but can send data.
>
> (gdb)p avail_idx
> $4 = 2668
> (gdb)p free_entries
> $5 = 0
> (gdb)l
> /* check th
101 - 170 of 170 matches
Mail list logo
