-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: Is there any way for the NotifReceive function to end? #104
Comments
The Linux API with ioctl SECCOMP_IOCTL_NOTIF_RECV does not seem to have an easy way to interrupt it when the container terminates (when the seccomp filter is no longer attached to any process). I see this was discussed on the lkml: The kernel function
So the go routine could be tied to a thread (with runtime.LockOSThread) and we could have a Golang ticker interrupting it regularly and check if the container still exists. I wonder if Golang thread preemption with SIGURG would help us for that somehow. cc @rata |
Hi~ @alban I try to bind notifHandler goroutine with seccomp agent single thread by using runtime.LockOSThread. When the process monitored by notifHandler exited, another goroutine would kill the notifHandler thread. But If the notifHandler thread is killed, the seccomp agent process will restart and the monitored data will be lost. So it seems that the notifHandler coroutine needs to exit by itself. code such as:
|
Hi~ @alban @rata thanks for help and reply~ The first is to send a signal to the kernel to interrupt the NotifReceive function in user mode (it is difficult to implement at present, and the related libseccomp-golang api is not yet supported). The second is to imitate The kernel writes data to ScmpFd to activate the NotifReceive function (I don't know if this is feasible). |
I think you have to use |
Hi~ @alban I use syscall.Tgkill(processFd.tgid, processFd.tid, syscall.SIGTERM) or kErr := syscall.Tgkill(processFd.tgid, processFd.tid, syscall.SIGKILL) . These will cause the seccomp-agent process to be killed. The Seccomp agent container restart. test code:
|
I guess is only killed if it doesn't handle the signal (and the signal it is sent default action is to kill the process), right? Anyways, I think what I mentioned here might be a better option: kinvolk/seccompagent#30 (comment). If we poll on the fd, we should detect either when a notification is received or when the process died. See this upstream commit (also mentioned in the linked issue): torvalds/linux@99cdb8b We will probably need some plumbing here and it will not be a small change, at least semantically. So I'd like to see what @pcmoore @drakenclimber @kolyshkin think about this. |
When no more information is generated in ScmpFd, the NotifReceive function will block and will not return a value. At this time, the process corresponding to ScmpFd has exited, so there is no need to monitor again. Is there any way to end the NotifReceive function?
The text was updated successfully, but these errors were encountered: