Bug 153235 – [Linux] Seccomp filters: safely allocate all memory used by web process signal handler

• Component: WebKit Misc.
• Status: RESOLVED INVALID

[Michael Catanzaro]

We can't use malloc or new inside our giant SIGSYS signal handler because they are not async-signal-safe.

Thanks to Petr Pisar for reminding me of this at [1].

[1] https://lists.fedoraproject.org/archives/list/[e-mail]/thread/YV7GJ4W3T3TX7ZAXUO3MVBWV3AOGFRMF/

[Thiago Marcos P. Santos]

I think you can, because it a synchronous signal. You have total control of when the thread will jump into the signal handler. Think of it like "open()" calling a wrapper before doing the actual "open()".

The problem would be if you have to handle a SIGSYS (or pretty much any other signal) not emitted by a seccomp fault and you allocate memory.

In this case your program could be preempted on any state, including in the middle of a memory allocation.

This premiss is the reason why the whole thing works in the first place.


The problem I see would be if you call "malloc()" and malloc does some funny stuff and ultimately call a function that triggers a SIGSYS before returning. In this case things will go wrong because malloc data structures could be in a fragile state, but I suppose memory allocators will only do "brk()" and "memmap()" anonymous and you are not catching these.

[Michael Catanzaro]

Yeah, good point. So this bug is invalid, except insofar that this code is very fragile, which is no surprise.... Unfortunately, malloc does do funny stuff, and that funny stuff changes (see bug #140068); to be safe, we have to manually inspect each new version of glibc, which nobody is going to do. In practice, we'll just have to respond to breakage when it's detected.