On Friday 24 August 2012 08:41:00 Dmitry V. Levin wrote: > 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: > > > > * 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)
i don't think there's a real chance (other than the {g,s}etsockopt since
earlier kernels shipped with the older number). i wouldn't mind being proven
wrong though that some people are just really weird/crazy ;).
> 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?
sounds fine to me on both points
-mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
