From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2EB85B1FB for ; Wed, 28 Feb 2024 17:21:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709140896; cv=none; b=JUTOJ8YfWXLBqdJ04P6M2GZaOZkEEK4zZ7jYd7aYSQTa8TEPxn3gs4a1iNVV2xsp3wx1w6oTL2UltOqf3VN49g7h3Z2aBuAxooKwSsumJw8AkLOUcLQvKeqNA+uUlDMhdsJbNZ14DVPIhzp8L8AuHS3WhQMkoeVBfCm5EY/RIv0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709140896; c=relaxed/simple; bh=XM399Q8VLvXuDw5uzrGwivCMbFeJ4FieetH05IdWTBs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Cso2JgkpGqeKx4FqpllS0jbN4kNU9rJyF8tr8TSHqMZ7LK6Df8DPKF3/Pg/oaMRa92lKcf9bRt9Zbd0JbAHGT3o7PbkSHpC2ofFTISt/KLsaTtvOtKEc+jLp/qPkJH5wF9E/u2fx5cPLv9zLe56pUw5M7A73OFNbu0mOGHbMn+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Dv0OfJNd; arc=none smtp.client-ip=209.85.210.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Dv0OfJNd" Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6e47a104c2eso3688101b3a.2 for ; Wed, 28 Feb 2024 09:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709140894; x=1709745694; darn=vger.kernel.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=Dv0OfJNd0vjGvtw41wUvZJPEkqakxszi4xsSYKDq8yiapJgAOCmPm4J8os/LY5Z1ga 29m8v4MdT/04TpsqzLc2k/pFWm1SreFcjydJcdYat3/P2N/j5WnV3oW3YBnA0shtdbnU Acz84GK3WQceLojwLQUrIDSze1WWHLLhNRtPw= 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=WSfAYULO7rJq9LdmPQKDA8BCu4veAP2jZ0gQZEO3/btXbxG7m5Lk15fzJ84xFOdXfm c7fZlYt+vtZDpU6JXSv46Vtlm6zh9GpDIDAVN/61ZUXRfXgN38RmfP8QY/v43LusN4st diVqSY5pPQnmR90z+AqaiUVmCV965j5kScuClsGuoX5LBRjrDVIY+rFQvu9iegzfvznX SsvjPykYEzzkwC5DdTvM0y27u34oVlWTNEWFCaTI6uLtuxb4fLUKch3oz6Lc0PfICQBL NmMYJX/DSjGrBTzsCECeCIk91QRw6Dgmteo6YNaWb55vTEksFEtEjR0VWmUI0ltMVTB0 kB/w== X-Forwarded-Encrypted: i=1; AJvYcCXR1kdplOCIomtVLsRkR/Bb5J5OM8xlu8Ls2zTKaUha03HfetJOGjeDqILDqcPhaTrWeLJCoYdPG1TuCrJNAM/MSsTRFImCcmd1jnQ= X-Gm-Message-State: AOJu0YxYz1I3za6wEZwhFgZ+wc6wYQnbBnJgX4ynVxB/zHu1lU98AKna 5VYSHkTkkONZMdh5vLd1DVoFLfGYZhY0cs4mqROZsk3nkM3GXorBDXe/PlJpYg== 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> Precedence: bulk X-Mailing-List: linux-alpha@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8FFA7C5478C for ; Wed, 28 Feb 2024 17:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VYBIfG77DauNhipDQ1C4C8iAKWkO5XobCzUJhHZDYvg=; b=fIMMfJPMsAlhSe k2RjAwJP37Ny/8IlKClg++hpxUSjM+AgRK1oHlMtvQY4e6lhwtxevUR1Adg/fzKRmaceTknAOsITt KrpyMxYSjpRTH95a1CRKtp4sp5uTk5lY8tyCf9ILTkpip9e7CBBBYQfrjipio6mqaAg25/xlIjvie PR2v01d0ZpjnhGoKKQDbdILkMH16qyCd6WXST9bfZYDcgd3dQDWYTdqevnTwejIFBYeLmLiIYhfzw m6UbNhAgXoGzcPLByLBx7SsLXA20WYKG+srP+GUtDGeIfUHjmqyrYHOYxSMFAjbgnpu15/qHjsEgN pu7/kPAgrHLZDCMeQzPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfNch-0000000AH0s-0WjJ; Wed, 28 Feb 2024 17:21:39 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfNcd-0000000AGz8-0VD9 for linux-snps-arc@lists.infradead.org; Wed, 28 Feb 2024 17:21:37 +0000 Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6e4d869b019so3046440b3a.0 for ; Wed, 28 Feb 2024 09:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709140894; x=1709745694; darn=lists.infradead.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=hWMGqlcCYE/ZGUp0wcXCEDa5JARu5tVXMb7IJKp6xhWUlS6HTnOa6OZmRoyWXog6no GJ5KhwHIpQP7JMz+BrzmGJMD70ZoG51OTtxn6GobKfe4QGePFY24O74CwLkyp8gz2Lli zPTDz+1JIDGQgqdJj+bRt6dm3COLywmAU/NKA= 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=VIIulZz8SjtiKYcbMqFuEWbVQJSsmu1h1r0Kp3IL+LoFgVWvdCP3PCugETF6Jbo8J/ rpgITykl7/O4nsFuHsDUsYMsRxKA2zSdHVeV/9IpzsYre0ZUgL6eCg2slOMAsAsg1RfT U6Mt0XS7iHXi5TAYhhib6Sk6Dc6MLNK4Jm4mRUfJqw6ajzEfo7LQtqO6N47NAmDeo49n jwOWFGYlNe6XOeZqWoJ3dD/3vGW1asY7HOqB4nDU2Y73D9IRP/VtN85Ioeu19UV42IaV bG1ZObTdHJXJlRCx0TikukdgptlYaPVWTDyfxKRbPvbvnFTz0LOi9GRjVglbU+eolb+d MSNQ== X-Forwarded-Encrypted: i=1; AJvYcCVm1zMEKRJD8qkjZey9HG/L/w2gu/jd9eZ873PQHm6ZffNooL59ZAsmHJ3MPF2C9lA7kI+H5y2Zb6AzN3JAxxAD8/IVsR5EKRwX4ikOW2YcMT5y X-Gm-Message-State: AOJu0YwjbszFujKcJABT9bd+euTkE6iHqNLRaDgBps5xvNXVJJj8B0if tOH/y8b6G8mSFsCe6vemcONYYVTJvT8Y//fbSH0xyFk97VvsBtKknSernYu90g== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240228_092135_239665_E747AEF0 X-CRM114-Status: GOOD ( 17.14 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 154D2C47DD9 for ; Wed, 28 Feb 2024 17:22:22 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=i5qlsW2f; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TlLl14086z3vYX for ; Thu, 29 Feb 2024 04:22:21 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=i5qlsW2f; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=chromium.org (client-ip=2607:f8b0:4864:20::42d; helo=mail-pf1-x42d.google.com; envelope-from=keescook@chromium.org; receiver=lists.ozlabs.org) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4TlLkC0KpVz3cST for ; Thu, 29 Feb 2024 04:21:36 +1100 (AEDT) Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-6e4e7e25945so3363936b3a.1 for ; Wed, 28 Feb 2024 09:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709140894; x=1709745694; darn=lists.ozlabs.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=i5qlsW2fhNcYDA933y9tYjHxlOMxabYaIoHErcKKx5BkJSczAg9lVz924HbKu2Pr2G /Ww6+m/nFG6CX9yRgbq4bAAsv2Z7zuJUA/bl3E2fum8Zle5U+YR+nUPwzBQx7ATEsFbu SPMuzivDgwQ3p02zvEG7CKLckV1tq0QNeKsoE= 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=oxDau9fmige04qyMXP/ngoNwtS0EcZjpGFDVc+0JkGWah7LBb6mUTTIBEm2KfsR+h8 Xq0XDWgrdztFn9ml02hHhrYUPUuKadpEha6yq+mJjM0tLX+GArB7hZ2ImzJm26+bdudh 6no2NFsDTSLqJnj8RfTKfmFVfbXUbi1YpRdxCuCnoMHFf3byaPwRHJBNgCWwwedZEeVo JWQfkwxzC8f8RGALBEhdwnjEG20EK8dpg4nmYLd6CMAMCOz/O4FVipM6VVDioOLiL4Ux Nm1X0FWDE6mQFzqNdrVM619UM8pjHi30hfXFYf6j2n1bcGUJw2BnxGkIvnlI2QAvhG6h wdnw== X-Forwarded-Encrypted: i=1; AJvYcCXlEpLygOg9h1nTaME3X79K/Exsya/JTnJbUR8G8gAP1vUp9zmKuYSeAe5bqlIPCLC/6pKSmi3gtFwXxt0yPCYyzvFvCgdQwH2h0xYWRg== X-Gm-Message-State: AOJu0Yxf3ZGNoOJ+G/Pjmd768NklPwWLONPy6eDfcc0MJ43GshBuYVtC bqolc6GYOvJ0CBvtvNEftUtaUD+oEgj+T8Xb8kYquhhjNZEfmlIM6fAQ3Sdvxg== 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 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-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "luto@kernel.org" , "linux-sh@vger.kernel.org" , "peterz@infradead.org" , "dave.hansen@linux.intel.com" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "hpa@zytor.com" , "sparclinux@vger.kernel.org" , "linux-s390@vger.kernel.org" , "x86@kernel.org" , "linux-csky@vger.kernel.org" , "mingo@redhat.com" , "linux-snps-arc@lists.infradead.org" , "Liam.Howlett@oracle.com" , "broonie@kernel.org" , "bp@alien8.de" , "loongarch@lists.linux.dev" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" , "debug@rivosinc.com" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "Edgecombe, Rick P" , "linuxppc-dev@lists.ozlabs.org" , "kirill.shutemov@linux.intel.com" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58D10C47DD9 for ; Wed, 28 Feb 2024 17:21:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=y/yIaGaodPUAVJZmz1Kz0Tc6qH8w0jqvjaIiqX155cM=; b=ZGb2jw+oY/NMsF PKgtI+m4xqcH0Pl6TmdI9xgNPaJqOsdm409BQWRdfzqhjFNy8AEsIC1quyvbnpudGKZkmttjxnRTM EZ0RZ18nXI55nUbsX/ekf97YXHuIS8NfJso2Us/FDB1Y5MWW8VAMwP1V+blu6TVk3pXqojbGCjGcx CngN8xKMZDWcO28GwdMT4kM6l5l3aXRciheokAD1WxAF4zlheT8LpS5MhNZ3vHNhLPjid3R/A7AQ+ sZO8QhYTE5x35aBCnGs83LzMwIdfbBAA3wUx7kJn+tiR4GB9DyiRvi33PI2aYUa38VBZgqNTQ0DJ5 wpvPLBe/InFuKFSiE+6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfNcf-0000000AH0C-21Je; Wed, 28 Feb 2024 17:21:37 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfNcd-0000000AGz9-0Ul2 for linux-arm-kernel@lists.infradead.org; Wed, 28 Feb 2024 17:21:36 +0000 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6e47a104c2eso3688106b3a.2 for ; Wed, 28 Feb 2024 09:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709140894; x=1709745694; darn=lists.infradead.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=hWMGqlcCYE/ZGUp0wcXCEDa5JARu5tVXMb7IJKp6xhWUlS6HTnOa6OZmRoyWXog6no GJ5KhwHIpQP7JMz+BrzmGJMD70ZoG51OTtxn6GobKfe4QGePFY24O74CwLkyp8gz2Lli zPTDz+1JIDGQgqdJj+bRt6dm3COLywmAU/NKA= 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=DPXOFqmnyyimgs8I/2teZhFbRMmEk2tsda+GS7YBF6Bxadk3CVGwWVjXojxAYc17NL 0l8X/xKOOFBw4JpaPyqVhueS6UuUiz/wrYxYN71Ygvttxvjpnm55NI9id9zW2e8sUsq4 /A97DcduOQEYuVCPh52ZidgkT95HspKpSk6n7r2aVp/gDvOB+dGXln9cMZwI103AOwBf uu9ixoSgxgB9f2i/wL2MLCnAiueNAakUd7O1TVYqC3ImNGK7nYd2Rrv7psqGWMfFJTNh 0t9jn8VinuLPu+YCLn+Vb/zO7Ly16I6oB+0WdJ4WcraIjv6b3RwgBdWBez0n653vgv+5 sH2g== X-Forwarded-Encrypted: i=1; AJvYcCUDRXLmrGAx/RiTHXe62lI2hqAknZkMrowJJuLYjpnKfoqXStIhyiMF3T51QmMGuoXoC7kAgfV9mvebnzQT6mHe6hSjpnB74wbLY8h3Ziu600jJT38= X-Gm-Message-State: AOJu0YxH/Fcnw5U7PtOnHslzjny0f7tgJ+mSIEorazFm9PAjvrzax+xM A5i3XT8HE8oclT3KRIaStQ6Y8XTEV92gpyuoGiH7HSy2LzkKLcKotNhK8Ujm9w== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240228_092135_240586_D293DD99 X-CRM114-Status: GOOD ( 18.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel