| 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
| ||
|
Message-Id: <200907031916.26214.arnd@arndb.de> Date: Fri, 3 Jul 2009 19:16:26 +0200 From: Arnd Bergmann <arnd@...db.de> To: monstr@...str.eu Cc: microblaze-uclinux@...e.uq.edu.au, John Williams <john.williams@...alogix.com>, LKML <linux-kernel@...r.kernel.org>, Remis Lima Baima <remis.developer@...glemail.com>, John Linn <John.Linn@...inx.com> Subject: Re: [microblaze-uclinux] [PATCH 03/11] microblaze: fall back on generic header files for the ABI On Friday 03 July 2009, Michal Simek wrote: > > > Initially I had hoped that we could do the change before 2.6.30 and > > I worked hard on getting the ABI patches to you early enough for > > that. After that failed, I made sure that you had everything in > > place for 2.6.31 and I believed that Michal said he would integrate > > that in the microblaze-mmu merge, before you actually start seeing > > users on the mainline kernel. > > we are talking about minor change - I know it break ABI a little bit > but don't be scared with it. The data structures are all compatible by now, with this one exception. __kernel_mode_t is easy enough to fix in the generic headers if it really helps. My frustration is only about the system call list, which has not been fixed, and which will cause a significant ABI break once you change it. If you are lucky, most applications will still work after you install a matching libc, but you still get a cross-dependency between libc and the kernel. This means you may not want to really use the generic syscall numbers, but at least you should make sure that your table is consistent. FWIW, below you find a list of inconsistencies. Arnd <>< System calls that have a number but are missing an entry in your sys_call_table: sys_preadv sys_pwritev sys_pselect6 sys_ppoll sys_sigaltstack sys_migrate_pages /* not needed */ sys_futimesat /* not needed */ System call numbers you might need for binary compatiblily and should have removed earlier: __NR_waitpid __NR_stime __NR_nice __NR_oldstat __NR_oldfstat __NR_oldlstat __NR_sigaction __NR_sgetmask __NR_ssetmask __NR_sigsuspend __NR_sigpending __NR_socketcall __NR_readdir __NR_sigreturn __NR_sigprocmask __NR_ipc __NR_sysfs Numbers that you really really should simply not #define, with no chance of breaking anything: __NR_break __NR_stty __NR_gtty __NR_ftime __NR_prof __NR_lock __NR_mpx __NR_ulimit __NR_oldolduname __NR_profil __NR_ioperm __NR_olduname __NR_iopl __NR_idle __NR_vm86old __NR_modify_ldt __NR_create_module __NR_get_kernel_syms __NR_afs_syscall __NR__newselect __NR_vm86 __NR_query_module __NR_getpmsg __NR_putpmsg __NR_ugetrlimit __NR_set_thread_area __NR_get_thread_area __NR_vserver __NR_accept04 /* typo? */ Duplicate system call numbers: __NR_lchown32 __NR_getuid32 __NR_getgid32 __NR_geteuid32 __NR_getegid32 __NR_setreuid32 __NR_setregid32 __NR_getgroups32 __NR_setgroups32 __NR_fchown32 __NR_setresuid32 __NR_getresuid32 __NR_setresgid32 __NR_getresgid32 __NR_chown32 __NR_setuid32 __NR_setgid32 __NR_setfsuid32 __NR_setfsgid32 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/
Powered by blists - more mailing lists