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]
Message-ID: <474B1960.2030104@zytor.com>
Date:	Mon, 26 Nov 2007 11:07:12 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ulrich Drepper <drepper@...hat.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tglx@...utronix.de
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

Ingo Molnar wrote:
> 
> So it's not like sys_indirect() would break some magic pristine state of 
> a flat parameter space - on the contrary, most of the nontrivial 
> syscalls take pointers to structures or pointers to streams of 
> information. The parameter count histogram i believe further underlines 
> this point:
> 
>   #args   #syscalls
>   -----------------
>       0       22
>       1       51
>       2       83
>       3       85
>       4       40
>       5       23
>       6        8
> 
> the natural 'center' of function call parameter counts is around 1-4 
> parameters, and that is natural. (most operators that the human brain 
> prefers to operate with are like that - having higher complexity than 
> that often defeats the purpose of getting an API used by ... humans.)
> 

I was preparing a response to Linus' email, but I really feel this needs 
to be addressed specifically.

When it comes to dealing with the operator-visible state, what matters 
is what happens on the API level, NOT on the system call level. 
Furthermore, the proposed sys_indirect interface just means that there 
are parameters hidden from immediately view, even though they 
fundamentally change the operation performed, and that it is much harder 
to correlate, say, the output of strace(1) with what actually happened 
in the program.  So from a *psychological* point of view, this seems to 
be an insane design choice.

	-hpa
-
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