Should strip discard the .ctf section ?

[Orlando Arias]

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
rather leave this discussion, as mutual understanding seems to be far
off. However, please do help me to understand the following. DWARF
sections are widely used as means of storing debug information.
Autoconfigure scripts generate them by default. The strip tool still
removes them. 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, what exactly would you
be breaking here by removing it*? Expectations from others? As I have
said before, I expect strip to remove things from a binary that are not
needed for it to create a working process. By changing the tool's
behavior, regardless of what the gcc's front-end receives as flags, you
are breaking expectations of how things work.

My point is: -g gets passed by default in autoconf scripts, resulting
sections are still removed by strip. You otherwise have to manually pass
-g to gcc and friends, strip still removes the sections. Why should .ctf
get different treatment regardless of how gcc got the flags to generate
that section? The argument that has been used against me so far is ``do
not pass -gt to gcc and you will be fine''. This ignores the future time
where I do not get to control passing -gt to gcc's front-end driver and
I am forced to run strip a different way. At that point I am told ``we
can alter the way strip works if there is enough noise about it'' but
then that breaks things for people who expected strip to leave .ctf in
place, and also takes us back to the problem of ``now I have to run
strip a different way because there's this thing here to remove''**. All
because we altered historical behavior in strip the first time around.

Anyway, my sincerest apologies for sounding confrontational. That is not
my intention, and has never been. I do have my philosophical objections
after all, which are rooted in the historical behavior of a tool. In the
end, I do not mind going either way, since I am relatively flexible with
my workflow. But please, do keep in mind others may not be that way.

Cheers,
Orlando.


* 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. 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.

** Also, I thought RPM distros like Fedora and derivatives had separate
debuginfo packages. I am not familiar with how those are created, but
would not that necessitate running some variation of  ``objcopy
--only-keep-debug'' to generate? Yes, .ctf carries more than debug
symbols/data, but my understanding is that there is no information
needed by the runtime sitting there.

[1] Tice et al., Enforcing Forward-Edge Control-Flow Integrity in GCC &
LLVM. In 23rd USENIX Security Symposium, 2014.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20191008/92c47f34/attachment.sig>