On Thu, Apr 6, 2023 at 9:09 AM Lorenz Bauer <lmb@xxxxxxxxxxxxx> wrote: > > On Wed, Apr 5, 2023 at 6:40 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > Can we check that both fields are zero when entering the syscall? > > > > Yep, it already happens and is done by generic > > bpf_check_uarg_tail_zero() check in __sys_bpf. > > I thought that check only happens if expected_size > actual_size? I'm > thinking of the actual_size == expected_size case, what prevents user > space from setting log_size_actual to a non-zero value? ah, in that sense... What's the reasoning for this enforcement? I'm just afraid that it will complicate applications that don't care and are not aware of this field and do retries with the same attribute. On first try, the kernel fills out log_true_size, application retries and doesn't clear log_true_size (because it was written a while ago, but compiled against latest kernel UAPI, so passes sizeof(union bpf_attr) that includes new field). And that suddenly starts failing with -EINVAL. Seems like an unfortunate side effect, no? What's the harm in not validating this field, if it's an output-only parameter?
