On Wed, Aug 10, 2011 at 08:25:24AM +0200, Hans Verkuil wrote: > On Wednesday, August 10, 2011 01:37:27 Sakari Ailus wrote: > > On Tue, Aug 09, 2011 at 09:26:30AM +0200, Hans Verkuil wrote: > > ... > > > > Wouldn't that be a security issue ? Any application with permissions to access > > > > the video device could DoS the system. > > > > > > How is this any different from an application that tries to use more memory > > > then there is available? It's an out-of-memory situation, that can happen at > > > any time. Anyone can make an application that runs out of memory. > > > > > > Out-of-memory is not a security risk AFAIK. > > > > If you coun availability to security, then it is. > > > > This might not be an issue in embedded systems which have a single user, but > > think of the availability of the interface in e.g. a server. > > > > Also, this memory is locked to system physical memory, making it impossible > > to page it out to a block device. > > So? Anyone can make a program that allocates and uses a lot of memory causing > an out of memory error. I still don't see how that differs from trying to allocate > these buffers. The difference is between physical and virtual memory. Reserving buffers pinned in physical memory will starve all the other users very efficiently. > Out of memory is a normal condition, not a security risk. Administrators of largish servers with thousands of users might disagree. I have to admit I don't know their usage patterns very well so I have no demands on the issue. ulimit is being used in those systems as is quota, that I know. On the other hand, those systems typically do not contain V4L2 devices either. > The problem I have is that you can't really determine a valid policy here > since that will depend entirely on your use-case and (embedded) device. This is quite similar case as with the CMA in my opinion. The proposal (by Arnd, if my memory serves me correctly) was to limit the CMA allocations under certain percentage of the system memory address space. The limit could be overriddend e.g. in board code. -- Sakari Ailus sakari.ailus@xxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
