On Fri, 2018-03-23 at 18:56 -0500, Seebs wrote: > On Fri, 23 Mar 2018 23:47:30 +0000 > Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > > I... am really unsure whether it's possible to catch that, > > > because > > > I really, really, don't want to try to intercept raw syscall() > > > calls. I don't think that ends well. > > Just out of interest for my education, why is that a really bad > > idea? > > Loops, e.g. with memory allocation issues? > > Potentially. We rely pretty heavily on the assumption that an > *actual* syscall can go through. > > Although... Actually, I don't even know if this is an actual syscall. > This could be an actual glibc wrapper around the syscall interface, > just like all the others, which is not the *actual* raw syscall or > whatever, and... I have no idea how often that is or isn't hit. > > It's totally possible it would work, but basically, I have a pretty > good intuition of when something sounds brittle and error-prone, and > trying to trap syscall() sounds brittle and error-prone and might > work today but not next week...
I do totally agree that this is into dangerous territory. That said, I did want to understand what they've done here. Checking on a f27 machine: [rpurdie@fedora27 ~]$ objdump -T /bin/mv | grep sys 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 syscall and a quick look at the glibc source says there is a syscall() function: long syscall (syscall_number, arg1, arg2, arg3, arg4, arg5, arg6) which whilst written in assembler, is a standard library function which I believe coreutils is using. I think, at least in principle, pseudo could wrap that and intercept this particular syscall, check syscall_number (the numbering having its own set of issues) and then only handle the specific problem case we have. The unfortunate reality is we will have to figure out some solution to this as f27 is in the wild now. Explaining why this causes problems for debian/yocto to the upstream is also obviously a good idea. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
