[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51CCDDA5.5050503@nicta.com.au>
Date: Fri, 28 Jun 2013 10:49:41 +1000
From: Matthew Fernandez <matthew.fernandez@...ta.com.au>
To: <musl@...ts.openwall.com>
CC: Rich Felker <dalias@...ifal.cx>
Subject: Re: Use of size_t and ssize_t in mseek
On 28/06/13 01:34, Rich Felker wrote:
> On Thu, Jun 27, 2013 at 02:31:48PM +1000, Matthew Fernandez wrote:
>> On 27/06/13 14:23, Rich Felker wrote:
>>> On Thu, Jun 27, 2013 at 02:16:15PM +1000, Matthew Fernandez wrote:
>>>> Perfectly reasonable to make it UB (and I had assumed it was so
>>>> already).
>>>
>>> Well the UB is just passing a wrong size. But the only way you can
>>> guarantee that such a huge size is "wrong" is by cutting off all ways
>>> of making such a large object.
>>
>> In some sense this is true, but this would not have affected my
>> scenario. I do not know the size of the object to which I have a pointer
>> to and the object was not derived from Musl C functionality. As a bit of
>> context, this is an embedded environment where we don't have much
>> address space introspection. I suppose you could argue that I should
>> have re-implemented fmemopen in a way that didn't assume a bounded buffer.
>
> Thanks for providing the added context. It helps to understand the
> situation a lot better. Am I correct in assuming that you're using
> musl not on Linux, but ported to an underlying embedded environment,
> possibly without a kernel? The reason I ask is that I don't see how
> Linux would give you such an object without you requesting it via a
> syscall of some sort.
Yes, Rich, you're correct. I'm using Musl in userspace on the seL4
microkernel [0]. I'm getting this object from a bootstrapping process
that inserts it into my address space. The object is not actually
SIZE_MAX-sized, but I don't have accurate bounds for it at the time I
call fmemopen.
[0]: http://www.ertos.nicta.com.au/research/sel4/
> Anyway, if I'm understanding your usage case correctly, I think we
> should eventually provide documentation (perhaps in the porting
> section of the future manual) about using musl like this. And either
> we should document that it's undefined behavior to pass sizes larger
> than PTRDIFF_MAX/SSIZE_MAX to functions in musl, or we should make an
> effort to find all the functions affected by this issue and make them
> either reject such large sizes, or work safely with them.
>
> As a user of musl, what's your take on this?
A check in fmemopen (and other affected functions) would be my preferred
solution, as an unwitting user like myself who doesn't check all the
assumptions would still be caught out by just documenting it as
undefined. I would be happy with just an assert-fail here if that's easiest.
>> Yes, I agree with this reasoning. It seems fmemopen should really take a
>> ssize_t, but this would require deviating from the standard which is
>> undesirable.
>
> There are a lot of functions (read, write, ...) that "should" take
> ssize_t, in some sense of "should", but that wouldn't really fix the
> problem either, since large values would just get converted to
> negative values when passed to the functions.
True, but I would at least get a compiler warning. Anyway, I agree that
changing the function signature is not appropriate.
________________________________
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
