On 2021-08-27 15:49, Paul Moore wrote: > On Fri, Aug 27, 2021 at 9:36 AM Richard Guy Briggs wrote: > > On 2021-08-26 15:14, Paul Moore wrote: > > > On Thu, Aug 26, 2021 at 12:32 PM Richard Guy Briggs wrote: > > > > I'm getting: > > > > # ./iouring.2 > > > > Kernel thread io_uring-sq is not running. > > > > Unable to setup io_uring: Permission denied > > > > > > > > # ./iouring.3s > > > > >>> server started, pid = 2082 > > > > >>> memfd created, fd = 3 > > > > io_uring_queue_init: Permission denied > > > > > > > > I have CONFIG_IO_URING=y set, what else is needed? > > > > > > I'm not sure how you tried to run those tests, but try running as root > > > and with SELinux in permissive mode. > > > > Ok, they ran, including iouring.4. iouring.2 claimed twice: "Kernel > > thread io_uring-sq is not running." and I didn't get any URING records > > with ausearch. I don't know if any of this is expected. > > Now that I've written iouring.4, I would skip the others; while > helpful at the time, they are pretty crap. Ok. > I have no idea what kernel you are running, but I'm going to assume > you've applied the v2 patches (if not, you obviously need to do that > ). Beyond that you may need to set a filter for the > io_uring_enter() syscall to force the issue; theoretically your audit > userspace patches should allow a uring op specifically to be filtered > but I haven't had a chance to try that yet so either the kernel or > userspace portion could be broken. I'm running audit/next (on 5.14-rc1) with your v2 patches. I did set a syscall filter for -a exit,always -F arch=b64 -S io_uring_enter,io_uring_setup,io_uring_register -F key=iouringsyscall and that yielded some records with a couple of orphans that surprised me a bit. I've attached that log. I was a bit surprised there were no records for ./iouring.3*. I'm now testing the new "-a uring,always -U ..." to get that userspace code working as expected... > At this point if you are running into problems you'll probably need to > spend some time debugging them, as I think you're the only person who > has tested your audit userspace patches at this point (and the only > one who has access to your latest bits). Yes, I'll do some basic debugging and then publish to avoid wasting people's time on silly bugs, but to get help on the more serious ones. > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635