[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: glibc's hurd/fd-read.c

From: Roland McGrath
Subject: Re: glibc's hurd/fd-read.c
Date: Mon, 21 Jul 2008 12:50:50 -0700 (PDT)

The NREAD value is filled by the RPC stub from kernel-supplied message
header bits, it's the actual amount of data in that part of the reply
message.  Unless there is a mig bug, it cannot be greater than the inline
data limit passed in, i.e. nread <= *nbytes when data == buf, guaranteed at
the IPC/mig level.  When it's out of line data (data != buf), then the size
can be anything the io server chose to send.

It's bogus, i.e. a violation of Hurd protocols, for an io server to send
back more data than requested.  But it's possible with a buggy or malicious
server.  So it is appropriate paranoia on the client side to check for this
rather than turning it into a buffer overrun.

If this occurs, it's a protocol violation and should not be papered over.
So rather than just ignore the extra data, I made it return EGRATUITOUS.
(This error code means, "a Hurd server violated its protocol".)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]