From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0VMzL+0oBGftDQUAWB0awg (envelope-from ) for ; Mon, 07 Oct 2024 14:31:09 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JiDJUP1I; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5CF361E355; Mon, 7 Oct 2024 14:31:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EE1611E05C for ; Mon, 7 Oct 2024 14:31:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8367E3858C66 for ; Mon, 7 Oct 2024 18:31:07 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 0A13E3858D3C for ; Mon, 7 Oct 2024 18:30:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A13E3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0A13E3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728325846; cv=none; b=aPc7nANhyfUOG4ayld3OGIOwfPvGRj7ve3okmqaqKoK2VA6L7JHDgKJzhZsC8XTx6uQbAM86h1qi7s/MzBmXwZ7NnU8YF8RXjcAdoUDrDMNxfhhuYhzjfG8KUZYBf3kyvCkCOIpqqlqHXm08j3lYWXgGMG6vIQEM8SstGKnz0TU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728325846; c=relaxed/simple; bh=PnuUF0Jg30jTtY5989zJAZGsm4WU5fK/n9NZEc7wBeo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=K+YnvihZy6xmqtruBDw72eakBUBdp0cwrR+7cMKjHGPs6LtWnGnGp5tfCd6AbF8UBI7GzrsVN2QGwSfUatcadRm/KTTvNgsW6xFIE0UKsBqyMNulTFMdZg//rH7U5DVsU29dypwOAcWBBVWZ1wNefpsdI5fu3bJTZ4FbeJ/ool8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728325843; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sOES9rqVQJrAznom5kIxhx7D9BsxHnLi5dlpG3PZkmo=; b=JiDJUP1ImaU5k0fAI5SMRyBx8u91kHJuxBWK/tul0hVqLRPA1kcqnxg+OuZT4qfuO/EVTU HnZIu5S4L8Oz5DcCB6dOA55mTrfmBfd+FGBjHXENWNA7YpmT2PbkOZx7lXlZ/qztLpBd0J fSzSy0RvqEaPEUI/yRUEzsk+/88vmiA= Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-31-U2aleD9hPL26jpSrPPOZUQ-1; Mon, 07 Oct 2024 14:30:42 -0400 X-MC-Unique: U2aleD9hPL26jpSrPPOZUQ-1 Received: by mail-io1-f71.google.com with SMTP id ca18e2360f4ac-82ad9fca614so647746139f.3 for ; Mon, 07 Oct 2024 11:30:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728325841; x=1728930641; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sOES9rqVQJrAznom5kIxhx7D9BsxHnLi5dlpG3PZkmo=; b=qFARW8JiJUFLly1wlf/U83hPtHtSeAL/cs5Q6BycpAJ5nw5cvbRyiadd84eer87t3q Ve90Yd10pCH2Rz+kYlosz8xqdiQHvEXuj1bnjXYkSlWAw9XTB/yyQBvqvsPVLplGdMrC 36efpZvoXeuBlIEMEJkRTjqxiFt5TnePQ3Kwau1rtQrfpCRHlJ7vTJTlaCZIxYh5nB8H GrRu6P9GQv4gc6cl9ZVYUwHsBP6JjTANH05g4eagoioAB6AOeSU80gBmUEOk0s24vLc3 2s8zPOpzsRHtRqVObTpQUDPWdPRJ50OuH93ICfJrLqHzD8m3tMt2jWrea8TpPUtTxt1I DQvQ== X-Gm-Message-State: AOJu0YxIZNdv0oZxwPs4yJUq7VWL1yNRdZq1VSLghmFiHLDo/nvFff6N HucImMDXWYfxm9vGmH7F64TDMOwlSQfXqB0dW+HW0zn14Sk2AL3jiXdMB6sY3lWMMCiXwpsgIJm Cu1HmnP7fLw1BioPm2YAbP9RLeZlXhRmuCuLhkVfwDdoHDxJatsrxTFmCSauQ4DMSDfg= X-Received: by 2002:a05:6602:2dc6:b0:82c:f05f:6c7a with SMTP id ca18e2360f4ac-834f7a9548fmr1489527939f.0.1728325841532; Mon, 07 Oct 2024 11:30:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHbNS4ZJozs3BU7noTKLopaFNEQDg7iIoJvl31gtpk1HTB8LGvTjhxbka43qyKEiZwfXN5UhA== X-Received: by 2002:a05:6602:2dc6:b0:82c:f05f:6c7a with SMTP id ca18e2360f4ac-834f7a9548fmr1489525139f.0.1728325841127; Mon, 07 Oct 2024 11:30:41 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1000? ([2804:14d:8084:92c5::1000]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-83503b3063asm135165539f.49.2024.10.07.11.30.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Oct 2024 11:30:40 -0700 (PDT) Message-ID: Date: Mon, 7 Oct 2024 15:30:37 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure To: Eli Zaretskii , Andrew Burgess Cc: gdb-patches@sourceware.org References: <20240925175340.1850969-1-guinevere@redhat.com> <86msjvars2.fsf@gnu.org> <865xqi9sak.fsf@gnu.org> <8634llaay5.fsf@gnu.org> <87setey6vi.fsf@redhat.com> <86ed4y1tgg.fsf@gnu.org> <87bk00x7u6.fsf@redhat.com> <86ed4wx6yt.fsf@gnu.org> From: Guinevere Larsen In-Reply-To: <86ed4wx6yt.fsf@gnu.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 10/4/24 11:45 AM, Eli Zaretskii wrote: >> From: Andrew Burgess >> Cc: guinevere@redhat.com, gdb-patches@sourceware.org >> Date: Fri, 04 Oct 2024 15:26:25 +0100 >> >> Eli Zaretskii writes: >> >>> If I'm right, then there are two separate aspects to "target": on the >>> one side, the ability to start/stop executables, insert breakpoints >>> and watchpoints, etc., and OTOH the ability to read and process debug >>> info used by that target, implement frame unwinders, etc. Are we >>> currently conflating these into a single notion of "target", and if >>> so, will the proposed changes include or exclude both parts of each >>> "target"? >> I agree with you about "target" having two components, the lower level >> stuff, and the higher level stuff. >> >> File format support, being able to read from file, only (I think) >> impacts higher level functionality. But just reading the file isn't (I >> claim) enough, we need the higher level functionality in order to really >> "understand" the file contents. >> >> My claim then is that being able to remove the file format support will >> actually make the GDB slightly better (in some cases) as GDB will no >> longer be able to read a file which it is then unable to correctly >> process the contents of. > Thanks. > > So given this situation, what exactly will removing, say, mipsread.o > give me? What will the GDB I build be unable to do that it was able > to do before? The main thing is security. If there was a security bug found in the reader for mips files, and you're only interested in debugging x86_64 linux and windows. An attacker could maliciously craft a binary file that appears to be with that file format, and convince a user to load it, which could trigger the security bug. If you disable the mips format, there is no physical way to reach the vulnerable code. I expect this change to be most useful to software packagers who only wish to support a few configurations, or very security conscious end-users who compile their own software. This is because, even though the project will aim to fix these as fast as possible, releases could take a little longer, and so the users or packagers would need to manually backport the fixes. Just removing the vulnerable file from compilation altogether makes the backport unnecessary. There are also small benefits in compilation time and final binary size, but they are pretty minor. > > And a more practical question: if I want to build GDB that will run on > GNU/Linux and should be able to debug Linux executables natively and > MS-Windows executables via gdbserver, which formats should I specify > with this new --enable-formats option? Linux uses elf files, and windows uses PE-coff (compiled when coff is requested), so you would need --enable-formats=elf,coff However, with the patch as-is in the list, any value you put in there (including --enable-formats=no, which would add nothing user selected) would compile support for elf and coff anyway, so there is no need to worry. Finally, if you aren't sure, the default behavior if the flag is to compile all readers, keeping with the old behavior. > > See, I think these are the questions that the readers of the manual > will ask themselves, and we should have the answers there for them. > That's a reasonable point. I don't think we should need to document all targets, but I can see the value of documenting the main usage of the file format when describing the options, as a guideline for users running on mainstream platforms and not meant as an exhaustive list. I'm thinking of adding the following to the readme: `--enable-binary-file-format=FORMAT,FORMAT...' `--enable-binary-file-format=all'   Configure GDB to only be be able to read selected file formats.   The special value "all" causes all file formats to be compiled in, and is the   the default behavior of the option. The other possible options are:   * coff: Main format on windows systems. This is required to compile with     windows target support;   * dbx: (also known as a.out), is a legacy file format, this is recommended     if you know you will be dealing with this file format;   * elf: Main format of linux systems. This is heavily recommended when     compiling with linux support;   * macho: Main format on MacOS systems, this is heavily recommended     when compiling for those targets;   * mips: (also known as ecoff), this is the main file format for targets     running on MIPS CPUs. It is heavily recommended when supporting those     targets.   * xcoff: Main format of AIX systems, this is required to compile for AIX     targets and rs6000 CPUs. What do you think? -- Cheers, Guinevere Larsen She/Her/Hers