linux-kernel - Re: [RFC] rootmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1365614602.18069.65@driftwood>
Date:	Wed, 10 Apr 2013 12:23:22 -0500
From:	Rob Landley <rob@...dley.net>
To:	Randy Dunlap <rdunlap@...radead.org>
Cc:	Byron Stanoszek <bstanoszek@...time.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] rootmpfs

On 04/09/2013 12:28:21 PM, Randy Dunlap wrote:
> On 04/09/13 07:52, Rob Landley wrote:
> > On 04/05/2013 02:53:12 PM, Byron Stanoszek wrote:
> >> Rob,
> >>
> >> FWIW I have a patch to do something like this. It even gives you a  
> rdsize=xxx
> >> tunable kernel parameter that lets you specify the size of the  
> tmpfs, which
> >> acts like the -osize= mount flag (so phrases like 100M or 20%  
> works). So doing
> >> things like 'cat /dev/zero > filename' will not run you out of all  
> available
> >> memory. (Note: If you don't specify rdsize= on the kernel command  
> line, it will
> >> not convert rootfs to tmpfs).
> >
> > In init/do_mounts.c the boot infrastructure already has kernel  
> command line options "rootflags=" and "rootfstype=", so the logical  
> thing to do is probably to hook those up to rootfs. (That way instead  
> of special casing a new option we use the existing tmpfs option  
> parsing.)
> >
> > The default tmpfs size is 50%, which solves the "trivial to exhaust  
> memory and panic a kernel running under rootfs" problem. Having one  
> tmpfs also fixes the case that multiple tmpfs mounts (for /home and  
> /var, for example,) have separate memory limits that don't coordinate  
> with each other, so if /home can use 30% and /var can use 30%, that's  
> 60% plus whatever rootfs is already using, so you can easily squeeze  
> the kernel against the wall without meaning to. (Yes, you can make  
> one tmpfs mount and --bind mount from there to elsewhere, I've seen  
> that done. Having rootfs just _be_ tmpfs makes this much easier to  
> track.)
> >
> >> See attached.
> >
> > You're not actually changing the type of rootfs, you're  
> overmounting it with a second filesystem instance. (Mine hasn't got a  
> "change", it just mounts it correctly the first time, and there's  
> just one rootfs instance.)
> >
> > What _is_ wrong with my version is that if you select tmpfs as a  
> module bad things happen; it tries to use code that's not there. I  
> dunno of an #ifdef that distinguishes between module and builtin, so  
> I think I have to add another kconfig symbol...
> 
> See include/linux/kconfig.h:  IS_MODULE() and IS_BUILTIN().

Good to know, thanks.

(It turns out I was looking at a distro kernel directory and vanilla  
only lets TMPFS be static anyway, but I should still use that in case  
it changes, and I think I still need to wire up a rootfsflags argument.)

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/