From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933393AbbJIILG (ORCPT ); Fri, 9 Oct 2015 04:11:06 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:35381 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933337AbbJIIKr (ORCPT ); Fri, 9 Oct 2015 04:10:47 -0400 From: Rasmus Villemoes To: Ingo Molnar 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 Organization: D03 References: <55F1DD53.1070102@ezchip.com> <20151005112700.GA1096@gmail.com> <87h9m57xwa.fsf@rasmusvillemoes.dk> <20151006080346.GB11523@gmail.com> <8737xnbqtn.fsf@rasmusvillemoes.dk> <20151007071821.GD7837@gmail.com> <87y4ffuk0r.fsf@rasmusvillemoes.dk> <20151008084837.GA4729@gmail.com> X-Hashcash: 1:20:151009:bp@alien8.de::mlW0y2hIkAoNXRuP:0000007Ib X-Hashcash: 1:20:151009:a.p.zijlstra@chello.nl::P4BpMn51T+fbHe0W:0000000000000000000000000000000000000000GZm X-Hashcash: 1:20:151009:mingo@kernel.org::zJUdKTPxJjIPeeJE:00SKO X-Hashcash: 1:20:151009:tglx@linutronix.de::Q0mpbIbsS/yV+7GN:000000000000000000000000000000000000000000023G1 X-Hashcash: 1:20:151009:cmetcalf@ezchip.com::Bl7fb11pyWvwjEf3:0000000000000000000000000000000000000000003hmC X-Hashcash: 1:20:151009:linux-kernel@vger.kernel.org::8jlKiryMd5naj8Ru:0000000000000000000000000000000006CdA X-Hashcash: 1:20:151009:hpa@zytor.com::3TIgu75CrghfKnEK:00008REW X-Hashcash: 1:20:151009:torvalds@linux-foundation.org::myNEIvXWm0z/6OJz:000000000000000000000000000000008/yd Date: Fri, 09 Oct 2015 10:10:43 +0200 In-Reply-To: <20151008084837.GA4729@gmail.com> (Ingo Molnar's message of "Thu, 8 Oct 2015 10:48:37 +0200") Message-ID: <87vbagwjgc.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08 2015, Ingo Molnar wrote: > * Linus Torvalds wrote: > >> So I really refuse to worry about the snprintf() family of functions wrt this >> race. I don't think it was hugely important for strlcpy() either - more of a >> "quality of implementation" issue rather than anything fundamental - but for >> snprintf and friends it's an almost unavoidable issue because of how snprintf >> works. >> [snip] >> >> Can we get odd truncated printouts in the (very very very unlikely) case that >> the string is being changed? Yes. We just don't care. > > I do agree mostly, but I think we should still try to achieve the following two > properties, if possible sanely+cheaply+cleanly: > > - the printed string should not contain spurious \0 bytes even if the %s source > 'races'. [I think this is true currently.] Sorry, no, that's not true currently. > - the return code should correctly represent what snprintf did to the target > string. [This might not be the case currently. But I'm not sure!] It does, in fact, represent "the number of characters, excluding the trailing nul byte, that would have been written if the output buffer is big enough" - but in some cases some of those bytes may happen to be '\0'. [The %s race is the only way I can see spurious \0, but \0 can also legitimately be put in the output using %c, or maybe these days also with some %p extension.] > Because that's a real concern I think: snprintf() return is used frequently to > iterate over buffers, and it should correctly and reliably represent what it did, > regardless of what the source buffer does - because snprintf obviously knows what > it did to the output buffer, it has full, race-free control over it. > > Whether left-alignment and other formatting details were calculated correctly, > etc. is a secondary concern and cannot be guaranteed, but we should at least > guarantee that we generated a single string, that we did nothing else, and that we > correctly returned its length. > > Agreed? No. More precisely, I don't agree with left-alignment etc. being a secondary concern. It's hard not to agree with the overall "let's make it more robust if it can be done sanely+cheaply+cleanly". I was a bit skeptical about whether those three requirements could be met, since we'd have to do byte-by-byte traversal of the string, maybe-copying it to the output as we go along, but then right-alignment would require us to do a memmove, but not before we've done some complicated bookkeeping exercise. However, now that I read the source again, it seems that Al Viro already did that exercise when he added dentry(). So maybe it's doable without a net increase in LOC. Rasmus