linux-kernel - Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87seu7bh85.fsf@email.froward.int.ebiederm.org>
Date: Tue, 10 Sep 2024 11:34:18 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Jubilee Young <workingjubilee@...il.com>
Cc: oleg@...hat.com,  akpm@...ux-foundation.org,  apais@...rosoft.com,
  benhill@...rosoft.com,  linux-kernel@...r.kernel.org,
  romank@...ux.microsoft.com,  ssengar@...rosoft.com,
  sunilmut@...rosoft.com,  torvalds@...ux-foundation.org,
  vdso@...bites.dev
Subject: Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc FS

Jubilee Young <workingjubilee@...il.com> writes:

>> if the process is ptraced, debugger can insert the breakoint into
>> please_insert_the_breakpoint_here(). Otherwise breakpoint_if_debugging()
>> is a cheap nop.
>
> Generally a programmer wants to put this kind of conditional breakpoint
> on an exception path, for which, unless one is working with a language that
> abuses exceptions for control flow (which unfortunately describes... many),
> the performance isn't of enormous concern. Not that it's free, either, but
> opening a file and scanning it is a lot more code than a single call
> to prctl.

I want to reiterate what Oleg pointed out elsewhere in this
conversation.

Observing a process is ptracing the current process does not mean a
debugger is attached to the current process.  It could be strace, or
upstart or some other code that happens to use the ptrace facility.

Which in turn means that opening /proc/self/status and looking for
TracerPid does not reliably detect if a debugger is attached.

Which unfortunately means that this must be solved as a coopeartive
effort between the library implementation and the debuggers.  Nothing
else can reliably tell you that a debugger is attached to your process.

Which in turn means this can not be solved in the kernel.  It must
be done as a cooperative effort between the implementation of the
library and the debuggers.

>> Perhaps it makes sense to discuss the alternatives? Say, a process can have a
>> please_insert_the_breakpoint_here() function implemented in asm which just does
>> asm(ret).
>
> There's some merit in having the debuggers recognize this pattern, as that
> then would save every language that wants to have this power available
> the trouble of reimplementing it. But first debuggers must recognize it,
> which would require teaching each of them, which can be... tedious.

Unfortunately that is the only solution that I can see that will work
reliably.

> Having a function named `fatal` or whatever likewise has this issue.
> A toolchain, however, can simply insert a jump to a breakpoint easily,
> without having to hold gdb, lldb, cdb, and whatever-other-db's hand.

Eric