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, 7 Jun 2007 15:12:43 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Kyle Moffett <mrmacman_g4@....com>,
	Davide Libenzi <davidel@...ilserver.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2

On Thu, 7 Jun 2007 07:59:47 -0400
Kyle Moffett <mrmacman_g4@....com> wrote:


> Likewise there are a massive group of other libraries (especially  
> user-interface and server related ones) that would really like to  
> have support for creating file-descriptors without the top-level  
> application closing them randomly (like several shells seem to).
> 

True, shells are sometimes quite strange.

For example, bash uses file descriptor 255 (FD_CLOEXEC)

When it forks a new process, child gets a file table with 256 slots.

At exec() time, 255 is closed but file table doesnt shrink.
(shrinking is done at fork() time only)

With fdmap, that means each process started by bash uses at least 
256 * sizeof(list_head) bytes, ie 4096 bytes on x86_64, even if only three 
file-descriptors are opened (0,1,2)

FD_CLOFORK should help here (BTW : current patch from Davide doesnt take this
into account and might need a change in fdmap_top_open_fd())

Davide, are you sure we want FIFO for non sequential allocations ?

This tends to use all the fmap slots, and not very cache friendly
if an app does a lot of [open(),...,close()] things. We already got a 
perf drop because of RCUification of file freeing (FIFO mode instead 
of LIFO given by kmalloc()/kfree())

If the idea behind this FIFO was security (ie not easy for an app to predict 
next glibc file handle), we/glibc might use yet another FD_SECUREMODE flag, 
wich ORed with O_NONSEQFD would ask to fdmap_newfd() to take the tail of 
fmap->slist, not head.

-
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