Re: Fwd: Safety Against Memory Leaks in opendir()

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Fri, 10 Feb 2017 12:41:56 +0000

>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

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC