Re: Should strip discard the .ctf section ?

[Nick Alcock <nick dot alcock at oracle dot com>]

On 8 Oct 2019, Orlando Arias stated:

> Greetings,
>
> On 10/8/19 12:35 PM, Nick Alcock wrote:
>>> So, assuming that CTF becomes widely used, the moment that -gt becomes a
>>> default in Autoconf scripts, we now have to change the way strip works
>>> to remove the section since it is automatically added whenever building?
>> 
>> If it's become widely used, it seems to me that surely you wouldn't want
>> to do that, because it would break things. That's what "wide use" *means*.
>
> At this point we are starting to talk past each other I believe, so I

I agree. One brief point, though.

>               Why should .ctf be treated different in a world where .ctf
> is common use? Why would removing .ctf at this point break things? My
> understanding is that the .ctf section in an object file does not
> contain information that a process needs to run,

The process may be using libctf to examine its own executable's .ctf
section, and the .ctf section of, say, shared libraries it intends to
dlopen(), or has already dlopen()ed or had loaded by ld.so. It might
well need the .ctf section to run, or some *other* program needs it to
have the .ctf section there, or why was it built with it?

This is not purely debugging information, though debuggers may find it
useful.

> * I will admit here that the type introspection portion does sound
> interesting from a security perspective. I have seen many software bugs
> that lead to security issues thanks to type confusion at runtime. A
> process being able to utilize more accurate type information whilst
> being run may actually be more secure in this regard, but this would
> need testing.

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 am thinking of a system reminiscent of libvtv that was
> added to GCC a while back [1]. However, this would require .ctf to be
> loadable, so that the process could use the data, as well as having some
> extra code to utilize it.

The process can use the data even if .ctf is not loadable: libctf loads
the .ctf section using BFD. This works. (Perhaps, in a loadable world, a
new API that takes an soname and traverses the phdrs and finds it and
loads the in-memory CTF corresponding to that soname might be useful
too, and one that just takes a phdr and loads the corresponding CTF, but
the existing load-using-BFD interface is never going to go away. Not all
possible use of CTF is of CTF that corresponds to something that's
already been loaded into the address space.)