Re: [PATCH] gdb, configure: Add disable-formats option for configure

[Guinevere Larsen <guinevere@redhat.com>]

On 10/4/24 11:45 AM, Eli Zaretskii wrote:
>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: guinevere@redhat.com, gdb-patches@sourceware.org
>> Date: Fri, 04 Oct 2024 15:26:25 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> 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