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 C007EC433FE for ; Wed, 19 Oct 2022 19:31:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230520AbiJSTbV (ORCPT ); Wed, 19 Oct 2022 15:31:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230267AbiJSTbT (ORCPT ); Wed, 19 Oct 2022 15:31:19 -0400 Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2338C16D56F for ; Wed, 19 Oct 2022 12:31:18 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id a24so12360242qto.10 for ; Wed, 19 Oct 2022 12:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SfmIq/KsseXkXGtgL/kNTADzR8nUzxj3FoT5DEC/Nzo=; b=X0bTSQDVigCsGSNgiew3B/3pbsp2ciGVZzYaoUwX27U3MUaI1cRc3mpMYk36lod3le PZeYdP/7vmxRFYoWQgPrD48IT8dIrD0IZA3+6io9VnGCbLbD1BneL65qRDHRGninF1si o+6Qmn1KAsm4NEKuh2u1NvPTsyG+1+K5JKoxA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SfmIq/KsseXkXGtgL/kNTADzR8nUzxj3FoT5DEC/Nzo=; b=LxgUM+6GHaurLJ9QupCJnyvxRuFDBT1Zl9ipwMxjrLi1JPP7yoGTnU+xmb9c9BYubg PITeW3YPifVFijkKUEg4fstdHXWeUDocBv7l1ZpXkN49gsebUUdp94bjFM5qll+4DFhm zIt+2qf2PExgHvu/E6piTpwVpK5LIFdXMAZEYieYNFr6V1tJgMDzEkla6m8GNrSPV9Aq DFFTDQOKJsjxLsFgv1VwUwvU1TWG0zL4EdQAVdr2KF4m/vA/3RQzAWyPDDtKHuCqe5Ca e2gz2MeutmBprfDhgnrnBlDqvPVJaICxs7X1DfzyjM0puyt9YdBa8ABK5CkfpwGJ2Rhu SePg== X-Gm-Message-State: ACrzQf2GAOl6dln78JusgAB82Br6OXRbfLdg7eqUYHwALzrzjq3Id1Q8 Mjn/udaMfIzutshBYtq30edxT17zLvfb5Q== X-Google-Smtp-Source: AMsMyM7XsjCmU3X9G9bYLqwDS21dtvK5dL/8RBDtyRoPO9b+ZAVJtN49TVs1GWQ9q0mdCBXmZdo55w== X-Received: by 2002:ac8:5ac5:0:b0:39c:f8f5:c432 with SMTP id d5-20020ac85ac5000000b0039cf8f5c432mr6609482qtd.33.1666207876917; Wed, 19 Oct 2022 12:31:16 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id u6-20020a05620a430600b006e16dcf99c8sm5671573qko.71.2022.10.19.12.31.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 12:31:16 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id r3so22047780yba.5 for ; Wed, 19 Oct 2022 12:31:16 -0700 (PDT) X-Received: by 2002:a05:6902:1147:b0:6c3:ff50:565e with SMTP id p7-20020a056902114700b006c3ff50565emr7551417ybu.362.1666207876006; Wed, 19 Oct 2022 12:31:16 -0700 (PDT) MIME-Version: 1.0 References: <20221019162648.3557490-1-Jason@zx2c4.com> <20221019165455.GL25951@gate.crashing.org> <20221019174345.GM25951@gate.crashing.org> <202210191209.919149F4@keescook> In-Reply-To: <202210191209.919149F4@keescook> From: Linus Torvalds Date: Wed, 19 Oct 2022 12:30:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: treat char as always signed To: Kees Cook Cc: Nick Desaulniers , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, Oct 19, 2022 at 12:11 PM Kees Cook wrote: > Yeah, I've had to fight these casts in fortify-string.h from time to > time. I'd love to see the patch you used -- I bet it would keep future > problems at bay. Heh. The fortify-source patch was just literally - unsigned char *__p = (unsigned char *)(p); \ + char *__p = (char *)(p); \ in __compiletime_strlen(), just to make the later __ret = __builtin_strlen(__p); happy. I didn't see any reason that code was using 'unsigned char *', but I didn't look very closely. But honestly, while fixing that was just a local thing, a lot of other cases most definitely weren't. The crypto code uses 'unsigned char *' a lot - which makes a lot of sense, since the crypto code really does work basically with a "byte array", and 'unsigned char *' tends to really be a good way to do that. But then a lot of the *users* of the crypto code may have other ideas, ie they may have strings as the source, where 'char *' is a lot more natural. And as mentioned, some of it really is just fairly fundamental compiler confusion. The fact that you can't use a regular string literals with 'unsigned char' is just crazy. There's no *advantage* to that, it's literally just an annoyance. (And yes, there's u"hello word", but and yes, that's actually "unsigned char" compatible as of C23, but not because the 'u' is 'unsigned', but because the 'u' stands for 'utf8', and it seems that the C standard people finally decided that 'unsigned char[]' was the right type for UTF8. But in C11, it's actually still just 'char *', and I think that you get that completely broken sign warning unless you do an explicit cast). No sane person should think that any of this is reasonable, and C23 actually makes things *WORSE* - not because C23 made the right choice, but because it just makes the whole signedness even messier. IOW, signedness is C is such a mess that -Wpointer-sign is actively detrimental as things are right now. And look above - it's not even getting better, it's just getting even more confusing and odd. Linus