CppCon 2018: Simon Brand “How C++ Debuggers Work”

[@onceuponapriori]

What a great talk and quite a good sport answering so many questions in the middle of his talk!

[@CppCon]

Glad you enjoyed it!

[@tetraphobie]

Nice talk! One thing to note is that in the explanation of how functions are called by the debugger (38:25), Simon said "JIT compile to machine code". To clarify, from my experience (and looking at the source code for GDB), what GDB does when you call a precompiled function is a bunch of trickery with the debuggee's state, like adding a dummy call stack frame and calling the memory allocation function on behalf of the debuggee. But ultimately, it will transfer execution to the original pre-compiled function and let it do the job. Simon mentions that LLDB does JIT compile the expressions being evaluated so I presume it would do that for the function call "shim" as well, but I don't think it would re-compile the function being called, either. (Unless it's a template function or some other special case, and you're using a modern LLDB version with experimental features enabled.) Just wanted to clarify that detail.

[@barrettellisadair]

Phenomenal talk in every regard. Thanks!

[@LesleyLai]

One of the best talks in CppCon this year I attended.

[@deutschWallah]

Really good Simon Brand.

[@mrlithium69]

I was trying to remember where I saw this guy last, it was this: "CppCon 2018: Brand & Nash “What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”" also a useful talk.

[@muhammadhabibjawady552]

Also : How to write well-behaved value wrappers (2018) hhh

[@henke37]

"So this is how stack unwinding would work if you have easy access to frame pointers." (casual ohcrap) "Sometimes you don't."

[@AbhinavGupta-i6m]

Amazing video! Thank you so much!

[@mrlithium69]

@30:50 He explains that the ptrace only reads 1 word at a time. Then he gives the alternative of "process_vm_readv" which I decided to look up and found this useful kernel doc: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf634098c00dd9cd247447368495f0b79be12d1 It seems to be known as CROSS_MEMORY_ATTACH which seems to ne enabled by default? and has security implications, ie: other processes are allowed to access other processes virtual memory space; although I am not qualified enough to assess these implications. I think this process_vm_readv needs more explanation on if/how this mechanism might be abused.

[@mrlithium69]

This document from Microsoft about how Windows does the security descriptors makes a lot more sense to me, docs.microsoft.com/en-us/windows/desktop/procthread/process-security-and-access-rights . Where you have to manually assign the PROCESS_VM_READ access right with SetSecurityInfo() and it requires the SeDebugPrivelege in your user token to do so, before you are allowed to do anything with another process's memory. So I still don't know how Linux compares to this. If anyone wants to explain...

[@mrlithium69]

Interestingly, Alex Ionescu wrote about a similar but opposite vulnerability, where he is concerned about malware turning themselves into Windows Protected Processes (where PROCESS_VM_READ, among other things, is disabled), so Anti-Virus/Anti-Malware won't be able to scan the address space to detect threats. www.alex-ionescu.com/?p=34

[@robinbuster1323]

56:55 The annotation should read ptrace calls not petrie skulls

[@danielro1209]

Very enlightening👍

[@CppCon]

Glad you think so!

[@informant09]

Great talk!

[@AleksandrSerov-rn2cn]

Can't find slides on github by link in description

[@CppCon]

Sorry, these slides are unfortunately unavailable.

[@lpadgett23]

They might be at the QR code that pops onto the screen around minute 52?

[@fahimp3]

11:08 I got so scared! Lmfao

[@Nuclearblastdrone]

Stylówe ma nie do podrobienia