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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B342C47DD9 for ; Wed, 28 Feb 2024 17:21:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E63426B00A1; Wed, 28 Feb 2024 12:21:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E13BB6B00A2; Wed, 28 Feb 2024 12:21:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB4556B00A3; Wed, 28 Feb 2024 12:21:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BAA956B00A1 for ; Wed, 28 Feb 2024 12:21:37 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1AA981A0299 for ; Wed, 28 Feb 2024 17:21:37 +0000 (UTC) X-FDA: 81841879434.30.99A77EF Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf10.hostedemail.com (Postfix) with ESMTP id 54BFBC001F for ; Wed, 28 Feb 2024 17:21:35 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hzlzyBNF; spf=pass (imf10.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709140895; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=W1bHapS5+5iN8in9GHCNPDr+SpYos985v6N2aaB8ggk=; b=lyMxVIXzveJtnIUMl1E9Sry53V9QFWn97+sgVMz2MkUNk0vO/ynyclRu7AX2xrvCUvvzIb q/Z0K/FIW9AyebITggsX8o+d/IGpURwW1wuu98VD6RmVHK0MFAP9emVTnzcTvy1x9DqMfK KT5tg88EJM3kV+L0GBiwMzroOzPod6s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709140895; a=rsa-sha256; cv=none; b=ce7YYXheoN+ghp1qWcBLMhkJbxys+NzcMNnMTNow9B3Y2VfBjz1sLKXn5zEiXQPhoGDzTB OZdj+XuA9H7dZm+fXbrihxs9FMapKB1VcxacBLdh9BNQ43bG+OLk3SOmaT0eMPOBlBL9bq SXQGaprKvDMq0x1pmcZlWuVuSN7hFIc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=hzlzyBNF; spf=pass (imf10.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-6e4e7e25945so3363932b3a.1 for ; Wed, 28 Feb 2024 09:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709140894; x=1709745694; darn=kvack.org; 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=W1bHapS5+5iN8in9GHCNPDr+SpYos985v6N2aaB8ggk=; b=hzlzyBNFrIwSuMMkxqoPRdaYBWLtWBjKFsW+ZZ28DTrOKV/p4LE13PCVKHKHhdzNZk 8YTxfB0hoJr0+kmRYP8+mTiXgOaffTusIDIjeoyuTAGA9xXGBcuvD+/zT7JILcMmrhGK Iya4wu4sz26AkvPe54thprAb+hAQPvVZYFasY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709140894; x=1709745694; 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=W1bHapS5+5iN8in9GHCNPDr+SpYos985v6N2aaB8ggk=; b=R5fe+N51P0/gsjAfeqxP9CPVxkn1JU0CDlPz2Pp6VP2DjVWwMm/6gECEKlAK1ba64H f6eM2mIzuppIzCjib65dtpWif0s6bchNjXaolKQigpS7Dw/T8v0UWA/0Tu1kWn4/vtkZ X5bLvaufQraqGJRt9qFUA26+1B5Z/MIiqE5UoN8Sqgv/UA5igqrvbXMxPIyXz60WdkDZ gB+he9afz80cxQRnoqGgfwz0I69gQrs2PNde7xEwmzIJqo+DDXDR98t5GGzwkcn9kwba nK3kKWESCgYCdnJ2tRx59dcKfnbforMwefP5pn4Yog2hu3sYwjUy/YmRgdipOftwaAcI HjAA== X-Forwarded-Encrypted: i=1; AJvYcCXCa6E0KSg8jILhTRcakr9rLxaZUnM/9wMsRek4QlradqOzuSdPVDOnr2vdZSvcGdwPTBcDJL7cJXj58FlhJvDUQMg= X-Gm-Message-State: AOJu0YwkluCogylOQQvOpBc17EGTA1513Z3W6j4FrAfC0i4fKySoybFQ awIIT87kN19Lki8hqHSHOUXJ/axf/9CqCczMkMoC3nBBW/CtdH8DbCM/uFVNHg== X-Google-Smtp-Source: AGHT+IFxqvM5hQDYAzOob05oGJvol0U6qboX77jQeHs6sC34fTUoZvoLbeslLh+rshINZpV8envxoA== X-Received: by 2002:aa7:8650:0:b0:6e5:84f6:2a9e with SMTP id a16-20020aa78650000000b006e584f62a9emr91910pfo.31.1709140894116; Wed, 28 Feb 2024 09:21:34 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id it1-20020a056a00458100b006e583a649b4sm90257pfb.210.2024.02.28.09.21.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Feb 2024 09:21:33 -0800 (PST) Date: Wed, 28 Feb 2024 09:21:33 -0800 From: Kees Cook To: Christophe Leroy Cc: "Edgecombe, Rick P" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "luto@kernel.org" , "dave.hansen@linux.intel.com" , "debug@rivosinc.com" , "akpm@linux-foundation.org" , "Liam.Howlett@oracle.com" , "mingo@redhat.com" , "linux-csky@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "kirill.shutemov@linux.intel.com" , "linux-snps-arc@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "loongarch@lists.linux.dev" , "hpa@zytor.com" , "peterz@infradead.org" , "sparclinux@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "bp@alien8.de" , "linux-alpha@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "broonie@kernel.org" , "x86@kernel.org" Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info Message-ID: <202402280912.33AEE7A9CF@keescook> References: <20240226190951.3240433-1-rick.p.edgecombe@intel.com> <20240226190951.3240433-6-rick.p.edgecombe@intel.com> <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu> <202402271004.7145FDB53F@keescook> <8265f804-4540-4858-adc3-a09c11a677eb@csgroup.eu> <91384b505cb78b9d9b71ad58e037c1ed8dfb10d1.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 54BFBC001F X-Rspam-User: X-Stat-Signature: moa6d9979gbdc94onaqdajx3ug4itmfb X-Rspamd-Server: rspam03 X-HE-Tag: 1709140895-392651 X-HE-Meta: U2FsdGVkX1/sZWk1bu9B465YyAIGiCNbAPrsTDnaBe960eeHNMaMNRKq3U63CHP8zpE9Jp6FHqhlfi3HaGsVYlcNIqRAtlmmnWdDRkePkHSqp3wNmEDapB+DeIAf0NI9wjbCFyH6ToS6EtamFspp/tEYPwApI21mufLhKGWaz4WzxPS8EIl5gFNti6/aCkNXfv1/2hBxjaiV6SNIw6VWM/VRURUtdQnIOvAPt/CXvpYm2O1DqnK/dIZGNEl0iHaznmnYYb/l65E8p5e411aUfemo4QtkeSo2KZNVYINF/kKYxG/OO8B+c/YUHvWAtI8TNkde8M8DzcY7ztP3bd6qIR0pejsNOqskzfwRCCuZu8/4AvEegeDo+6CB0e9DCf2nA5frbk7lJAj5j/BOVEdc7EXfqShLvRUWTfBv5XGHNSZlz6KDTlN57Q/zLAV2CEnN4yAxBjzTry+cYASNpZDwdBz+O4sd63RZAyn9SATt/FxjvAtSg3rYm6l14OQdQUlcdBD6ucQEtp+3N3VHa2uNIzMq5FI5177um7h91LmxuA2roAhprFttP0UKW9rBsOdSyni6AgxBDT0u6vhiqxv9oBCMGZ01WS5KVT9CEVjXU+eBMb3pAd5GBff2sAkSDm981wH2lPsBkbWVmE+Od2waHGyaiqcgWBEQA+LkHw1ErhF1a3bB9GUZy8dWjGzSxop8+/Ton8FVxqns9uQDpQGzk2yuYWhxPU2GYcrIXnKenPqAN1t17vrmvK1vVzqfMqNh6gfYo9coPMTSageBLjSIRT/nsj5AgS7c/rtYNlAkguEaAcMW65dCkBHCcMQfNq632+44+8z42XVd3aXiUA1FEkXC2x0x8VeWXHI/JwIwZFo4gMXc0DLwLqj/C4h+Vgoi7wK+E1y0Z+6qBXkBLA2ya8s96MOaWdrlsnPeEghUyFtw9dliCYKjLFyT5ORebCnL0LlaXsNpdSMtcKMhWUK qyjBKSX5 rz7JdFsJFAqZCx9EpTrMnz/k8II/Vv7X7AoQT1traBK1weRVIEENgWd4xrEz3UdT8u9S/HZ94u1Wgkv0I63iELm8tmWGKVve8w+62NsuDsWHpSiFX6cTWflZU0EaNYIL6IAZ5zwaj6eVRwWQdhJpFeT/wbmh7kWJPkr7XXNcsq+g82a4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000453, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 28, 2024 at 01:22:09PM +0000, Christophe Leroy wrote: > [...] > My worry with initialisation at declaration is it often hides missing > assignments. Let's take following simple exemple: > > char *colour(int num) > { > char *name; > > if (num == 0) { > name = "black"; > } else if (num == 1) { > name = "white"; > } else if (num == 2) { > } else { > name = "no colour"; > } > > return name; > } > > Here, GCC warns about a missing initialisation of variable 'name'. Sometimes. :( We build with -Wno-maybe-uninitialized because GCC gets this wrong too often. Also, like with large structs like this, all uninit warnings get suppressed if anything takes it by reference. So, if before your "return name" statement above, you had something like: do_something(&name); it won't warn with any option enabled. > But if I declare it as > > char *name = "no colour"; > > Then GCC won't warn anymore that we are missing a value for when num is 2. > > During my life I have so many times spent huge amount of time > investigating issues and bugs due to missing assignments that were going > undetected due to default initialisation at declaration. I totally understand. If the "uninitialized" warnings were actually reliable, I would agree. I look at it this way: - initializations can be missed either in static initializers or via run time initializers. (So the risk of mistake here is matched -- though I'd argue it's easier to *find* static initializers when adding new struct members.) - uninitialized warnings are inconsistent (this becomes an unknown risk) - when a run time initializer is missed, the contents are whatever was on the stack (high risk) - what a static initializer is missed, the content is 0 (low risk) I think unambiguous state (always 0) is significantly more important for the safety of the system as a whole. Yes, individual cases maybe bad ("what uid should this be? root?!") but from a general memory safety perspective the value doesn't become potentially influenced by order of operations, leftover stack memory, etc. I'd agree, lifting everything into a static initializer does seem cleanest of all the choices. -Kees -- Kees Cook