[Annatar]

A kernel should always be compiled with symbols / source code inside of it -- that the Linux kernel doesn't have full support for CTF says more about it than it does about CTF.

Yes, a SIGABRT will get you a core file and will kill a process, but if your process is hanging in an endless loop (like the author's was), one already has far bigger problems, and keeping such a process running will not amount to much.

[monocasa]

I can't think of a single OS that gives you kernel stack traces on SIGABRT.

Can you disambiguate CTF? I only know that as capture the flag, which doesn't really make sense here.

Edit: ok, I figured it out.

No theyre not going to give you that raw information because it's a kernel ASLR bypass. You can totally get all the same information with the dwarf symbols, but you're going to have to opt in on a kernel for it to mean anything.

Edit2: bitching about how people aren't using portable Unix techniques, and then citing features that are Solaris specific isn't a great look.

[jwilk]

Tell us what you figured out…

[monocasa]

Haha sorry. It's a Solaris version of DWARF or pdb style metadata for their kernel.

https://docs.oracle.com/cd/E19253-01/816-5041/syntax-20/inde...

For that to be useful, you'd need the addresses in question, which is why it'd be an ASLR bypass. The kernel needs to give higher level information by default so it can sanitize the output.

And the debugging symbols exist on Linux anyway, they're just DWARF (which ironically is the more standards compliant way as opposed to CTF).

[Annatar]

CTF is just a specially compressed format and specification of embedding the source code into the binary; it's a complement to DWARF format, not the format itself. The documentation you cite even says it's similar, meaning that it's not DWARF.

[markjdb]

The main purpose of CTF is to provide a succinct representation of the graph of C types used in a program. It's generated from DWARF; anything encoded in the CTF section can also be found in DWARF info. CTF has nothing to do with "embedding source code" and isn't useful for stack unwinding or symbol resolution.

[monocasa]

And that's what I said: "DWARF or pdb style metadata".

[Annatar]

It's not a Solaris specific feature; FreeBSD has it as well:

https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sekt...

Linux is the one lagging behind, as usual.

How is embedding source code an "ASLR bypass"?

[monocasa]

OK, it's a dtrace thing that got ported to FreeBSD with dtrace. That still doesn't make it "Unix" any more than Linux's proc access.

Embddeding debugging information in a way that allows to you to use it (ie. in a way that you'd care about the format as an end user) implies giving you kernel addresses, which implies an ASLR bypass. If it's an implementation detail, then DWARF works great.

[geofft]

And if "FreeBSD has it too" is our standard for portable UNIX features, then /proc counts thanks to linprocfs.

[Annatar]

/proc on Linux wasn't implemented like /proc is on other operating systems; it's the only /proc implemented that way. The interface, if it could even be called that, is completely proprietary to Linux; output is ad hoc with no consistency. As usual.

[Annatar]

Again, which bypass? If you attach to a process you will see machine code and it will be stored at memory addresses.