Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp1040852pxy; Sun, 1 Aug 2021 10:20:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbZ2WA0+u9FGKHhJXPjAKbX6ze07fnPpY37RWFPNv+TsMxjjGuy16+q+l7oJmZkCeRxBb4 X-Received: by 2002:a17:906:5ac5:: with SMTP id x5mr9445216ejs.271.1627838457929; Sun, 01 Aug 2021 10:20:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627838457; cv=none; d=google.com; s=arc-20160816; b=QDFuJ902S0mo2nNFkFkuryKrzYYaMKpIJlM0bqQJcY5IPuooQ0xSr7kVK3PF8D8xGe hV7FzoKbh9iWgpBLlz0K7aIO0eazi1HqSChJmNWdUoN2OvZrg54g3gcsiv+XVvwP0zOR RDbJinQkpf4cSYlOb3SU+RK4wmkwtIaE8+7xlsEqHOuXwpWTR4ZlcEwU/XLa8whUwumq rAWCyOdzxcSfcekPf4pTywgVIbPPs8S2nLRe0fxZbPOGMrZBY3d8L2g3ex1AXI+Bl2vp i/3wym1TP05HpZqmfskjbDi/hXuNBN3edgrN6qtTmhhDCY5yvp5TNsGRzgDTeVLyeSaJ qxFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=6x3QWVYNzA8oWY+P2CnHY/LSOtwPRNB5RDZ9JILj+eY=; b=A9kcTLYD0HRmjI6nnpALyVziqTXrOqBqvvZ2bL7/aaDmJIbv8VqOVAXHMyHvzUoISb 6hk5n4Q5XfeUXml6MYx7EfxROVZhFCYYN5NIFGnDhLi7yu74YkupfSEMKNk4mxR3U/8v s5PJnPmea+WmQs3XXmK1YEYVzSvZIjAB5w/FsAXGSQQO5aYbc5Eh1/X20QMInbUoSdeK 1rUacCspMGSNED0FzAhCJIrsNxKb7O/bCZcmWGJ3W26ZzFO6Tx52mfFhZJA4h5+J6sXi CX/Kg0bU/z50gNoVb/1N9xGh39QGyOGSSmCewGuMK2+a9aX9s+QW8KqgJbSa2HG6xGvs 0RnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="ky/IPsSG"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si7107488edw.373.2021.08.01.10.20.33; Sun, 01 Aug 2021 10:20:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="ky/IPsSG"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229658AbhHARTV (ORCPT + 99 others); Sun, 1 Aug 2021 13:19:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229592AbhHARTU (ORCPT ); Sun, 1 Aug 2021 13:19:20 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCD07C06175F; Sun, 1 Aug 2021 10:19:11 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id u2so8676274plg.10; Sun, 01 Aug 2021 10:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6x3QWVYNzA8oWY+P2CnHY/LSOtwPRNB5RDZ9JILj+eY=; b=ky/IPsSGP1pgCJX+7tKzpqQbcF8UtDmxisvlH8DgENnL54BDKicV0UV3XIICgvK8TL ymkgV8EfwN/3pa/Xu0smcU3oNqgJKjpZATBK1MtbKGJqvhAHS5r+6QjAvT/IVkVcOvF2 bZNxmk5pBUL4KfRtTJluK/fN6Lab9+r0UvO3ejwmoHaKuA9MKTe32GgIl3mMTEr/tEXb 9dtKwdLJpROQgbjLVWASLPGeMoubl9qow4ZlmaL4m3GmpJ2wgXi8A4tzw04clOqixFeq TOIsv4xcmLTU6N70ZrIoT+F8IFan3zTXC+EBtrUdr0rgJ+s2jvhZrIIkzXexwCJULET4 5tqw== 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=6x3QWVYNzA8oWY+P2CnHY/LSOtwPRNB5RDZ9JILj+eY=; b=BJP6wUKUY4zYYgt26MHakNQmdC6dieqeYe79Kh23e5+RBPgzAhfm1BmxhGPCsjgLHf 0cvwoKQ1+sUn03qj0rFoZukhtCGGmAAJE8IyJACzocxmGcU1CI+GiU2EfR6PyXT6L83V UH6Es8crAhmVzgoo29nSlYfh1uBHNpcfSPjHWNS551HK7iTOGcnkb7FLYbZp8qau3opS V0Y58Ko5OrySDySBCPH1hFFqRBZZ6W5ew0/0UPNJMMKysleBIdPtsExzC80EZG8DIF6Y OCnMISise6ixZGLqYP4z5ltDnMrYcoPk9LYg4IPSPtj9oMB+cT7r4CFDvU4+7IJPEx4S bGHQ== X-Gm-Message-State: AOAM531lRq0dNF88jb6jsJh5YKapBikjsQn90vD7hzSCjWq0ysP6FS7j B2S8A5RxmWc1iujJoTOScUg= X-Received: by 2002:a17:902:7d82:b029:12c:5930:98c7 with SMTP id a2-20020a1709027d82b029012c593098c7mr11080561plm.46.1627838350958; Sun, 01 Aug 2021 10:19:10 -0700 (PDT) Received: from google.com ([2620:15c:202:201:f80c:7a7e:9e46:8cee]) by smtp.gmail.com with ESMTPSA id p17sm8613878pfh.33.2021.08.01.10.19.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Aug 2021 10:19:09 -0700 (PDT) Date: Sun, 1 Aug 2021 10:19:07 -0700 From: Dmitry Torokhov To: Kees Cook Cc: Len Baker , "Russell King (Oracle)" , Lee Jones , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , linux-hardening@vger.kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Joe Perches Subject: Re: [PATCH] drivers/input: Remove all strcpy() uses in favor of strscpy() Message-ID: References: <20210801144316.12841-1-len.baker@gmx.com> <20210801145959.GI22278@shell.armlinux.org.uk> <20210801155732.GA16547@titan> <202108010934.FA668DEB28@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202108010934.FA668DEB28@keescook> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 01, 2021 at 09:44:33AM -0700, Kees Cook wrote: > On Sun, Aug 01, 2021 at 05:57:32PM +0200, Len Baker wrote: > > Hi, > > > > On Sun, Aug 01, 2021 at 04:00:00PM +0100, Russell King (Oracle) wrote: > > > On Sun, Aug 01, 2021 at 04:43:16PM +0200, Len Baker wrote: > > > > strcpy() performs no bounds checking on the destination buffer. This > > > > could result in linear overflows beyond the end of the buffer, leading > > > > to all kinds of misbehaviors. The safe replacement is strscpy(). > > > > > > > > Signed-off-by: Len Baker > > > > --- > > > > This is a task of the KSPP [1] > > > > > > > > [1] https://github.com/KSPP/linux/issues/88 > > > > > > > > drivers/input/keyboard/locomokbd.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c > > > > index dae053596572..dbb3dc48df12 100644 > > > > --- a/drivers/input/keyboard/locomokbd.c > > > > +++ b/drivers/input/keyboard/locomokbd.c > > > > @@ -254,7 +254,7 @@ static int locomokbd_probe(struct locomo_dev *dev) > > > > locomokbd->suspend_jiffies = jiffies; > > > > > > > > locomokbd->input = input_dev; > > > > - strcpy(locomokbd->phys, "locomokbd/input0"); > > > > + strscpy(locomokbd->phys, "locomokbd/input0", sizeof(locomokbd->phys)); > > > > > > So if the string doesn't fit, it's fine to silently truncate it? > > > > I think it is better than overflow :) > > > > > Rather than converting every single strcpy() in the kernel to > > > strscpy(), maybe there should be some consideration given to how the > > > issue of a strcpy() that overflows the buffer should be handled. > > > E.g. in the case of a known string such as the above, if it's longer > > > than the destination, should we find a way to make the compiler issue > > > a warning at compile time? > > > > Good point. I am a kernel newbie and have no experience. So this > > question should be answered by some kernel hacker :) But I agree > > with your proposals. > > > > Kees and folks: Any comments? > > > > Note: Kees is asked the same question in [2] > > > > [2] https://lore.kernel.org/lkml/20210731135957.GB1979@titan/ > > Hi! > > Sorry for the delay at looking into this. It didn't use to be a problem > (there would always have been a compile-time warning generated for > known-too-small cases), but that appears to have regressed when, > ironically, strscpy() coverage was added. I've detailed it in the bug > report: > https://github.com/KSPP/linux/issues/88 > > So, bottom line: we need to fix the missing compile-time warnings for > strcpy() and strscpy() under CONFIG_FORTIFY_SOURCE=y. Is it possible to have them warn always? Or that would be too many false positives? > > In the past we'd tried to add a stracpy()[1] that would only work with > const string sources. Linus got angry[2] about API explosion, though, > so we're mostly faced with doing the strscpy() replacements. I would like to have an API that would do compile-time checks and BUILD_BUG_ON() for a few places in input drivers where we copy constant strings. There is no reason to encumber the code with runtime checks, and bombing out on compile instead of truncating would be nice. > > Another idea might be to have strcpy() do the "constant strings only" > thing, leaving strscpy() for the dynamic lengths. > > One thing is clear: replacing strlcpy() with strscpy() is probably the > easiest and best first step to cleaning up the proliferation of str*() > functions. OK, so the consensus is that we set this patch aside as it does not really fix any issues (the strcpy() destination is 32 bytes and is big enough to hold the string being copied)? Thanks. -- Dmitry