From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751159AbbJGHS0 (ORCPT ); Wed, 7 Oct 2015 03:18:26 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:37143 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbbJGHSZ (ORCPT ); Wed, 7 Oct 2015 03:18:25 -0400 Date: Wed, 7 Oct 2015 09:18:21 +0200 From: Ingo Molnar To: Rasmus Villemoes Cc: Linus Torvalds , Chris Metcalf , open list , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , Borislav Petkov Subject: Re: [PATCH] string: Improve the generic strlcpy() implementation Message-ID: <20151007071821.GD7837@gmail.com> References: <55F1DD53.1070102@ezchip.com> <20151005112700.GA1096@gmail.com> <87h9m57xwa.fsf@rasmusvillemoes.dk> <20151006080346.GB11523@gmail.com> <8737xnbqtn.fsf@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737xnbqtn.fsf@rasmusvillemoes.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Rasmus Villemoes wrote: > On Tue, Oct 06 2015, Ingo Molnar wrote: > > > * Rasmus Villemoes wrote: > > > >> > >> I'm not against making strlcpy more robust, but I think the theoretical race is > >> far more likely to manifest through a member of the printf family. > > > > So the printf family is generally less frequently used in ABI output than string > > copies, > > Huh? snprintf and friends are often used just to copy or concatenate > strings (essentially, any format string containing no specifiers other > than %s does exactly that) - even if a str*() function could do the same > thing. I see no reason to believe this wouldn't also be done in cases > where the final string ends up being presented to userspace. But 'format string' usually means 'human output', and most of our ABI pertains to system calls where we rarely form human output, we typically generate programmatically actionable data structures. We have procfs and sysfs as well, where format strings are indeed dominant, but are you sure this race exists in snprintf() in that form? I.e. can the return value of snprintf() be different from the true length of the output string, if the source string is modified in parallel? > > So I'd improve it all in the following order: > > > > - fix the strscpy() uninitialized use > > > > - base strlcpy() on strscpy() via the patch I sent. This makes all users faster > > and eliminates the theoretical race. > > I'm not so sure about that part. I'd strongly suspect that the vast > majority of strings handled by strlcpy (and in the future strscpy) are > shorter than 32 bytes, so is all the word_at_a_time and pre/post > alignment yoga really worth it? That's a good question, I'll measure it. Thanks, Ingo