Re: Basesystem programs redefine routine symbols from libc

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 9 Dec 2017 19:54:00 +0100
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <2ae77bc6-0ccf-4b4a-02a5-84b218f81a5e%gmx.com@localhost>

  | The problem is not on the header files (preprocessor), but on the linker
  | level.

The problem you are observing, yes, but that is not where the issue begins.
The problem is ...

  | We are intercepting uname(3)

And you shouldn't be, or rather, you aren't, you (in the case of ps) were
interception some other function that happened to have the same name as
uname(3).

This is no different than if some crime were committed by some person named
Kamil, and the police came and locked you up - after all, you have the same
name, it must have been you...    That is (would be) unreasonable, in both
cases.

  | because behind the scenes it's a syscall

but the one in ps was not, it was a perfectly normal function,
defined in the program, which had nothing whatever to do with the
uname sys call, beyond happening to share the same name.

That is the root of the problem.  The uname() being used in a program
is only the syscall uname() if the program has included sys/utsname.h

  | In the MSan case we mark the utsname pointer as initialized.

I understand what needs to happen if the uname() in question were the
uname that is the system call - but you cannot do that if the function
in question is something different.

That's why it is/was so easy to fix by simply renaming the function in
ps - nothing really cares what its name is, the name is just a method to
connect the function definition in the source code with the function calls.
Any legal name would do just as well - uname() usrname() xyzzy() or perhaps
ptrace() hostname() or kill() (I haven't bothered to check to see if those
names, as syscalls, would be expected to be known in ps or not, so I am not
sure if the last three would actually be OK  as substitutes).

  | I agree that this is not perfect, but I'm not aware about a better
  | solution that does not introduce redesign&rewrite of the sanitizers.

If the sanitizers are making incorrect and improper assumptions about
what the program is doing, and what it is entitled to check, that might
be the only proper answer.

kre