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:	Fri, 15 Feb 2013 17:44:33 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Shentino <shentino@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

On Fri, Feb 15, 2013 at 5:22 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Fine by me - the variant I'd posted simply moved these calls in one
> place; I've no problem with replacing them with force_sig() (or
> force_sigsegv(SIGSEGV, current), for paranoia sake).  OTOH, I'd probably
> prefer to make it a separate commit.

I'd argue that it actually makes sense in the same commit - since
you're changing SIGKILL to SIGSEGV, and what makes SIGKILL special
really is that it can never be blocked. So even conceptually, it's
actually *that* change that it should couple with.

But I don't care enough, so if you already just have the one commit
and want to add on top of it with a second one, that's fine.

> Cause: SET_PERSONALITY() on alpha doesn't care to preserve the upper bits
> of current->personality and just does either set_personality(PER_LINUX) or
> set_personality(PER_LINUX_32BIT).

Christ, we should just try to get rid of the personality bits
entirely, they are completely insane. We don't even use most of the
numbers, yet we have these odd personality numbers for emulating
legacy Unixes that we don't even care about. Some of it *may* have
made sense back when we actually thought things like iBCS2 would
matter. I cannot believe it possibly matters any more.

But nobody seems to care enough, and the numbers have slipped into
user space. I do wonder if we could make things clearer, get rid of
the insane internal "personality number", and instead have explicit
bits for the few things that actually do matter (like the whole
zero-page mapping, the address randomization etc). And then leave the
insane "set_personality()" system call as a legacy interface that just
looks at the number and moves the bits around appropriately.

The fact that we actually carry this insane meaningless number along,
and then have crazy things like that "upper bits of the crazy number
doesn't get set by alpha SET_PERSONALITY" is just crazy.

But don't worry, I sympathize 100% with all sane people who go "I
don't want to touch that mess".

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