linux-kernel - Re: [PATCH] broken TASK_SIZE for ia32

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:	Sun, 6 May 2012 18:54:51 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH] broken TASK_SIZE for ia32_aout

On Sun, May 06, 2012 at 10:16:11AM -0700, Linus Torvalds wrote:
> On Sun, May 6, 2012 at 9:20 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> > Setting TIF_IA32 in load_aout_binary() used to be enough; these days
> > TASK_SIZE is controlled by TIF_ADDR32 and that one doesn't get set
> > there. ?Switch to use of set_personality_ia32()...
> 
> Applied. Just out of curiosity, how did you notice? Just looking at
> TIF_IA32 usage, or do you actually have some old app?

Putting together an idiot's guide to thread flags ;-)  Other very similar
bug, AFAICS, is in mips elf.h:
#define __SET_PERSONALITY32_N32()                                       \
        do {                                                            \
                set_thread_flag(TIF_32BIT_ADDR);                        \
                current->thread.abi = &mips_abi_n32;                    \
        } while (0)
probably should clear_thread_flag(TIF_32BIT_REGS); as well.  Ralf?

Another catch on mips, and that one is downright funny:
#ifdef CONFIG_MIPS32_O32
#define TIF_32BIT TIF_32BIT_REGS
#elif defined(CONFIG_MIPS32_N32)
#define TIF_32BIT _TIF_32BIT_ADDR
#endif /* CONFIG_MIPS32_O32 */

Spot the breakage.  Note that TIF_32BIT is used only in is_compat_task()
there, so that went unnoticed for a long time.  BTW, I really wonder if
the logics here is correct, nevermind the obvious typo...  For kernels
with O32, but not N32 support we could bloody well use TIF_32BIT_ADDR -
O32 sets both flags.  And for kernels that support both (O32 and N32 are
not mutually exclusive), we probably want both of o32 and n32 processes
match is_compat_task().

Note that we have different semantics for is_compat_task() on x86 and
everywhere (AFAICS) else: "is this a 32bit syscall" vs. "is this a biarch
syscall with 32bit pointers, etc.".  On architectures where 32bit syscall
can't be issued by 64bit task and vice versa there's no difference, but for
e.g. sparc there definitely is one.  is_compat_task() there goes by what
the task is, not what kind of syscall is it trying to make.  It mostly
doesn't matter (is_compat_task() has very few users), but I suspect that
for e.g. ext4 is_32bit_api() it does matter and is currently broken...

What kind of semantics do we want?  "Thread property" one, set when we
set personality on execve(), or "syscall property", like e.g. x86 TIF_IRET
and TS_COMPAT?
--
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/