[DTrace-devel] [PATCH 2/2] Fix copy from user space when accessing high-number pid entry args

Eugene Loh eugene.loh at oracle.com
Tue Apr 19 19:32:58 UTC 2022


Thanks for the explanations, but I'm not sure where to go from here.

The code refers to BPF helper functions via enums like 
BPF_FUNC_probe_read_user.  So one option is to hardwire the enum in 
without depending on a header file.  Would that be better?  Add some 
"#define BPF_FUNC_foo bar" to dt_cg.c.  That means one could use the 
function if available in the kernel even if the header file is behind.

One still needs the runtime check to see what's in the running kernel.  
I guess one can start with some "definitely low-enough" max_id and keep 
bumping it up until an "invalid func " message is found (rather than 
starting with the /usr/include value, which might not be big enough, and 
working down).  Or just checking the kernel only for this one specific 
helper function, ignoring whatever MAX_ID might be.

On 4/19/22 1:51 PM, Nick Alcock wrote:
> On 15 Apr 2022, eugene loh told this:
>
>> +/*
>> + * Set dt_bpf_func_max_id.  While it should be __BPF_FUNC_MAX_ID from
>> + * /usr/include/linux/bpf.h,
> That assumption is just not justified at all. /usr/include/linux is the
> kernel headers against which *glibc* was built: it need have no
> relationship with the running kernel at all. It's often older, if RH is
> using an older kernel than we are; it is also often newer, because when
> building glibc you are (or were, historically: see below) supposed to
> use the newest headers possible so that glibc can enable every kernel
> feature it supports (iff the running kernel is new enough).
>
> In glibc 2.33 (IIRC) this whole dance is dropped in favour of just
> copying in definitions out of the /usr/include/linux header files, and
> distros can finally start treating the kernel headers in a somewhat more
> reasonable fashion (and upgrading them more often).
>
> Projects that use kernel headers (like we do) are expected to copy them
> into their source tree. Shame we can't do that because we're the wrong
> license :/



More information about the DTrace-devel mailing list