>I've been studying the documentation of S6. I see that s6-svscan has
>been
>designed so that it can run as init (PID==1), and there's a note that
>most
>opendir() implementations use malloc, so it may be possible to leak
>memory.
No, that's not what I wrote.
I wrote that s6-svscan will never leak memory, and I stand by it.
I also wrote is that it's impossible to guarantee that s6-svscan does
not use heap memory at all, because opendir() uses heap memory. But it
does not mean it leaks it.
Unless, of course, the libc manages to botch opendir/readdir/closedir,
but those are simple functions and I don't know of a libc that does not
get them right.
>To protect against this I'm pondering to use suckless init (sinit) as
>PID
>1, and have it spawn something supervising s6-svscan. My understanding
>is
>that sinit won't be able to leak memory in userspace.
Don't. sinit is not a correct init: it does not supervise any process.
If you kill -9 -1, then exit your shell, sinit is unable to give you
back
a way of recovering your system and you have effectively bricked it -
and
need a hard, physical reboot (and your filesystems will be dirty).
>If a suitable sinit -> supervisor -> s6-svscan chain could be made, it
>takes a little extra memory and boot-up time, but should mean that if
>opendir() leaks memory an s6-svscan dies, then the leaked memory will
>be
>recovered and the supervisor could restart s6-svscan.
sinit will not respawn s6-svscan if it dies.
Check it:
http://git.suckless.org/sinit/tree/sinit.c
>I think it would be worth the trade-off of always using a little extra
>resources to get the extra protection. Does it seem wise? Am I
>overlooking
>things or misunderstanding things?
>
>If it makes a difference I plan to use musl libc.
If you are looking to get theoretical correctness, sinit is not what
you
want anymore than s6-svscan. Even runit is not (it assumes that you want
to start stage 3 as soon as stage 2 dies, even if it crashed).
If you are looking to get a working system, you will have no problem
using s6-svscan as process 1, because there will be no memory leak.
If you are using musl, it's easy to check:
http://git.musl-libc.org/cgit/musl/tree/src/dirent/opendir.c
http://git.musl-libc.org/cgit/musl/tree/src/dirent/readdir.c
http://git.musl-libc.org/cgit/musl/tree/src/dirent/closedir.c
So: don't worry, be happy.
--
Laurent
Received on Fri Feb 10 2017 - 12:41:56 UTC