linux-kernel - Re: [RFC PATCH v1 14/31] ARC: syscall support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201211151235.31735.arnd@arndb.de>
Date:	Thu, 15 Nov 2012 12:35:31 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	"Gilad Ben-Yossef" <gilad@...yossef.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [RFC PATCH v1 14/31] ARC: syscall support

On Thursday 15 November 2012, Vineet Gupta wrote:
> So the primary concern here is not breaking the userspace ABI - right ?
> 
> For syscalls I agree that we will indeed need to fix the ABI - by fixing
> uClibc. And if uClibc doesn't merge the fixes we can stay out of tree
> for uClibc - as we currently already are.

I'm sure we can find a solution for uClibc. We already have seven
architectures using the generic syscalls, including at least one
(arm64) that is going to run on a large number of installations
in the future.

> For gdbserver, the kernel provides the complete regset ABI. However it
> also provides a very limited version of old ABI - i.e. ptrace with
> PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the
> regset callbacks. This allows us to support the legacy gdbserver. If and
> when gdbserver upgrades it can switch over to new interface. So all
> along there will be NO ABI breakage at all. The cost is couple extra
> functions in kernel which we might have to maintain for some foreseeable
> future. Agree ?

It's more a question of principle. The rule is that we don't break user
space, and ptrace is just another user space interface is this. If
we merge it now, we will keep it around forever, taking it out later
is not an option IMHO. My preference would be not to merge the backwards
compatibility layer for ptrace at all, but I'm willing to listen to
other people that support your view if you want to keep it. In one
way, ptrace is less critical than the other system calls, and that is
because it's already architecture specific.

	Arnd
--
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/