[OE-core] pseudo: host user contamination

[Andre McCurdy]

On Sat, Mar 24, 2018 at 10:23 AM, Seebs <seebs at seebs.net> wrote:
> On Sat, 24 Mar 2018 17:10:47 +0000
> "Burton, Ross" <ross.burton at intel.com> wrote:
>> On 24 March 2018 at 12:36, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > 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.
>>
>> And to make things easier I think we could even just ENOTSUPP
>> renameat2 in the short term (i.e. for 2.5)

If you can successfully intercept the libc syscall() API and return
ENOTSUPP for the one specific case of renameat2 but pass on all other
callers transparently then haven't you've already solved the bulk of
the problem (for the non-Go case)?

Or are you suggesting unconditionally returning ENOTSUPP for every
syscall called via the libc syscall() API?

>>, before looking at a more
>> comprehensive intercepting
>> which could solve the Go issue.
>
> In the Go case, we would basically have to do something more like
> debugger traps. They're not using libc *at all*, and unless something's
> built with cgo or requires C-type libraries, it's not even going to be
> dynamically linked. No dynamic linker => LD_PRELOAD is irrelevant.

Right, Go (and statically linked libc apps) are a completely different
problem and need a different solution.

>> I filed a bug with coreutils yesterday.  "Just intercept syscall()"
>> they said.
>
> If they can describe a mechanism for intercepting syscall that they can
> guarantee will work across all Linux architectures including possible
> future architectures not yet in use, I'd love to know what it is.

It's basically exactly what the musl syscall() wrapper does. ie fetch
6 register sized vaargs values from the caller and pass them on in the
same order to the next syscall().

  http://git.musl-libc.org/cgit/musl/tree/src/misc/syscall.c

> See syscall(2) for some examples of the kinds of things that could be
> concerns, such as the EABI calling convention. We can sort of hope for
> the best if we just treat everything as a chain of unsigned longs, but
> that's really *not* safe, and it should not be expected to work
> reliably across architectures.

None of that matters if you don't need to interpret the arguments -
you just need to pass them on in the same order you received them.

> Honestly, reading it more closely, I don't think we can actually
> produce behavior that precisely mimics the behavior of syscall() for
> generic cases on architectures we currently run on. There's magic like
> setting values in other registers, clobbering registers, and so on,
> because *this function does not obey general architecture calling
> conventions*. And if the wrapper does, the wrapper will break at least
> some of the expected behaviors, by not behaving the same way.

I don't see any evidence to support all this doom and gloom, but if
there is a corner case which fails then it will also fail when running
on musl - so at least you won't be debugging it on your own :-)

> Basically: I don't think we can promise that we will correctly pass
> through both parameters to syscall() and returns from it in on existing
> architectures we're actually running on today, for the whole set of
> possible syscalls. So if we intercept syscall(), at least some
> previously-valid programs break.

Since the libc syscall() API is only going to be used for syscalls
which don't have an libc wrapper, it's unlikely to get used very much.
The LWN article has a list of the potential syscalls which are likely
to come via this API and it's not a long list. In practice, getrandom
and renameat2 may be the only syscalls which currently get called that
way - and getrandom now has a wrapper in libc so over time that will
migrate away from using syscall().

  https://lwn.net/Articles/655028/