From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754293AbbFRJMf (ORCPT ); Thu, 18 Jun 2015 05:12:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753328AbbFRJM1 (ORCPT ); Thu, 18 Jun 2015 05:12:27 -0400 Date: Thu, 18 Jun 2015 11:12:24 +0200 From: Igor Mammedov To: "Michael S. Tsirkin" Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 3/5] vhost: support upto 509 memory regions Message-ID: <20150618111224.0aa6dff7@nial.brq.redhat.com> In-Reply-To: <20150617182917-mutt-send-email-mst@redhat.com> References: <20150617123842-mutt-send-email-mst@redhat.com> <20150617134803.5a03d04e@nial.brq.redhat.com> <20150617134848-mutt-send-email-mst@redhat.com> <20150617142339.6e6deb12@nial.brq.redhat.com> <20150617151030-mutt-send-email-mst@redhat.com> <5581742C.9060100@redhat.com> <20150617163028-mutt-send-email-mst@redhat.com> <20150617171257.11fe405d@nial.brq.redhat.com> <20150617173736-mutt-send-email-mst@redhat.com> <20150617180921.7972345d@igors-macbook-pro.local> <20150617182917-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 17 Jun 2015 18:30:02 +0200 "Michael S. Tsirkin" wrote: > On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote: > > On Wed, 17 Jun 2015 17:38:40 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote: > > > > On Wed, 17 Jun 2015 16:32:02 +0200 > > > > "Michael S. Tsirkin" wrote: > > > > > > > > > On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote: > > > > > > > > > > > > > > > > > > On 17/06/2015 15:13, Michael S. Tsirkin wrote: > > > > > > > > > Considering userspace can be malicious, I guess yes. > > > > > > > > I don't think it's a valid concern in this case, > > > > > > > > setting limit back from 509 to 64 will not help here in any > > > > > > > > way, userspace still can create as many vhost instances as > > > > > > > > it needs to consume memory it desires. > > > > > > > > > > > > > > Not really since vhost char device isn't world-accessible. > > > > > > > It's typically opened by a priveledged tool, the fd is > > > > > > > then passed to an unpriveledged userspace, or permissions > > > > > > > dropped. > > > > > > > > > > > > Then what's the concern anyway? > > > > > > > > > > > > Paolo > > > > > > > > > > Each fd now ties up 16K of kernel memory. It didn't use to, so > > > > > priveledged tool could safely give the unpriveledged userspace > > > > > a ton of these fds. > > > > if privileged tool gives out unlimited amount of fds then it > > > > doesn't matter whether fd ties 4K or 16K, host still could be DoSed. > > > > > > > > > > Of course it does not give out unlimited fds, there's a way > > > for the sysadmin to specify the number of fds. Look at how libvirt > > > uses vhost, it should become clear I think. > > then it just means that tool has to take into account a new limits > > to partition host in sensible manner. > > Meanwhile old tools are vulnerable to OOM attacks. I've chatted with libvirt folks, it doesn't care about how much memory vhost would consume nor do any host capacity planning in that regard. But lets assume that there are tools that do this so how about instead of hardcoding limit make it a module parameter with default set to 64. That would allow users to set higher limit if they need it and nor regress old tools. it will also give tools interface for reading limit from vhost module. > > > Exposing limit as module parameter might be of help to tool for > > getting/setting it in a way it needs. >