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 51498C433EF for ; Sun, 13 Feb 2022 03:35:10 +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:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/+nPB53AQG7jBn0HAHqyGYEOrwJ80KjqOXlsvp5yKlM=; b=SjK31UeXIfyTXO /0NqnDiG+e8EQLrwEfQ7sVI/8MpDcxM2XZC5Hao6TEgg8iQXppvDeg3QWw3p7DbblQwNNeit+II7v W5qLkuF0yGtciqC0pzAZz+60x25NzKOHwtlMYYeIQEXH3N/9ls8g5RpygMn2/+lProJMD+PQgvEu3 Kb8IMt14GkYDrVl9u8BoEMhgEMTBvy27xrkj9opTRhKUuFrpYKhKCJL3EvZzdbJjvqBFC8xzCgK+z hK4h+50Ylw+py7LDGH2BNxY98c46shqlwGelJZc1D1wMvB6TGZwSpvTf5rYbNneEVZlMH+zg+AawF wJ2xxBwycRqQolMXVZpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJ5e5-00Asc0-HT; Sun, 13 Feb 2022 03:33:53 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJ5e2-00Asbd-6M for linux-arm-kernel@lists.infradead.org; Sun, 13 Feb 2022 03:33:51 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-59-m5e4icDAO8m0cbi-5HV2aQ-1; Sun, 13 Feb 2022 03:33:46 +0000 X-MC-Unique: m5e4icDAO8m0cbi-5HV2aQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Sun, 13 Feb 2022 03:33:44 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.028; Sun, 13 Feb 2022 03:33:44 +0000 From: David Laight To: 'Kees Cook' , Robin Murphy CC: Ard Biesheuvel , Victor Erminpour , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , "ACPI Devel Maling List" , Linux ARM , Linux Kernel Mailing List , "trivial@kernel.org" Subject: RE: [PATCH v2] ACPI/IORT: Fix GCC 12 warning Thread-Topic: [PATCH v2] ACPI/IORT: Fix GCC 12 warning Thread-Index: AQHYH6jGUiwsSGsVWkybqVzsUhE0OqyQ00mw Date: Sun, 13 Feb 2022 03:33:44 +0000 Message-ID: References: <1644518851-16847-1-git-send-email-victor.erminpour@oracle.com> <202202101415.43750CEE@keescook> <3740c93e-9fde-f89f-9752-26ffff3ea274@arm.com> <202202111623.A7881CC@keescook> In-Reply-To: <202202111623.A7881CC@keescook> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220212_193350_534572_69A1C944 X-CRM114-Status: GOOD ( 13.20 ) 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 From: Kees Cook > Sent: 12 February 2022 00:38 .... > > Sure. I think I am trying to take a pragmatic approach here, which is > that gaining auto-var-init is a big deal (killing entire classes of > vulnerabilities), but it comes with an annoying compiler bug (that we do > get a warning about) for an uncommon code pattern that is easy to fix. My worry about the compiler setting variables to zero is that people will get lazy and assume it happens. Then some code will get compiled without that enabled (possibly because it slows things down too much) and then really horrid bugs start to appear. If the intent is to detect code that is failing to initialise locals then setting to a non-zero value (that is likely to cause grief) is much better than setting to zero. I'm particularly worried if the compiler starts to zero on-stack arrays. There is plenty of userspace code that will use char buff[MAX_PATH] to build a filename or char errmsg[1024] for an error message. At the moment the size only needs to be 'big enough' but if the compiler zeros it then there are performance issues and oversize buffers make a difference. At which point you start making the arrays 'just big enough' and then fall foul of truncations and overruns because the calculation was wrong. Definitely double edged. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel