From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com 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> From: Richard Earnshaw In-Reply-To: <20230414172538.1ddee8d5@meshulam.tesarici.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3490.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.