linux-kernel - Re: Staging tree status for the .33 kernel merge

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:	Mon, 4 Jan 2010 00:57:55 -0600
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
	Ashwin Ganti <ashwin.ganti@...il.com>
Subject: Re: Staging tree status for the .33 kernel merge

Quoting Greg KH (greg@...ah.com):
...
> This means, unless someone steps up and starts doing real work (not
> trivial spelling fixes) on the following drivers, they will be removed
> in the future kernel releases.
> 
>  - arlan, netwave, strip, wavelan - wireless drivers mentioned above
>    that are on the way out.  Slated for removal in 2.6.35
>  - hv - Microsoft Hyper V drivers.  The developers again seem to have
>    disappeared, this is getting old. Slated for removal in 2.6.35
>  - p9auth - this will be removed in .34 unless someone steps up.

I think I've decided to try to push it.  I'm working with some patches
at git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-cr.git
(branch p9auth.jan3.4 is latest).  I'll send patches as I feel they
are ready - so far they pass testcases, but are too new for me to
feel I should push them today.

Ashwin, I'm curious whether you'd think the last patch
(http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sergeh/linux-cr.git;a=commitdiff;h=1662ba777140a39c21a9b647459d2deab8ffe1ca)
would be a problem with any userspace - but I assume there is no
legacy userspace to really worry about?

Apart from plenty more cleanups, another more fundamental issue to
address is how to stop unused caphash entries from piling up in
memory.  Put a timeout on them?  Let privileged userspace list and
occasionally delete them?  Associate a target task with each entry,
where either the task or its decendent can use the capability, but
if the task dies we free the caphash entry?

-serge
--
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/