From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9CB9FA373D for ; Tue, 25 Oct 2022 23:00:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232553AbiJYXAg (ORCPT ); Tue, 25 Oct 2022 19:00:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231511AbiJYXAe (ORCPT ); Tue, 25 Oct 2022 19:00:34 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 069A5CBFD6 for ; Tue, 25 Oct 2022 16:00:33 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id m2so8320528pjr.3 for ; Tue, 25 Oct 2022 16:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=s6LZP8hvZm1H8c+TGDoLOM2VTr5Lxnor/nw5sFV/2mY=; b=eBUosIjwxzoCivbiFw947tiAH5Kc5Zjv1vE5XKCjauANrPGnJZaAjWvYUDGuc2p3ra D0o1CDbvF+anvekmPVnVtDC7TRRKwRsL6DsbvrN33f10kJRVrqHzLepIxWOfr8YWUHdG 5iP/4geENpl6p+WCcY5oEeLfXkWqGUaRijJpE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s6LZP8hvZm1H8c+TGDoLOM2VTr5Lxnor/nw5sFV/2mY=; b=ZXE1lq2Zbpis+k4Z/EIAKsIeIWm+APVWjUmeVkJ8poqCG0pF6wnoYYfg5pzYOCc1CI wyBa6CorB8BTR1O/D+aBsZuVbKF5QZ9JgPFRVyw4R2XqKIMyxQd0CtHrDEgPxpjBOQDH W9vPF0GlXFGxZrbr4IgJKw+QG4mxck2PtAkr34UkxxA3gJt+IB+Lv4jDG/RoSti0hyPC HgiBcPeuE7UztJ9WP7kE3IKLA2TxRrkl5F/HlfHFSgijxiTkjrgKVPNoYiY4U6jdQYZk QbvKCJchensSI84pgLAhZj2bOmvUHQ5IXwNX1cr8QNkb2H28BGzrgCcuHhQmoCmAh6N8 SpCw== X-Gm-Message-State: ACrzQf1rcwUjrWO8QZRK5hzeZg0wx1UVELMu83Y43oHP4fgsNnRgX9as KJY9RN+WPVpNj+5ZyEk6suqf2Q== X-Google-Smtp-Source: AMsMyM54nuuM6c/UCbGYg0BC7n31Zk4wLqgiVvdCYEO4DeWdRrGI+Ggys2dZfI4gYVoed9ITHFD2RA== X-Received: by 2002:a17:902:ec8a:b0:185:5462:261a with SMTP id x10-20020a170902ec8a00b001855462261amr40802031plg.160.1666738832501; Tue, 25 Oct 2022 16:00:32 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id cc21-20020a17090af11500b002086ac07041sm90501pjb.44.2022.10.25.16.00.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 16:00:31 -0700 (PDT) Date: Tue, 25 Oct 2022 16:00:30 -0700 From: Kees Cook To: Gabriel Paubert Cc: Linus Torvalds , Segher Boessenkool , "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-arch@vger.kernel.org, linux-toolchains@vger.kernel.org, Masahiro Yamada , Andrew Morton , Andy Shevchenko , Greg Kroah-Hartman Subject: Re: [PATCH] kbuild: treat char as always signed Message-ID: <202210251555.88933A57F@keescook> References: <20221019162648.3557490-1-Jason@zx2c4.com> <20221019165455.GL25951@gate.crashing.org> <20221019174345.GM25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 23, 2022 at 10:23:56PM +0200, Gabriel Paubert wrote: > On Sat, Oct 22, 2022 at 11:16:33AM -0700, Linus Torvalds wrote: > > Practically speaking this might be a bit painful, because we've got > > several different variations of this all due to all the things like > > our debugging versions (see for example), so > > some of our code is this crazy jungle of "with this config, use this > > wrapper". > > I've just had a look at that code, and I don't want to touch it with a > 10 foot pole. If someone else to get his hands dirty... Heh. Yes, fortify-string.h is a twisty maze. I've tried to keep it as regular as possible, but I admit it is weird. On my list is to split compile-time from run-time logic (as suggested by Linus a while back), but I've worried it would end up spilling some of the ugly back into string.h, which should probably not happen. As such, I've tried to keep it all contained in fortify-string.h. Regardless, I think I'd rather avoid yet more special cases in the fortify code, so I'd like to avoid using transparent union if we can. It seems like -funsigned-char and associated fixes will be sufficient, though, yes? -- Kees Cook