From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 23:16:02 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD05106564A for ; Sat, 28 Jul 2012 23:16:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFF078FC21 for ; Sat, 28 Jul 2012 23:16:01 +0000 (UTC) Received: by weyx56 with SMTP id x56so3383602wey.13 for ; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05KygHWNThcV6CzudxTlOUnsp+j9SdkqdSzRzXZT+A0=; b=dP9yqEsHzkOoJzs+AnZw2GuXoYg5rphsg4RR/zL2eL7k6ymjsVn3esfVpJbmoqQSJX HI+psNXJk985GSTzq5tloDZTUM9Cm335stZZVR7PhJRK8Ebub0rIeAYbYCyfWAwy8Nb2 kgG4jABhjqaPC6vLG0EB3IoWL8zv8pgiId959otDzh9jWEjiWeIGh3GaIBExyma+GfrG D3g9aUwF66ubHCN8CBUkF5yQKiHnUUfwI7HBjjMjnONbsAI0zmXIRjHqr+qiZ0dm7qqb HGTun4Bdg1h9FWASAMCtZKlXt6ru0TXP/T1oh9EM1VNNSN/d8I1aEYXJJ5QNB8Pb4fqJ 2JgA== MIME-Version: 1.0 Received: by 10.216.183.140 with SMTP id q12mr3131225wem.58.1343517360607; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 16:16:00 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 19:16:00 -0400 Message-ID: From: Arnaud Lacombe To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 23:16:02 -0000 Hi, On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb wrote: > On Sat, 28 Jul 2012, Arnaud Lacombe wrote: > >> Hi, >> >> On Sat, Jul 28, 2012 at 6:14 PM, Bjoern A. Zeeb >> wrote: >>> >>> On Wed, 25 Jul 2012, Luigi Rizzo wrote: >>> >>>> During some ipfw/dummynet cleanup i noticed that the libkern version of >>>> inet_ntoa_r() is missing the buffer size argument that is present in >>>> the libc counterpart. >>>> >>>> Any objection if i fix it ? >>> >>> >>> >>> And why exactly would you need it? What does libc do with it? Render >>> partial IPv4 addresses? >>> >> Mitigate possibilities of memory corruption ? At the very least, allow >> the following: >> >> { >> char tmp[sizeof "255.255.255.255"]; > char tmp[INET_ADDRSTRLEN]; > Should I mention that this is taken directly from `lib/libc/inet/inet_ntop.c' ? you may want to fix it, as you have been blessed with a commit bit. >> >> KASSERT(size >= (sizeof tmp)); > > This would need to go into the called library function and cannot. > > So that gives you what extra checking exactly? That the programmer got > the sizeof right rather than the buffer size? You pushed some more on the > stack or reused an register That is funny. I was told that 2 always unused extra argument all along the mutex API could not change anything, and now I am told the opposite for 1 argument. There is no point trading the cost of a register for overall runtime correctness. This is a string manipulation function, it must be doing some kind of size check. > for something that is supposed to be at a minial fixed length > "supposed to be" ? you do not seem to be really sure to know how inet_ntoa_r() is gonna be used, nor have you any way, by your words, enforce it in any way. > (nothing else lower allowed and will ever result > in anything but misbehaviour) no matter what. > I'd be more than happy to welcome you tracking down memory corruption based misbehaviors, but I prefer to detect it before, than attempt to catch it after, it happens. > It's not like it's > inet_pton which can take totally different sizes. > that's nothing but an implementation details. > > Which again leaves me with the question - why does libc have it? > It is passed down to strlcpy(). You could have found this out by yourself in a minute or so... But again, implementation details, might they be incomplete, are irrelevant. - Arnaud