4 ms·

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

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 8y ago
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 8y ago
  Tell us what you figured out…
  - monocasa 8y ago
    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/index.html 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 8y ago
      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.
      - monocasa 8y ago
        And that's what I said: "DWARF or pdb style metadata".
      - markjdb 8y ago
        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.
- Annatar 8y ago
  It's not a Solaris specific feature; FreeBSD has it as well: https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html 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 8y ago
    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 8y ago
      And if "FreeBSD has it too" is our standard for portable UNIX features, then /proc counts thanks to linprocfs.
      - Annatar 8y ago
        /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 8y ago
      Again, which bypass? If you attach to a process you will see machine code and it will be stored at memory addresses.

monocasa 8y ago

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 8y ago
Tell us what you figured out…
- monocasa 8y ago
  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/index.html 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 8y ago
    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.
    - monocasa 8y ago
      And that's what I said: "DWARF or pdb style metadata".
    - markjdb 8y ago
      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.
Annatar 8y ago
It's not a Solaris specific feature; FreeBSD has it as well: https://www.freebsd.org/cgi/man.cgi?query=ctf&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html 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 8y ago
  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 8y ago
    And if "FreeBSD has it too" is our standard for portable UNIX features, then /proc counts thanks to linprocfs.
    - Annatar 8y ago
      /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 8y ago
    Again, which bypass? If you attach to a process you will see machine code and it will be stored at memory addresses.