public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	Tim Vlaar <Tvlaar@ptgrey.com>,
	Markus Rechberger <mrechberger@gmail.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	USB list <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size
Date: Mon, 7 Nov 2011 13:49:09 -0800	[thread overview]
Message-ID: <20111107214909.GA13023@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1111071537170.2004-100000@iolanthe.rowland.org>

On Mon, Nov 07, 2011 at 03:53:59PM -0500, Alan Stern wrote:
> On Mon, 7 Nov 2011, Sarah Sharp wrote:
> 
> > > > Alan, won't this global limit on the usbfs URB buffer size effect
> > > > userspace drivers that are currently allocating large amounts of
> > > > buffers, but still respecting individual buffer limit of 16KB?  It seems
> > > > like the patch has the potential to break userspace drivers.
> > > 
> > > It might indeed.  A further enhancement would replace that 16-MB global
> > > constant with a sysfs attribute (a writable module parameter for
> > > usbcore).  Do you have any better suggestions?
> > 
> > No, I don't have any better suggestions, except take out the limit. ;)
> > 
> > I do understand why we don't want userspace to DoS the system by using
> > up too much DMA'able memory.  However, as I understand it, the usbfs
> > files are created by udev with root access only by default, and distros
> > may choose to install rules that have more permissive privileges.  A
> > device vendor may not be ensured that a udev rule with permissive access
> > will be present for their device, so I think they're likely to write
> > programs that require root access.  Or require root privileges to
> > install said udev rule.
> > 
> > At that point, the same userspace program that has root privileges in
> > order to access usbfs or create the udev rule can just load and unload
> > the usbcore module with an arbitrarily large global limit, and the
> > global limit doesn't really add any security.  So why add the extra
> > barrier?
> 
> This is a question of kernel policy, and I don't know what is the
> generally accepted approach to this sort of thing.  Maybe Greg or Alan
> Cox can comment.

You have to set the limit to something, otherwise a non-root user can
kill the box quite easily.  If the admin wants to set the system up so
that any user can use up all of the memory, they are free to do that,
but we can't have it be the default.

thanks,

greg k-h

  reply	other threads:[~2011-11-07 21:49 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-12 12:36 [Patch] Increase USBFS Bulk Transfer size Markus Rechberger
2011-10-12 12:46 ` Markus Rechberger
2011-10-12 13:48 ` Sergei Shtylyov
2011-10-12 14:17 ` Greg KH
2011-10-12 16:59   ` Markus Rechberger
2011-10-12 20:33     ` Greg KH
2011-10-12 21:48       ` Markus Rechberger
2011-10-12 22:09         ` Markus Rechberger
2011-10-13  4:03           ` Manu Abraham
2011-10-13  4:59             ` Markus Rechberger
2011-10-13  5:46               ` Manu Abraham
2011-10-13  8:37                 ` Markus Rechberger
2011-10-13  9:29                   ` Markus Rechberger
2011-10-16  9:22                     ` James Courtier-Dutton
2011-10-13  9:34                   ` Manu Abraham
2011-10-13  9:39                     ` Markus Rechberger
2011-10-13 14:58           ` Alan Stern
2011-10-13 15:19             ` Markus Rechberger
2011-10-13 16:01               ` Chris Friesen
2011-10-13 16:12                 ` Markus Rechberger
2011-10-13 16:25                   ` Chris Friesen
2011-10-13 18:27                     ` Markus Rechberger
2011-10-13 20:07                       ` Alan Stern
2011-10-13 20:17                         ` Markus Rechberger
2011-10-13 18:21               ` Alan Stern
2011-10-13 19:05                 ` Alan Cox
2011-10-14 19:21             ` Johannes Stezenbach
2011-10-14 20:19               ` Alan Stern
2011-10-14 22:45                 ` Johannes Stezenbach
2011-10-15 11:45                   ` Markus Rechberger
2011-10-15 17:47                     ` Valdis.Kletnieks
2011-10-15 19:08                     ` Alan Stern
2011-10-15 19:04                   ` Alan Stern
2011-10-16  9:10                     ` Johannes Stezenbach
2011-10-16 14:18                       ` Alan Stern
2011-10-17 18:11                     ` Johannes Stezenbach
2011-10-17 18:22                       ` Alan Stern
     [not found]           ` <CAAMvbhFNTQeuJBgsDB9Y5ODc_b2O0X=oP_3uwRpWUREFS9qufA@mail.gmail.com>
2011-10-14  2:47             ` Markus Rechberger
2011-10-14  3:42               ` Markus Rechberger
2011-10-14  3:48                 ` Markus Rechberger
2011-10-14  5:47                 ` Valdis.Kletnieks
2011-10-14  6:23                   ` Markus Rechberger
2011-10-14  8:51                     ` James Courtier-Dutton
2011-10-14 15:38                       ` Markus Rechberger
2011-10-14 14:05                 ` Alan Stern
2011-10-14 14:33                   ` Greg KH
2011-11-07 18:52                     ` Sarah Sharp
2011-11-07 19:12                       ` Alan Stern
2011-11-07 20:18                         ` Sarah Sharp
2011-11-07 20:37                           ` Brink, Peter
2011-11-07 20:53                           ` Alan Stern
2011-11-07 21:49                             ` Greg KH [this message]
2011-11-07 23:07                             ` Sarah Sharp
2011-11-08  1:44                               ` Alan Stern
2011-11-07 19:16                       ` Tim Vlaar
2011-11-07 19:55                         ` Alan Stern
2011-11-07 20:13                           ` Tim Vlaar
2011-10-17 18:38                 ` Alan Stern
2011-10-17 19:07                   ` Markus Rechberger
2011-10-12 18:00   ` Mihai Moldovan
2011-10-12 20:36     ` Greg KH

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=20111107214909.GA13023@kroah.com \
    --to=greg@kroah.com \
    --cc=Tvlaar@ptgrey.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mrechberger@gmail.com \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox