From: Mathias Krause <minipli@googlemail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
security@kernel.org, "Luck, Tony" <tony.luck@intel.com>,
James Morris <jmorris@namei.org>,
Mike Waychison <mikew@google.com>,
Michael Davidson <md@google.com>,
linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Roland McGrath <roland@redhat.com>
Subject: Re: [Security] DoS on x86_64
Date: Thu, 28 Jan 2010 23:47:41 +0100 [thread overview]
Message-ID: <F8EDE1FD-DF2A-412C-8A00-7B332A3E1253@googlemail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1001281427220.22433@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
Am 28.01.2010 um 23:33 schrieb Linus Torvalds:
>>
>> - The actual point of no return in the case of binfmt_elf.c is inside
>> the subroutine flush_old_exec() [which makes sense - the actual
>> process
>> switch shouldn't be dependent on the binfmt] which isn't subject to
>> compat-level macro munging.
>
> Why worry about it? We already do that additional
>
> SET_PERSONALITY(loc->elf_ex);
>
> _after_ the flush_old_exec() call anyway in fs/binfmt_elf.c.
>
> So why not just simply remove the whole early SET_PERSONALITY
> thing, and
> only keep that later one? The comment about "lookup of the
> interpreter" is
> known to be irrelevant these days, so why don't we just remove it all?
>
> I have _not_ tested any of this, and maybe there is some crazy
> reason why
> this won't work, but I'm not seeing it.
>
> I think we do have to do that "task_size" thing (which
> flush_old_exec()
> also does), because it depends on the personality exactly the same way
> STACK_TOP does. But why isn't the following patch "obviously correct"?
Looks good to me because that's almost exactly the thing we already
tried, too. But by doing so we just got another Oops when executing a
32 bit program. But, in fact, we forgot the assignment of TASK_SIZE
which now clearly makes sense. I guess we can try this tomorrow. I'll
keep you informed.
Thanks for the patch. Looks promising :)
Greets,
Mathias
[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
next prev parent reply other threads:[~2010-01-28 22:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 7:34 Mathias Krause
2010-01-28 8:18 ` [Security] " Andrew Morton
2010-01-28 15:41 ` H. Peter Anvin
2010-01-28 22:33 ` Linus Torvalds
2010-01-28 22:47 ` Mathias Krause [this message]
2010-01-28 22:47 ` H. Peter Anvin
2010-01-28 23:09 ` Linus Torvalds
2010-01-28 23:27 ` H. Peter Anvin
2010-01-28 23:46 ` Linus Torvalds
2010-01-29 4:43 ` Linus Torvalds
2010-01-29 4:43 ` [PATCH 1/2] Split 'flush_old_exec' into two functions Linus Torvalds
2010-01-29 4:47 ` [PATCH 2/2] x86: get rid of the insane TIF_ABI_PENDING bit Linus Torvalds
2010-01-29 5:17 ` [PATCH 1/2] Split 'flush_old_exec' into two functions H. Peter Anvin
2010-01-29 5:05 ` [Security] DoS on x86_64 H. Peter Anvin
2010-01-29 5:29 ` H. Peter Anvin
2010-01-29 5:34 ` [PATCH 1/2] Split 'flush_old_exec' into two functions H. Peter Anvin
2010-01-29 5:34 ` [PATCH 2/2] x86: get rid of the insane TIF_ABI_PENDING bit H. Peter Anvin
2010-01-29 5:36 ` [PATCH 1/2] Split 'flush_old_exec' into two functions H. Peter Anvin
2010-01-29 5:36 ` [PATCH 2/2] x86: get rid of the insane TIF_ABI_PENDING bit H. Peter Anvin
2010-01-29 5:41 ` [PATCH 1/2] Split 'flush_old_exec' into two functions H. Peter Anvin
2010-01-29 5:41 ` [PATCH 2/2] x86: get rid of the insane TIF_ABI_PENDING bit H. Peter Anvin
2010-01-29 5:44 ` H. Peter Anvin
2010-01-29 6:14 ` [PATCH 1/2] Split 'flush_old_exec' into two functions H. Peter Anvin
2010-01-29 6:14 ` [PATCH 2/2] x86: get rid of the insane TIF_ABI_PENDING bit H. Peter Anvin
2010-01-28 23:06 ` [Security] DoS on x86_64 Linus Torvalds
2010-01-28 23:14 ` H. Peter Anvin
2010-01-28 21:31 ` Mathias Krause
2010-01-28 17:10 ` Linus Torvalds
2010-01-28 21:49 ` Mathias Krause
2010-01-28 21:58 ` Linus Torvalds
2010-01-28 22:08 ` Mathias Krause
2010-01-28 22:18 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F8EDE1FD-DF2A-412C-8A00-7B332A3E1253@googlemail.com \
--to=minipli@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=linux-mm@kvack.org \
--cc=md@google.com \
--cc=mikew@google.com \
--cc=mingo@redhat.com \
--cc=roland@redhat.com \
--cc=security@kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox