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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.00.1009221215250.29127@tigran.mtv.corp.google.com>
Date:	Wed, 22 Sep 2010 12:31:05 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 1/2] sysfs: Fail bin file mmap if vma close is
 implemented.

On Mon, 20 Sep 2010, Eric W. Biederman wrote:
> 
> It is not reasonably possible to wrap vma->close().  To correctly
> wrap close would imply calling close on any vmas that remain when
> sysfs_remove_bin_file is called.  Finding the proper lists walking
> them getting the locking right etc, requires deep knowledge of the
> mm subsystem and as such would require assistence from the mm
> subsystem to implement.  That assistence does not currently exist.

Isn't it fair to assume that the call to sysfs_remove_bin_file() would
come from the module (or whatever) that would be handling the ->mmap,
->open, ->close, ->fault etc. calls?

In which case, it has been kept up to date with the reference counting
so far: and if it judges that it's apppropriate now to remove bin file,
despite having received more mmaps and opens than closes, then I think
it should be allowed to make that decision (knowing that your sysfs end
will take care not to call it further), even though it wanted to support
close while the sysfs bin file was still there.

I think it would be nicer to leave the bin_vma_close() handling as you
had it before (but repositioning its sysfs_get_active more carefully,
as in your 2/2).

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ