linux-kernel - Re: microblaze syscall list

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:	Mon, 28 Apr 2008 10:15:34 +1000
From:	John Williams <jwilliams@...e.uq.edu.au>
To:	Arnd Bergmann <arnd@...db.de>
CC:	monstr@...nam.cz, microblaze-uclinux@...e.uq.edu.au,
	Matthew Wilcox <matthew@....cx>,
	Will Newton <will.newton@...il.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arch@...r.kernel.org, git@...inx.com,
	John Williams <john.williams@...alogix.com>,
	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>,
	John Linn <John.Linn@...inx.com>
Subject: Re: microblaze syscall list

Arnd Bergmann wrote:
> On Sunday 27 April 2008, Michal Simek wrote:

>> I thing you understand that we can't change all application per night. This is
>> not possible. But we have to start with change this.
> 
> Note that the only thing you should need to change is the libc implementation
> (any version of it: glibc, uclibc, klibc, ...), but not any application source
> code, as the applications just call the functions that are defined in the libc.
> If you have binaries that are statically linked with their libc, you'd have
> to recompile or at least relink them. If you redefine data structures or
> types that are used in application code, like struct stat or off_t, you
> also need to recompile all user code.

Until very recently with the MMU support added to the CPU (and upcoming 
MMU support patches for MicroBlaze), all apps were statically linked 
anyway. So, this is not too much of an issue I don't think.

Because the CPU is so configurable re: instruction set and features, it 
is common to rebuild your entire userland and libs + kernel in one go. 
If you add support for HW integer mul or div, barrel shift etc, you need 
to rebuild not just the kernel but apps and libs as well.  Or rather, 
rebuild apps, and relink against a different multilib'd libc.

So, the issue seems not so much that there's a bunch of legacy binaries 
out there that will break, but rather that there will be a dead-zone 
period in which the kernel is exporting an ABI that is simply not 
available in the C libs and existing toolchains.  We should be doing all 
we can to encourage individual developers and distro maintainers (like 
PetaLogix) to base from the kernel.org tree.

> I think you have three options here:
> 
> 1. Keep the old syscall interface and just add new syscalls for the stuff
> that you are currently missing. Don't change userspace at all, but live
> with somewhat bloated kernels and libc forever and maintain a larger
> code base in the kernel.
> 
> 2. Change the syscall interface in the kernel in the way we have discussed,
> and adapt the libc code along with it. Break all backwards compatibility
> and start out with a new leaner ABI. Old applications can still use
> your old out-of-tree kernels, or forks of that.
> 
> 3. Merge only the ABI as in 2. into the mainline kernel, but use new
> syscall numbers for that. Maintain an out-of-tree patch that adds the
> old ABI for backwards compatibility so you can run old and new code
> on one kernel if you build with that patch, but eventually phase
> out the old ABI.

Maybe I misunderstand, but is there an option 1(a) where we keep the 
old, add the new, and suffer the bloat for a short period until the 
toolchains and C libs catch up and we remove out the old interfaces?

Are the old and new syscalls necessarily overloaded onto the same 
numbers?  We'd obviously like to be as "standard" as reasonably possible 
regarding syscall numbers

> I won't try to force you to go either route, it's your own decision,
> but you should understand the tradeoffs. I don't think there is any
> value in trying to deprecate just part of the ABI and break some
> binaries but not others, this will only cause hard to find bugs. Make
> sure that if you decide to break backwards compatibility, you break it
> in an obvious way and get the most benefit out of it.

No argument there.

John

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