linux-kernel - Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

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: <CA+55aFyZFf_9ZMFSOs9y-n3EsQ7n2V0qEnCrqAGFWgDGmPBmtg@mail.gmail.com>
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/