Re: [PATCH 2/3] io_uring: add support for BPF filtering for opcode restrictions

[Jens Axboe <axboe@kernel.dk>]

On 1/15/26 2:05 PM, Jonathan Corbet wrote:
> Jens Axboe <axboe@kernel.dk> writes:
> 
>> On 1/15/26 1:11 PM, Jonathan Corbet wrote:
>>> Jens Axboe <axboe@kernel.dk> writes:
>>>
>>>> This adds support for loading BPF programs with io_uring, which can
>>>> restrict the opcodes performed. Unlike IORING_REGISTER_RESTRICTIONS,
>>>> using BPF programs allow fine grained control over both the opcode
>>>> in question, as well as other data associated with the request.
>>>> Initially only IORING_OP_SOCKET is supported.
>>>
>>> A minor nit...
>>>
>>> [...]
>>>
>>>> +/*
>>>> + * Run registered filters for a given opcode. Return of 0 means that the
>>>> + * request should be allowed.
>>>> + */
>>>> +int __io_uring_run_bpf_filters(struct io_restriction *res, struct io_kiocb *req)
>>>> +{
>>>
>>> That comment seems to contradict the actual logic in this function, as
>>> well as the example BPF program in the cover letter.  So
>>> s/allowed/blocked/?
>>
>> Are you talking about __io_uring_run_bpf_filters() or the filters
>> themselves? For the former, 0 does indeed mean "yep let it rip", for the
>> filters it's 0/1 where 0 is deny and 1 is allow. I should probably make
>> the comment more explicit on that front...
> 
> Ah, yes, I got confused between the two, sorry for the noise.

It's useful, I expanded the comment now:

/*                                                                              
 * Run registered filters for a given opcode. For filters, a return of 0 denies 
 * execution of the request, a return of 1 allows it. If any filter for an      
 * opcode returns 0, filter processing is stopped, and the request is denied.   
 * This also stops the processing of filters.                                   
 *                                                                              
 * __io_uring_run_bpf_filters() returns 0 on success, allow running the         
 * request, and -EACCES when a request is denied.                               
 */ 

I am making one more change in this patch though - to deny by default.
If restrictions are registered with BPF, we should probably have the
same logic as the classic restrictions, where if an opcode isn't
explicitly enabled, it is denied. That makes it easier to future proof a
filter set. I do want to do that without needing a dummy BPF program
attached to each one, however...

-- 
Jens Axboe