Re: valgrind diff to fix run memcheck on amd64

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.

> If so, the code is now behaving differently. An "if" statement has
> been told to misbehave. Meaning the addition of valgrind *IS* the
> an behaviour change, furthermore, it is introducing security problems.

> Fail hard is the only way things get built right.

--yasuoka