Should strip discard the .ctf section ?

[Orlando Arias]

Greetings,

On 10/8/19 2:38 PM, Nick Alcock wrote:
>>               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 see. In that case, yes, the .ctf section should definitely stay lest
we break the program which expects this behavior.

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

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

Cheers,
Orlando.

-------------- 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/fd5f3fc4/attachment.sig>