Bug 238837

Summary: init: Remove P_SYSTEM flag from PID 1 to allow easier debugging of init(8)
Product: Base System Reporter: WHR <msl0000023508>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Some People CC: brooks, cem, kevans
Priority: --- Keywords: needs-qa
Version: CURRENTFlags: koobs: mfc-stable12?
koobs: mfc-stable11?
Hardware: Any   
OS: Any   
Attachments:
Description Flags
allow-ptrace-attach-1.diff
none
allow-ptrace-attach-1.diff none

Description WHR 2019-06-27 03:00:28 UTC
Created attachment 205367 [details]
allow-ptrace-attach-1.diff

Currently ptrace(2) won't allow attaching to processes have P_SYSTEM flag set; by removing this flag, debuggers like gdb(1) and lldb(1) will be able to debug the current running init(8) process like other userspace processes.
Like all programs, init(8) may need to be ptrace(2)-attached, due to bugs or testing new changes; generally, allowing that would be very convenient when working with init(8)-related debuggings.

Although I currently didn't have a need to debug the FreeBSD init(8), this report was a generic idea open for discuss.
Comment 1 WHR 2019-06-27 03:07:12 UTC
Created attachment 205368 [details]
allow-ptrace-attach-1.diff

Update the diff with the latest head from SVN.
Comment 2 Conrad Meyer freebsd_committer freebsd_triage 2019-07-12 18:53:53 UTC
If P_SYSTEM is removed from pid 1, is there *any* other process using it?  Looks like anything created with kproc_create(), which kind of makes sense, but we could/should also prevent debugging P_KPROC processes anyway (and that flag is also set).

I'm not sure that debugging pid 1 without this flag set actually functions correctly; init is pretty special.  Have you tried using gdb on it with this patch?
Comment 3 WHR 2019-07-13 03:27:15 UTC
(In reply to Conrad Meyer from comment #2)

I knwon that ptrace(2) can't be used to debug any kernel processes, allowing that would hang or panic the kernel; but process 1 (init(8)) isn't a kernel, but an user process, right?

> Have you tried using gdb on it with this patch?
Yes, I has been used a 10.3-RELEASE-p29 kernel with this patch applied, for a long time; I can debug init(8) in gdb(1) any time, without any problem.