Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2226888ybn; Thu, 26 Sep 2019 08:48:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJv67JVtVjwjmOvdeMqb+4jN8efyd7xBx7xQVkCcKYJi5nFUqiySR2NYZzJqfj3gKa1EFr X-Received: by 2002:a17:906:4541:: with SMTP id s1mr3800812ejq.210.1569512888795; Thu, 26 Sep 2019 08:48:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569512888; cv=none; d=google.com; s=arc-20160816; b=Yn7JGN3IjQU8enmW87EDelhh8DG65Jj+baq9n6nZwSOZy0c/Hzywf6fDMHKX/trSHG d+WSrUvm9cDOvFqgzom4kUQntHcS234npHce7gpB2Wi97WC3SJYRzLnUhoznoaoE+x4N 9ESM38cn1YHZVSEkpEjdhKpBliuwLGGqluWMi5jtWQhDYUWOrYTK/OYkNXW5bvHm2TYK X2bWq8eoofVN0VviB+MDUXtPOphMB9dgBfCNivfMkiYVYd/ZmNhs67Fm/2JoTECQeoph GkKXiM2HakBG/FIFzP59olMFfg0gA8iQ4SWmAHKvgT8TftVySvlBcWx64VMqBGx+y0sJ 8fDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=5ZbnURneNamOfnAb8QQHRVCtDN7XxRbs7mNJ0pCMRFE=; b=NVTdmjkSw+JveoWNDt0KBE5vPs/TBJu88BqRYg6gYO6E0AT3sbhrU8uURmZK2bVWUR B8xHW0sbxJp+K3Q/XW2IiKJwU83SX8WpD+Mcr/tT+TXvfVua7d6yBP2WOt2xxVYA+sR/ 7FvRamd91uSQwV8KOoyvTEpoGQm5smH+qz2j19onLVw7TK3yrIN9NKQdi8MKPgWQTye5 bO9PKdbqTwYIbo+uU7/6RDbXWHuZxtXYVWFsJ3Ety8AMt/zTIurXTJJg1lIgcjIIydMZ GwdmP7MoU8tkQmmd3WEhAZ86csthfHVYzw70PNKhoO92dGgUQZXLvwzKeLv2C7fb0Jf/ 1Fbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=hu1Avh6H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16si1615612edb.341.2019.09.26.08.47.45; Thu, 26 Sep 2019 08:48:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=hu1Avh6H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727338AbfIZPpI (ORCPT + 99 others); Thu, 26 Sep 2019 11:45:08 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:35092 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726845AbfIZPpI (ORCPT ); Thu, 26 Sep 2019 11:45:08 -0400 Received: by mail-pf1-f193.google.com with SMTP id 205so2084027pfw.2 for ; Thu, 26 Sep 2019 08:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5ZbnURneNamOfnAb8QQHRVCtDN7XxRbs7mNJ0pCMRFE=; b=hu1Avh6HcqLpy5a9yjDIQN3+CC8g6gnkJFoWqDCO74VwYbTG2Id9OyLgbNOP4Zax2v 21g4LHuBUdfx0xCL4QtJXtzPd20X3Ti4LQkQb1fq7Gn/gBRxQ1++jWdW3ENuPcpEPT15 xsp4sYKWdHQzYVDTqdJgT/FZm3JyuDW95iOos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5ZbnURneNamOfnAb8QQHRVCtDN7XxRbs7mNJ0pCMRFE=; b=uRBve7amHaUGMxE6VETNkcOJYQFD5d9ClWJmv2mpigKBwlH7KvoODe8TEObrcN5ZUQ Q61TgTmPutLGbBrFpgQhx8481xqmfs9GMcDK3t1/ZnEV9UdP6ThEhvF4cve9tkDucE/S IOtCgZmdzHf7oViPE+2dEB5MHhZeX2VRKJN2S/ddRuFsZPGsvubCyJ+PxsQ/8rhLeCbL nGSV6R/0SxZfr+j0hqQRYuhm6c7HEW7FyOjsL3r5ylrHY1zAuzFQbqrvzo1u4d/LC3kx mzYc2hZcx2OhlKjatzI4769ioSwFevxqACBBcqAnciE66lR2qcjpk05xULlJJMgZyhSV 2czw== X-Gm-Message-State: APjAAAXhHgr0XVrzhNokkdKX6T8saB0xqq2nA4aGMBkd+5L5vK6aGaA+ E/JyDJQArj2Aj/bDBjyqMXT0Kw== X-Received: by 2002:a63:2b01:: with SMTP id r1mr3806943pgr.19.1569512707669; Thu, 26 Sep 2019 08:45:07 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id n3sm2857002pff.102.2019.09.26.08.45.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 08:45:06 -0700 (PDT) Date: Thu, 26 Sep 2019 08:45:05 -0700 From: Kees Cook To: Joe Perches Cc: Andrew Morton , Julia Lawall , Linus Torvalds , linux-kernel@vger.kernel.org, Jonathan Corbet , Stephen Kitt , Nitin Gote , jannh@google.com, kernel-hardening@lists.openwall.com, Rasmus Villemoes Subject: Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms Message-ID: <201909260842.CDA50B7E3@keescook> References: <20190925145011.c80c89b56fcee3060cf87773@linux-foundation.org> <56dc4de7e0db153cb10954ac251cb6c27c33da4a.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56dc4de7e0db153cb10954ac251cb6c27c33da4a.camel@perches.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 26, 2019 at 01:34:36AM -0700, Joe Perches wrote: > On Wed, 2019-09-25 at 14:50 -0700, Andrew Morton wrote: > > On Tue, 23 Jul 2019 06:51:36 -0700 Joe Perches wrote: > > > > > Several uses of strlcpy and strscpy have had defects because the > > > last argument of each function is misused or typoed. > > > > > > Add macro mechanisms to avoid this defect. > > > > > > stracpy (copy a string to a string array) must have a string > > > array as the first argument (dest) and uses sizeof(dest) as the > > > count of bytes to copy. > > > > > > These mechanisms verify that the dest argument is an array of > > > char or other compatible types like u8 or s8 or equivalent. > > > > > > A BUILD_BUG is emitted when the type of dest is not compatible. > > > > > > > I'm still reluctant to merge this because we don't have code in -next > > which *uses* it. You did have a patch for that against v1, I believe? > > Please dust it off and send it along? > > https://lore.kernel.org/lkml/CAHk-=wgqQKoAnhmhGE-2PBFt7oQs9LLAATKbYa573UO=DPBE0Q@mail.gmail.com/ > > I gave up, especially after the snark from Linus > where he wrote I don't understand this stuff. > > He's just too full of himself here merely using > argument from authority. > > Creating and using a function like copy_string with > both source and destination lengths specified is > is also potentially a large source of defects where > the stracpy macro atop strscpy does not have a > defect path other than the src not being a string > at all. > > I think the analysis of defects in string function > in the kernel is overly difficult today given the > number of possible uses of pointer and length in > strcpy/strncpy/strlcpy/stracpy. > > I think also that there is some sense in what he > wrote against the "word salad" use of strcpy, > but using stracpy as a macro when possible instead > of strscpy also makes the analysis of defects rather > simpler. > > The trivial script cocci I posted works well for the > simple cases. > > https://lore.kernel.org/cocci/66fcdbf607d7d0bea41edb39e5579d63b62b7d84.camel@perches.com/ > > The more complicated cocci script Julia posted is > still not quite correct as it required intermediate > compilation for verification of specified lengths. > > https://lkml.org/lkml/2019/7/25/1406 > > Tell me again if you still want it and maybe the > couple conversions that mm/ would get. FWIW, I want it because it creates a compile-time-verifiable API for a non-trivial set of common string copying flaws. CONFIG_FORTIFY_SOURCE isn't able to handle these (yet?) because it's examining the outer size of structures that hold char arrays. And even if we built in the logic to deal with it correctly, it'd still split the detection between compile time and run time. -Kees -- Kees Cook