On 09.12.2017 21:51, Robert Elz wrote: > 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. > The problem raised earlier as ps(1) wasn't buildable because of duplicate symbol. This unveils the problems very early and so there is no observed misbehavior. > | 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 > I think that reusing symbol names of well-known standard functions from libc is at least misleading and shouldn't happen - so the process of renaming such functions is improving the situation. I suspect that this can also lead to subtle bugs that order of linking of files can produce different result image or break on platforms that use a different executable format to ELF. I don't see any gain from redefining such functions long term, instead of getting old code to still build. I don't expect anybody in modern code to reuse data symbols like 'errno'. I was attempting to port the sanitizers with minimal changes in the NetBSD code base and it looks like these symbol names are the only altered thing so far. Redesigning sanitizers to teach them about such cases is too complex work for me as of now.
Attachment:
signature.asc
Description: OpenPGP digital signature