On Sat, 24 Mar 2018, Andre McCurdy wrote:
On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky <kamen...@cisco.com> wrote:
On Sat, 24 Mar 2018, Burton, Ross wrote:
On 24 March 2018 at 20:12, Victor Kamensky <kamen...@cisco.com> 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.
Thanks,
Victor
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
