Should strip discard the .ctf section ?

[Nick Alcock]

On 8 Oct 2019, Orlando Arias outgrape:

> On 10/8/19 2:38 PM, Nick Alcock wrote:
>> Yes indeed, though I'm not sure how libctf could really help with
>> security auditing without extra metadata (I'd be fascinated to know,
>> though). It certainly might help programs *themselves* determine that
>> e.g. "this thing over here looks like it should be right for us but oh
>> look it has the wrong type signature, it refers to struct foo which is
>> not assignment-compatible with our struct foo" or something: a runtime
>> libabigail :) (ctf_type_compat() would need a bit of souping up for this
>> to be practical, but I don't think it would need much.)
>
> I will have to think a bit about this, all the information that the .ctf
> section contains, and what extra could be needed for a runtime type
> verifier to properly design a system. I rather not change the structure
> of the section [as to avoid introducing incompatibilities]

The internal structure of CTF is expected to change in any case (it
can't even handle the wilder edges of GNU C extensions yet, and I know I
can make it more compact as well): it is libctf's responsibility to keep
reading the older formats. I plan for it to eventually grow the ability
to *downgrade* newer formats into older ones, as well, where possible.
The idea is that other consumers only need to read and write one format
and can ask libctf to convert the current format into the one they
understand: they won't need to chase format changes.

(None of the API for this exists yet, though.)

>                                                            opting to
> work around limitations. I am not sure what type of overhead we would be
> looking at for doing this kind of verification, but if I had to guess I
> would think it would result something similar to what libvtv or
> AddressSanitizer add; though I am getting ahead of myself here, this is
> just hypothetical and I am not even sure if it is fully workable.

There are a number of things in planning -- a backtrace section in the
CTF is one. So adding more stuff is quite sensible!

I have a todo list which I'd very much like to get up somewhere
publically visible. Hm, does binutils have a wiki... doesn't look like
it.

> Anyway, thank you for your time and apologies for all the noise.

There were some very good points buried in the misunderstandings, and
it's clear I should document some of this stuff more carefully --
whether in the yet-to-be-written libctf documentation or in the CTF spec
I'm not sure. (It's not really part of the *file format*, but it does
apply to all potential consumers of the file format, not only libctf...
so maybe I need a section on 'Possible use cases' or something.)

-- 
NULL && (void)