lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 1 Sep 2016 08:19:33 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Liviu Dudau <Liviu.Dudau@....com>
Cc:     Nicolai Stange <nicstange@...il.com>,
        Brian Starkey <brian.starkey@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation

On Wed, Aug 31, 2016 at 04:23:52PM +0100, Liviu Dudau wrote:
> On Wed, Aug 31, 2016 at 03:07:49PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Aug 05, 2016 at 01:11:45PM +0200, Nicolai Stange wrote:
> > > Brian Starkey <brian.starkey@....com> writes:
> > > 
> > > > On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote:
> > > >>Nicolai Stange <nicstange@...il.com> writes:
> > > >>> However, if you wish to have some mmapable debugfs file which *can* go
> > > >>> away, introducing mmap support in the debugfs full proxy is perfectly
> > > >>> valid. But please see below.
> > > >>
> > > >>Assuming that you've got such a use case, please consider resending your
> > > >>patch along with the Cocci script below (and the Coccinelle team CC'ed,
> > > >>of course). If OTOH your mmapable debugfs files are never removed, just
> > > >>drop this message and use debugfs_create_file_unsafe() instead.
> > > >
> > > > So we do have an implementation using this, but it's likely we will
> > > > keep it out-of-tree (it's a stop-gap until we can get a non-debugfs
> > > > implementation of the functionality into mainline).
> > > >
> > > > Do you think it's worth merging this (and your cocci script) anyway to
> > > > save someone else doing the same thing later?
> > > 
> > > I personally think that having ->mmap() support in debugfs would be a
> > > good thing to have in general and I expect there to be some further
> > > demand in the future.
> > 
> > Ugh, mmap in debugfs, that's funny.  And sad...
> 
> Yeah.
> 
> While our need for the mmap-ing the debugfs entry is at best a temporary
> option and a hack, I would be interested to know what alternatives could
> be used to read a large amount of data that does not need the seq_operations
> API? The out-of-tree proof-of-concept code that we have to interact with
> a memory write engine needs to be able to access the output buffer from
> userspace, but that output buffer is created by the kernel KMS driver.

What type of debugging do you need this for?

A binary sysfs attribute also might work well for you, on the device
that you are talking to, but if not, yeah, mmap on debugfs will work
just fine, seems to be the best fit.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ