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:	Sat, 7 May 2016 18:16:14 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...nel.org>, x86@...nel.org
Cc:	linux-kernel@...r.kernel.org, Borislav Petkov <bp@...en8.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	Aleksa Sarai <cyphar@...har.com>,
	Amanieu d'Antras <amanieu@...il.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Heinrich Schuchardt <xypron.glpk@....de>,
	Jason Low <jason.low2@...com>,
	Josh Triplett <josh@...htriplett.org>,
	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Paul Moore <pmoore@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Richard Weinberger <richard@....at>,
	Sasha Levin <sasha.levin@...cle.com>,
	Shuah Khan <shuahkh@....samsung.com>,
	Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vladimir Davydov <vdavydov@...allels.com>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH 4/4] signals/sigaltstack: Change SS_AUTODISARM to (1U <<
 31)

03.05.2016 20:31, Andy Lutomirski пишет:
> Using bit 4 divides the space of available bits strangely.  Use bit
> 31 instead so that we have a better chance of keeping flag and mode
> bits separate in the long run.
>
> Cc: Stas Sergeev <stsp@...t.ru>
> Cc: Al Viro <viro@...iv.linux.org.uk>
> Cc: Aleksa Sarai <cyphar@...har.com>
> Cc: Amanieu d'Antras <amanieu@...il.com>
> Cc: Andrea Arcangeli <aarcange@...hat.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Andy Lutomirski <luto@...capital.net>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: Denys Vlasenko <dvlasenk@...hat.com>
> Cc: Eric W. Biederman <ebiederm@...ssion.com>
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Heinrich Schuchardt <xypron.glpk@....de>
> Cc: Jason Low <jason.low2@...com>
> Cc: Josh Triplett <josh@...htriplett.org>
> Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Palmer Dabbelt <palmer@...belt.com>
> Cc: Paul Moore <pmoore@...hat.com>
> Cc: Pavel Emelyanov <xemul@...allels.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Richard Weinberger <richard@....at>
> Cc: Sasha Levin <sasha.levin@...cle.com>
> Cc: Shuah Khan <shuahkh@....samsung.com>
> Cc: Tejun Heo <tj@...nel.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Vladimir Davydov <vdavydov@...allels.com>
> Cc: linux-api@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> ---
>   include/uapi/linux/signal.h               | 2 +-
>   tools/testing/selftests/sigaltstack/sas.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/signal.h b/include/uapi/linux/signal.h
> index 738826048af2..cd0804b6bfa2 100644
> --- a/include/uapi/linux/signal.h
> +++ b/include/uapi/linux/signal.h
> @@ -8,7 +8,7 @@
>   #define SS_DISABLE	2
>   
>   /* bit-flags */
> -#define SS_AUTODISARM	(1 << 4)	/* disable sas during sighandling */
> +#define SS_AUTODISARM	(1U << 31)	/* disable sas during sighandling */
And what if we are out of 32 bits for storing both mode and flags? :)
Well, yes, very unlikely, but I did it that way exactly so that
we can eventually promote to 64bit variable.
Doesn't matter at all, of course. Let it be any way you like.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ