On Wed, Aug 22, 2012 at 02:51:33PM -0400, Mike Frysinger wrote: > On Wednesday 22 August 2012 12:56:36 Dmitry V. Levin wrote: > > On Wed, Aug 22, 2012 at 11:56:15AM -0400, Mike Frysinger wrote: > > > Starting with linux 3.6 (and backported to earlier kernels), these two > > > syscalls have changed numbers (moving from native to compat entry > > > points). Update the strace syscall list accordingly. > > > > What will happen with applications using old syscall numbers (if any)? > > Will they get ENOSYS? > > the 64bit and x32 syscall tables are shared. so you can call any of the > 64bit > syscalls from an x32 app, and vice versa. there are a few additional entry > points which are really there just to map the x86 compat entry points which > the x32 ABI uses (for when types are different sizes like pointers). > > for example, if we look at the rt_sigaction syscall, we see: > 64bit's unisted.h sets the NR to 13 > x32's unistd.h sets the NR to 512 > > nothing is stopping you from doing syscall(13) in an x32 app, or syscall(512) > in a 64bit app. in either case, you won't get ENOSYS because they're both > valid syscall entry points. but in most cases, the call won't "work" because > the types being passed are wrong (which is why we've had to change the NRs > here in the first place).
OK, I've pushed this commit as is. > > > * linux/x32/syscallent.h: Move setsockopt from 54 to 541, and move > > > getsockopt from 55 to 542. > > > > > > Signed-off-by: Mike Frysinger <[email protected]> > > > --- > > > Note: I'm not sure about the old entry points. Should they get relabeled > > > as "old" ? Or just leave them as is ? > > > > From one side, the rule is to stick to __NR_* names as close as possible. > > From another side, it's desirable to decode syscalls on older kernels > > properly. So maybe we should rather leave old entry points for > > compatibility. > > should we fill out the entire table then ? with the rt_sigaction example > above > (which isn't the only one -- if you look at the x32 syscallent.h, pretty much > every {} entry is in the same boat), we could label it as > "64bit:rt_sigaction" > or something similarly obvious that the x32 app is most likely doing > something > wrong. the other problem here is that we can't really decode these syscalls > properly -- is the app passing up x32 structures (so the syscall will most > likely fail anyways), or has it manually crafted a 64bit compatible structure > and passing that up (which would be crazy and generally make no sense) ? If there is a real chance to see these 64bit syscalls used by x32 apps (no matter how crazy such apps are), would it be better to show syscall names (e.g. with "64bit:" prefix) rather than their "syscall_*" names, even without detailed decoding of these syscalls? What about setting appropriate sys_flags in these syscall entries so that traditional syscall filtering would work for them as well? -- ldv
pgp1UnwLuzaqW.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
