On Sun, Mar 25, 2018 at 9:05 AM, Andre McCurdy <[email protected]> wrote: > On Sat, Mar 24, 2018 at 10:37 PM, Victor Kamensky <[email protected]> wrote: >> On Sat, 24 Mar 2018, Andre McCurdy wrote: >>> On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky <[email protected]> >>> wrote: >>>> On Sat, 24 Mar 2018, Burton, Ross wrote: >>>>> On 24 March 2018 at 20:12, Victor Kamensky <[email protected]> wrote: >>>>>> Here is another crazy idea how to deal with it, just >>>>>> brainstorming what options are on the table: disable >>>>>> renameat2 with help of seccomp and force coreutils to >>>>>> use other calls. Something along the lines that were >>>>>> suggested with intercept of syscall function call, but >>>>>> let kernel to do interception work. >>>>> >>>>> Wow, that's impressively magic. Does this depend on kernel options or >>>>> specific recent versions? >>> >>> Yeah, it's impressive but perhaps overkill for this situation. >>> >>> Having the kernel run a BPF script on every syscall is going to have a >>> much bigger performance impact than intercepting one specific libc >>> function in user space. >> >> I don't think we should worry about overhead in pseudo case. >> >>> Also, AFAIK, seccomp can't be nested - so building within an >>> environment which has already been secured with seccomp (e.g. recent >>> versions of docker?) might be a problem if pseudo starts to rely on >>> seccomp too. >> >> Above is true. It was on my mind. >> >> Note I have no problem whatsoever if you can intercept syscall >> function correctly. Function intercepting way is definitely more >> aligned with what pseudo does. I was just listing other >> possible options. >> >> But please note syscall function takes a >> variable number of arguments and call another variable >> number of argument function, real syscall implementation, in >> general, cannot be done. One would need to have complimentary >> vsyscall function taking va_list. I.e like printf and vprintf. >> >> Please see http://c-faq.com/varargs/handoff.html >> >> But maybe something special can be done for syscall case. >> Disclaimer: I did not read full thread, maybe you already >> discussed this. > > Yes, I think it's already been covered in the thread. Although the > libc syscall() function takes a variable number of arguments, it's > known that there are a maximum of 6 of them and they are all of a data > type which fits into the register size of the target architecture (ie > "long" for most 32bit and 64bit targets, "long long" for x32 etc). > Therefore it's possible to extract them from the va_args created by > the caller into 6 temporary variables and then pass those variables on > when calling the real libc syscall() function. ie we don't actually > need to pass the original caller's va_args on to the real syscall() > function - we just need to pass on all the arguments. > > There's some concern that unconditionally extracting 6 arguments when > the caller may have supplied less than that could be problematic. > However, there's code in both glibc and musl which does exactly that, > so I'm inclined to think it's OK in practice. The worst that can > happen would seem to be passing some extra junk values to a syscall in > the kernel which is going to ignore them. > -- FWIW: All my build machines are affected by this issue. As temporary workaround I downgraded coreutils-8.27-20.fc27 by
dnf install coreutils-8.27-16.fc27 Now images seem to build again without floods of host contamination. Have no idea for how long downgrade is possible... Interesting background: mv/renameat2 change seemed so important for Fedora that they backported the changes into 8.27. Andreas -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
