linux-kernel - microblaze: clone syscall: Potentially ABI breaking by passing parent/child_tidptr

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>] [day] [month] [year] [list]

Message-ID: <4F6203C9.3010608@monstr.eu>
Date:	Thu, 15 Mar 2012 15:59:21 +0100
From:	Michal Simek <monstr@...str.eu>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	John Williams <john.williams@...alogix.com>,
	Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	John Linn <John.Linn@...inx.com>
Subject: microblaze: clone syscall: Potentially ABI breaking by passing parent/child_tidptr
 - old glibc 2.3.6.

Hi All,

We have updated our toolchain to the latest & greatest based on an eglibc with ntpl for microblaze.
And I would like to check one thing with you to be sure that we don't break ABI compatibility.

In current kernel code (without ntpl), kernel sys_clone wrapper(in entry.S) clears 2 arguments (or setup them to NULL)
which is parent_tidptr and child_tidptr.
Obviously we have to use these two parameters to get things to work on eglibc that's why I have to remove
that clearing.

I have looked at the kernel code(fork.c and core.c files) and I haven't found any reason why
passing parent_tidptr and child_tidptr from glibc and not to clearing them in the kernel should break
old glibc toolchain and break ABI.

For old glibc if clone_flags is setup to (CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_CHILD_SETTID)
to get parent/child_tidptr use in the kernel (but both are NULL).
 From code I have seen it always ends with unsuccessful attempt to return value back to user space
because kernel ignores return values from put_user macros (It also means that put_user fails
because pointer is NULL).
For new case(with passing parent/child_tidptr) from old glibc, kernel will just do what it is expected
to do which is setup/clear proper values to provided pointers.

Also from man page if I compare both cases (with setup pointers to NULL and passing them from glibc)
kernel will setup/clear thread ID to proper location prepared by glibc.

My point is if there is any option if we start to pass parent/child_tidptr for old glibc that it will
break anything.

Can you correct my understanding?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
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/