On Thu, Jan 30, 2025 at 7:57 AM Kees Cook <kees@xxxxxxxxxx> wrote: > > On Thu, Jan 30, 2025 at 07:05:42AM -0800, Eyal Birger wrote: > > So if we go with the suggestion above, we'll support the theoretical > > __NR_uretprobe_32 for filtered seccomp, but not for strict seccomp, and > > that's ok because strict seccomp is less common? > > It's so uncommon I regularly consider removing it entirely. :) > > > Personally I'd prefer to limit the scope of this fix to the problem we > > are aware of, and not possible problems should someone decide to reimplement > > uretprobes on different archs in a different way. Especially as this fix needs > > to be backmerged to stable kernels. > > So my personal preference would be to avoid __NR_uretprobe_32 in this patch > > and deal with it if it ever gets implemented. > > That's fine, but I want the exception to be designed to fail closed > instead of failing open. I think my proposed future-proof check does > this. I think it does. I think the code in the patch does too, since it avoids the special handling for compat, so defaults to the existing behavior which blocks the syscall. Eyal.
