From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3476 Path: news.gmane.org!not-for-mail From: Matthew Fernandez Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Fri, 28 Jun 2013 10:49:41 +1000 Message-ID: <51CCDDA5.5050503@nicta.com.au> References: <51CBB6E1.6080302@nicta.com.au> <20130627041028.GV29800@brightrain.aerifal.cx> <51CBBC8F.5050301@nicta.com.au> <20130627042314.GW29800@brightrain.aerifal.cx> <51CBC034.7030001@nicta.com.au> <20130627153429.GZ29800@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372380607 9635 80.91.229.3 (28 Jun 2013 00:50:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Jun 2013 00:50:07 +0000 (UTC) Cc: Rich Felker To: Original-X-From: musl-return-3480-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 28 02:50:10 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UsMt7-0000HY-NT for gllmg-musl@plane.gmane.org; Fri, 28 Jun 2013 02:50:09 +0200 Original-Received: (qmail 23792 invoked by uid 550); 28 Jun 2013 00:50:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23784 invoked from network); 28 Jun 2013 00:50:08 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <20130627153429.GZ29800@brightrain.aerifal.cx> X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19980.002 X-TM-AS-Result: No--41.291100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-SA-Exim-Connect-IP: 221.199.216.119 X-SA-Exim-Mail-From: Matthew.Fernandez@nicta.com.au X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on atp-es2.it.nicta.com.au X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on atp-es2.it.nicta.com.au) Xref: news.gmane.org gmane.linux.lib.musl.general:3476 Archived-At: 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 buffe= r. > > 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 pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.