On 17.10.2020 15:32, Christos Zoulas wrote:
> In article <Pine.NEB.4.64.2010161434570.25027%speedy.whooppee.com@localhost>,
> Paul Goyette <paul%whooppee.com@localhost> wrote:
>> For a custom kernel build with ``no options PTRACE'' and ``no options
>> COREDUMP'' defined, and sources updated on 2020-10-16 at 13:18:24 UTC,
>> I get the following linker error:
>>
>> # link SPEEDY/netbsd
>> /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map
>> netbsd.map --cref -T netbsd.ldscript -Ttext 0xffffffff80200000 -e start
>> -z max-page-size=0x200000 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
>> ${EXTRA_OBJ} vers.o swapnetbsd.o
>> /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
>> process_machdep.o: in function `ptrace_machdep_dorequest':
>> /build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:329:
>> undefined reference to `ptrace_update_lwp'
>> /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
>> /build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:372:
>> undefined reference to `ptrace_update_lwp'
>> *** [netbsd] Error code 1
>>
>> nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
>> 1 error
>>
>> nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
>>
>> ERROR: Failed to make all in
>> "/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY"
>> *** BUILD ABORTED ***
>
> process_machdep.c provides 2 functions:
>
> The read+write regs functions: used by ptrace and coredump
> The machdep ptrace function: handling used only by ptrace
>
> These dependencies are not reflected correctly in the patch below.
> Perhaps we want a regs module by splitting and then coredump
> and ptrace depends on that.
>
> This patch puts process_machdep.c in the ptrace module, and
> moves all the coredump functions in the coredump module. I have
> only compile-tested this.
>
> christos
>
We can step back and reevaluate the usefulness of ptrace modularization.
It's not complete as we call ptrace-related routines across the core of
the operation systems in the signal, process and threading code. In my
opinion this part of the kernel should be monolithic and ptrace is not a
pluggable "add-on".
Putting just a selection of routines to a kernel module is stretching
and ends up with a non-pretty code like:
#if defined(__HAVE_COMPAT_NETBSD32) && !defined(COMPAT_NETBSD32) \
&& !defined(_RUMPKERNEL)
#define COMPAT_NETBSD32
#endif
We create distinct kernel modules for this: ptrace and ptrace_common.
This is a hack for having operational compat code.
What are the purposes of "no PTRACE"?
1. Security. If this is the case, we should add a sysctl switch to
enable/disable ptrace.
2. Kernel size. Do we really gain that much to be worth the complexity?
If we want to go this route we should ifdef core kernel code precisely
instead of a subset of ptrace-related functions.
3. Kernel speed. Is this really measurable that in e.g. signal code we
end up with performance. Nobody so far ever (unless I missed it)
reported any performance overhead here and I'm not interested in
benchmarking it myself.
4. Easier debugging of the ptrace code through the loadable modules. I
have never ended up having this potential feature proven to be right.
This, I propose to do the following:
1. Remove the modularization of ptrace. This does not affect the compat
layers that still can and should be in my opinion modular.
2. Either abandon 'no PTRACE' or make it complete ifdefing all the
ptrace-related code from the kernel core.
3. If we have security related concerns, add
"security.models.extensions.ptrace".
Attachment:
signature.asc
Description: OpenPGP digital signature