Re: valgrind diff to fix run memcheck on amd64

YASUOKA Masahiko <yasuoka@openbsd.org> wrote:

> On Wed, 02 Oct 2019 08:35:26 -0600
> "Theo de Raadt" <deraadt@openbsd.org> wrote:
> > YASUOKA Masahiko <yasuoka@openbsd.org> wrote:
> >> On Wed, 02 Oct 2019 07:24:46 -0600
> >> "Theo de Raadt" <deraadt@openbsd.org> wrote:
> >> >> As far as my test (the log attached), valgrind seems to work with
> >> >> "pledge" but not work with "unveil".
> >> >>
> >> >> Is there any fundamental problem of valgrind to work with "pledge"?
> >> >
> >> > If unveil causes problems, then that means it is trying to access files.
> >> > unveil will return ENOENT or EACCES for files which you think exist,
> >> > but they've become invisible.
> >>
> >> I looked into the problem more.
> >>
> >> - unveil(2) itself fails
> >> - so file system related system calls are not restricted (yet)
> >>
> >> valgrind complains:
> >>
> >> ==13326==
> >> --13326-- WARNING: unhandled syscall: 114
> >> --13326-- You may be able to write your own handler.
> >> --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> >> --13326-- Nevertheless we consider this a bug. Please report
> >> --13326-- it at http://valgrind.org/support/bug_reports.html.
> >>
> >> valgrind doesn't support unveil(2) yet. I suppose Asou can add that.
> >
> > that's wonderful. when not handling that system call, does it simply
> > continue with return value 0?
>
> No, it returns -1 but my test program ignores that error.
>
> if (unveil(NULL, NULL) == -1)
> warn("unveil"); /* must not continue but this is a test */
>
> actually warn() shows the message.
>
> a.out: unveil: Undefined error: 0
>
> I'm sorry for making the confuse. My test program was to check
> unveil(2) and pledge(2) at the same time.

OK fine.

It's a big sad. I guess valgrind is designed to cope with the
"system call stubs are not neccessarily the native system call" problem
that only linux has.