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: <1365519128.18069.55@driftwood>
Date:	Tue, 09 Apr 2013 09:52:08 -0500
From:	Rob Landley <rob@...dley.net>
To:	Byron Stanoszek <bstanoszek@...time.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] rootmpfs

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...

I'll poke at it.

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/