linux-kernel - Re: [PATCH 2/4] Add NR_syscalls for x86

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:	Wed, 26 Aug 2009 01:38:35 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Jason Baron <jbaron@...hat.com>, "H. Peter Anwin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, x86@...nel.org, lethal@...ux-sh.org,
	laijs@...fujitsu.com, peterz@...radead.org, jiayingz@...gle.com,
	mbligh@...gle.com, lizf@...fujitsu.com, jistone@...hat.com
Subject: Re: [PATCH 2/4] Add NR_syscalls for x86_64

On Tue, Aug 25, 2009 at 04:58:29PM -0400, Jason Baron wrote:
> > Ugh! My eyes hurt!
> 
> sorry :)
> 
> > What you are doing here is to basically put back the hardcoded
> > NR_syscalls rather that using the build infrastructure already in place.
> > 
> 
> no. NR_syscalls is not hardcoded by this patch. Its defined in terms of
> __NR_syscall_max which is dynamically generated by the kernel build.
> 
> > If my memory serves me well, unistd_64.h generates __NR_syscall_max
> > automatically by being included multiples times. Can we generalize this
> > and make the information generated available in an automaticaly
> > generated header instead ? It is saved in ams-offsets.h currently as
> > "__NR_syscall_max". We could also save it somewhere else meant to be
> > included by C code.
> > 
> > Mathieu
> > 
> 
> The request was to define NR_syscalls in unistd.h, since that is the
> historical Linux location for it. Adding another automatically generated
> header does not accomplish that. Even if I include that new file in
> unistd.h, I'm still going to have a circular dependency, and require a
> solution similar to what I've proposed.
> 
> thanks,
> 
> -Jason


Hmm, yeah that's not easy to deal with.

May be, to lower a bit the hacky impact of this patch, __NR_syscall_max
should be at least replaced by NR_syscall in every x86-64 uses (also in
asm-offsets.h), to standardize this variable name.

Also, may be we could have an empty asm-offsets.h stub in the very beginning
that can be filled later so that we could include it unconditionnaly from
unistd_64.h ?

It would be nice to have the opinion of an x86 maintainer about what to do.

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