From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qWcZGg1yOWSNtCsAWB0awg (envelope-from ) for ; Fri, 14 Apr 2023 11:32:29 -0400 Received: by simark.ca (Postfix, from userid 112) id 562F71E221; Fri, 14 Apr 2023 11:32:29 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=nzXkWcsU; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 simark.ca (Postfix) with ESMTPS id 078361E0D3 for ; Fri, 14 Apr 2023 11:32:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 504D83858002 for ; Fri, 14 Apr 2023 15:32:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 504D83858002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681486347; bh=hfGQg72MtBkAmR6mSfyshzEX9LLpSlLLcHaUm73mVgM=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=nzXkWcsU8akLJfW4uvHzgaqhn9XsycWcTzLZPbWtF6aBuAqp4OCNClMMduno/rJuc DsV0hVXKwC5qfyAm2ae9DoAr6rZw3u0p49OkgLIbamr8O88nLkmkwdF6HrJ1tiXj9O mLNMAPEzj9vebKwxbG3fz8WXYBcPyvgH9olnh9UQ= Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 80F543858D32 for ; Fri, 14 Apr 2023 15:32:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80F543858D32 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CB4E42F4; Fri, 14 Apr 2023 08:32:44 -0700 (PDT) Received: from [10.2.78.76] (unknown [10.2.78.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D16E23F6C4; Fri, 14 Apr 2023 08:31:59 -0700 (PDT) Message-ID: <539b2e82-b084-784b-673b-b175638454f8@foss.arm.com> Date: Fri, 14 Apr 2023 16:31:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: Threat model for GNU Binutils Content-Language: en-GB To: =?UTF-8?B?UGV0ciBUZXNhxZnDrWs=?= , gdb@sourceware.org References: <032c1307-c143-3f2c-0502-683d966f0257@foss.arm.com> <78f3e6a6-dec2-3aa2-d1b6-935d842add1e@gotplt.org> <5947697c-274f-58a7-af02-00618691021d@foss.arm.com> <20230414172538.1ddee8d5@meshulam.tesarici.cz> In-Reply-To: <20230414172538.1ddee8d5@meshulam.tesarici.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Richard Earnshaw via Gdb Reply-To: Richard Earnshaw Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 14/04/2023 16:25, Petr Tesařík wrote: > On Fri, 14 Apr 2023 15:41:38 +0100 > Richard Earnshaw via Gdb wrote: > >> On 14/04/2023 15:08, Siddhesh Poyarekar wrote: >>> On 2023-04-14 09:12, Richard Earnshaw wrote: >> [...] >>>> 2) Code directly generated by the tools contains a vulnerability >>>> >>>>   Nature: >>>>   The vast majority of code output from the tools comes from the input >>>>   files supplied, but a small amount of 'glue' code might be needed in >>>>   some cases, for example to enable jumping to another function in >>>>   another part of the address space.  Linkers are also sometimes asked >>>>   to inject mitigations for known CPU errata when this cannot be done >>>>   during the compilation phase. >>> >>> Since you've split this one out from machine instructions, there's a >>> third category too; where binutils tools generate incorrect code for >>> alignment of sections, sizes of sections, etc.  There's also a (rare) >>> possibility of an infrequently used instruction having incorrect opcode >>> mapping, resulting in a bug being masked when dumped with objdump or >>> resulting code having undefined behaviour. >>> > > I must be dumb, but isn't the biggest risk is that GNU Binutils produce > an exploitable bug in the target binary? > > Let me give a silly hypothetical example. If the linker places Global > Offset Table incorrectly, so that it overlaps stack, then I would > definitely consider it a security bug in GNU Binutils, because all > input object files were OK, but the result is not. > > Just my two cents, > Petr T This probably comes under the 2) of generated output, but it could be more explicit. Layout bugs is also something Sid alluded to with his comments about alignment. I haven't really spent enough time thinking about this to be sure I've captured all reasonable possibilities. And by their very nature, threat models tend to be live as the threats morph over time. R.