RFE: investigate the new SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP seccomp() flag

[pcmoore]

Linux v6.6 is expected to add support for a new seccomp() flag, SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP. Investigate what we need to do for libseccomp.

My initial thought is that as this really only affects kernel scheduling, we may not need to do much other than to enable setting it, likely via a libseccomp filter attribute.

• https://lore.kernel.org/all/20230308073201.3102738-5-avagin@google.com

[drakenclimber]

I read through the entire thread. I agree that it looks pretty straightforward from a libseccomp point of view. Likely a filter attribute.

This message [1] from the author, @avagin, outlines a potential use case. For me, it validates the filter attribute approach.

[1] https://lore.kernel.org/all/CANaxB-wykCH+2fgrwBNe2BkTmEJpZjhsFBekiS_qaQHz4vYt8Q@mail.gmail.com/

[pcmoore]

Now that I'm looking at this to implement the functionality in libseccomp, I'm realizing that we probably don't need to do anything, at least not with our current approach to the seccomp notification mechanism. Based on the kselftest code, it appears that the proper way to use SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP is to load a seccomp filter with notification enabled and then set SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP using ioctl(). Considering that we don't support other notification response actions, e.g. returning a fd, leaving that up to the library's caller, I think our best, and most consistent, option is to do the same here and leave the code as-is.

Thoughts @drakenclimber?

[drakenclimber]

Now that I'm looking at this to implement the functionality in libseccomp, I'm realizing that we probably don't need to do anything, at least not with our current approach to the seccomp notification mechanism. Based on the kselftest code, it appears that the proper way to use SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP is to load a seccomp filter with notification enabled and then set SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP using ioctl(). Considering that we don't support other notification response actions, e.g. returning a fd, leaving that up to the library's caller, I think our best, and most consistent, option is to do the same here and leave the code as-is.

Thoughts @drakenclimber?

I agree. The test clearly shows the ioctl() usage which is out of scope for libseccomp. Looks like there's nothing for us to do.

[drakenclimber]

I'm going to close this, but feel free to re-open it if I'm missing something.

[pcmoore]

I realize I was the one who originally suggested there was nothing to do here, but while talking with someone who was planning to work on #380 it occurred to me that there was some similarity in terms of providing an API that wraps the ioctl() calls.

I'm going to reopen this for now, but let's see how things go in #380.