Re: mmap on GNU Hurd

[Jacob Appelbaum]

Thomas Schwinge:
> Hi!
> 
> On Tue, 30 Apr 2013 00:47:47 +0000, Jacob Appelbaum <jacob@appelbaum.net> 
> wrote:
>> I've noticed that mmap() doesn't behave as expected
> 
> There are known issues with mmap, in particular it (currently) doesn't
> work at all on filesystem based on libnetfs (such as NFS, ftpfs, etc.),
> <http://www.gnu.org/software/hurd/open_issues/git_nfs_mmap.html>,
> <http://www.gnu.org/software/hurd/open_issues/libnetfs_io_map.html>.
> More details: <http://www.gnu.org/software/hurd/glibc/mmap.html>.  A few
> individual issues filed:
> <http://www.gnu.org/software/hurd/open_issues/mmap_crash_etc.html>,
> <http://www.gnu.org/software/hurd/open_issues/mmap_write-only.html>.
> And, there's no mremap,
> <http://www.gnu.org/software/hurd/open_issues/glibc/mremap.html>.
> 
> If you tell us what you're seeing with mmap and what you'd expect to see,
> we should quickly be able to tell "who's at fault".

Hi there,

I'm sure that this is a known issue of sorts or if it isn't it is
probably closely related to one of the above bugs.

Sure - I made a dist tar.gz from git (
https://github.com/ioerror/tlsdate ) tip:
https://people.torproject.org/~ioerror/src/tlsdate-git-tip-dist.tar.gz

It appears that the issue is that when I try to memcpy into my mmap()
created in the parent, the child is unable to write into it properly -
that is - the mmap() is constructed like so:

https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1115

tlsdate-helper then forks a child process and then attempts to memcpy
into the mmap():

https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1056

Now - if I inspect the contents of the mmap inside the child process -
sizeof() reports it to be four bytes (expected and the same size as the
32bit uint). However if I print it inside the child, it prints as a very
small integer - it most certainly is not identical to the contents of
ssl->s3->server_random. It gets even weirder from there...

When the child process ends and the parent goes to use it - it is zero.
I've added a clause to ensure that this value is never allowed and so
now on GNU/Hurd it simply fails to get further than this check:

  https://github.com/ioerror/tlsdate/blob/master/src/tlsdate-helper.c#L1194

So far this is good as it caught a bug on all platforms - this value
should never be zero and it shouldn't even attempt to set a clock if the
value is somehow zero. So I've now caught that case - though really it
should ensure the value is sane in a few ways - zero is OK for now but
will likely be extended in the future.

So... whose bug is this anyway? I was planning to just replace mmap()
here with a pipe but now I wonder if this should be fixed in GNU/Hurd or
if a pipe would do the trick in any case?

All the best,
Jacob