Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using /proc to get a process' current stack trace

ops.tips

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Using /proc to get a process' current stack trace

#51

Post by monocasa »

oneanddone wrote: post #42
someguydave wrote: post #24

Earlier quoted context omitted.

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

BSD user here. Of course there is porting occurring, but this is the nature of open source, is it not? Oftentimes, the BSD devs will take whatever hardware specs they can get and code something from that. OpenBSD frequently writes drivers that are orders of magnitude smaller than comparable Linux drivers, while getting the same functionality. NVIDIA drivers are but one example. Some hardware vendors are generous with…

> will not have any GPL'd code in the base OS, as it's not truly free.

"My freedom to lock down someone else's code is more important than my user's freedom to have access to the code."

Re: Using /proc to get a process' current stack trace

#52

Post by Annatar »

monocasa wrote: post #31
Annatar wrote: post #28

Earlier quoted context omitted.

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.

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…

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"?

Re: Using /proc to get a process' current stack trace

#53

Post by Annatar »

monocasa wrote: post #41
jwilk wrote: post #40

Earlier quoted context omitted.

Tell us what you figured out…

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 ironica…

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.

Re: Using /proc to get a process' current stack trace

#55

Post by Annatar »

someguydave wrote: post #47
dman wrote: post #45

Earlier quoted context omitted.

I dont understand how ports help / hinder usability of drivers. Could you please elaborate?

They don't. However, they do reduce the ability of the target O/S of the port to claim that it isn't a clone of Linux. The top-level post was complaining that people don't consider non-Linux O/S, and then failed to offer compelling alternatives.

I did not, I stated that nothing has changed: before people only knew PC buckets and Windows, now PC buckets and Linux is the only truth and religion. Nothing else exists. So the more things changed, the more they stayed the same. That's progress!

I also listed several alternatives just a few comments below, but apparently you didn't read that. You know of the old saying "you can bring a horse to the water, but you can't make him drink"?

Re: Using /proc to get a process' current stack trace

#56

Post by TheDong »

oneanddone wrote: post #42
someguydave wrote: post #24

Earlier quoted context omitted.

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

BSD user here. Of course there is porting occurring, but this is the nature of open source, is it not? Oftentimes, the BSD devs will take whatever hardware specs they can get and code something from that. OpenBSD frequently writes drivers that are orders of magnitude smaller than comparable Linux drivers, while getting the same functionality. NVIDIA drivers are but one example. Some hardware vendors are generous with…

> will not have any GPL'd code in the base OS, as it's not truly free

That's a disingenuous way to put it. The GPL is a free software license. It is "free" as in libre by all common definitions of "free" in regards to software.

The GPL is not compatible with the BSD dev's preferred license, which is much more likely the reason they avoid using such code.

By all conventional definitions, the BSD and GPL licenses are "truly free [software licenses]."

You're welcome to argue that the BSD license is better (because, for example, it lets sony create derivative playstation OSs without providing that source code to their users, ensuring their users have less freedom than if it were linux) or that the GPL is better (because it would prevent the previous), but they're both free licenses.

Re: Using /proc to get a process' current stack trace

#57

Post by drewg123 »

ktpsns wrote: post #54

Note, the GNU debugger (gdb) can attach to running processes. This should give you a stack trace with readable addresses, cf. https://stackoverflow.com/questions/2308653/can-i-use-gdb-to...

The /proc interface tells you what the process is doing in the kernel (eg, after a system call), which is orthogonal to getting a user-space stack trace. Both are helpful. The userspace trace is arguably more helpful. The nice thing about the kernel trace is that you're likely to have symbols (or be able to download them); that is unlikely to be true for userspace if you're running a commercial binary, for example.

Re: Using /proc to get a process' current stack trace

#58

Post by monocasa »

Annatar wrote: post #53
monocasa wrote: post #41

Earlier quoted context omitted.

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 ironica…

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.

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

Re: Using /proc to get a process' current stack trace

#59

Post by trasz »

someguydave wrote: post #24
justinsaccount wrote: post #9

Earlier quoted context omitted.

How's the support for bluetooth on openbsd these days?

Also, how many of the aforementioned bsds use drivers that were ported from the Linux kernel tree?

No idea about other BSDs, but in case of FreeBSD that’s generally just Intel and AMD graphics drivers. All the rest is native.

And this goes both ways - at one point Linux folks famously managed to violate the BSD license when porting some WiFi driver, iirc, which is notable, since it’s not that easy given the licenses nature :-)

Re: Using /proc to get a process' current stack trace

#60

Post by monocasa »

Annatar wrote: post #52
monocasa wrote: post #31

Earlier quoted context omitted.

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…

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"?

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.

Post reply on HN