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]

Date:	Thu, 17 Jan 2013 10:43:50 +0530
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Gilad Ben-Yossef <gilad@...yossef.com>,
	<linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 14/31] ARC: syscall support

On Thursday 15 November 2012 06:05 PM, Arnd Bergmann wrote:
> 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
> 

OK as of now the legacy syscall ABI and ptrace PEEKUSR/POKEUSR are taken out of
submissions tree - we'll carry these out-of-tree for sometime before eventually
moving to newer uClibc/gdbserver which don't need these O-O-T patches.

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