[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
enabled") introduced using tmpfs as the rootfs filesystem.  The use of
tmpfs is limited to systems that do not specify "root=" on the boot
command line.

Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
must be a valid reason for this check, this patch introduces a new boot
command line option named "noramfs" to force rootfs to use tmpfs.

Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 ++
 init/do_mounts.c                                | 15 +++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..fd82df2ff150 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2733,6 +2733,8 @@
 
 	nopcid		[X86-64] Disable the PCID cpu feature.
 
+	noramfs		Don't use ramfs for rootfs, use tmpfs.
+
 	norandmaps	Don't use address space randomization.  Equivalent to
 			echo 0 > /proc/sys/kernel/randomize_va_space
 
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..74d8bfcd1294 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -315,6 +315,16 @@ static int __init root_data_setup(char *str)
 	return 1;
 }
 
+static bool force_tmpfs;
+static int __init force_tmpfs_setup(char *str)
+{
+	if (*str)
+		return 0;
+	force_tmpfs = true;
+	return 1;
+
+}
+
 static char * __initdata root_fs_names;
 static int __init fs_names_setup(char *str)
 {
@@ -332,6 +342,7 @@ static int __init root_delay_setup(char *str)
 __setup("rootflags=", root_data_setup);
 __setup("rootfstype=", fs_names_setup);
 __setup("rootdelay=", root_delay_setup);
+__setup("noramfs", force_tmpfs_setup);
 
 static void __init get_fs_names(char *page)
 {
@@ -632,8 +643,8 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
+	if (IS_ENABLED(CONFIG_TMPFS) && (force_tmpfs || (!saved_root_name[0] &&
+		(!root_fs_names || strstr(root_fs_names, "tmpfs"))))) {
 		err = shmem_init();
 		is_tmpfs = true;
 	} else {
-- 
2.7.5

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
enabled") introduced using tmpfs as the rootfs filesystem.  The use of
tmpfs is limited to systems that do not specify "root=" on the boot
command line.

Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
must be a valid reason for this check, this patch introduces a new boot
command line option named "noramfs" to force rootfs to use tmpfs.

Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 ++
 init/do_mounts.c                                | 15 +++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..fd82df2ff150 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2733,6 +2733,8 @@
 
 	nopcid		[X86-64] Disable the PCID cpu feature.
 
+	noramfs		Don't use ramfs for rootfs, use tmpfs.
+
 	norandmaps	Don't use address space randomization.  Equivalent to
 			echo 0 > /proc/sys/kernel/randomize_va_space
 
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..74d8bfcd1294 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -315,6 +315,16 @@ static int __init root_data_setup(char *str)
 	return 1;
 }
 
+static bool force_tmpfs;
+static int __init force_tmpfs_setup(char *str)
+{
+	if (*str)
+		return 0;
+	force_tmpfs = true;
+	return 1;
+
+}
+
 static char * __initdata root_fs_names;
 static int __init fs_names_setup(char *str)
 {
@@ -332,6 +342,7 @@ static int __init root_delay_setup(char *str)
 __setup("rootflags=", root_data_setup);
 __setup("rootfstype=", fs_names_setup);
 __setup("rootdelay=", root_delay_setup);
+__setup("noramfs", force_tmpfs_setup);
 
 static void __init get_fs_names(char *page)
 {
@@ -632,8 +643,8 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
+	if (IS_ENABLED(CONFIG_TMPFS) && (force_tmpfs || (!saved_root_name[0] &&
+		(!root_fs_names || strstr(root_fs_names, "tmpfs"))))) {
 		err = shmem_init();
 		is_tmpfs = true;
 	} else {
-- 
2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
enabled") introduced using tmpfs as the rootfs filesystem.  The use of
tmpfs is limited to systems that do not specify "root=" on the boot
command line.

Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
must be a valid reason for this check, this patch introduces a new boot
command line option named "noramfs" to force rootfs to use tmpfs.

Signed-off-by: Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 ++
 init/do_mounts.c                                | 15 +++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..fd82df2ff150 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2733,6 +2733,8 @@
 
 	nopcid		[X86-64] Disable the PCID cpu feature.
 
+	noramfs		Don't use ramfs for rootfs, use tmpfs.
+
 	norandmaps	Don't use address space randomization.  Equivalent to
 			echo 0 > /proc/sys/kernel/randomize_va_space
 
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..74d8bfcd1294 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -315,6 +315,16 @@ static int __init root_data_setup(char *str)
 	return 1;
 }
 
+static bool force_tmpfs;
+static int __init force_tmpfs_setup(char *str)
+{
+	if (*str)
+		return 0;
+	force_tmpfs = true;
+	return 1;
+
+}
+
 static char * __initdata root_fs_names;
 static int __init fs_names_setup(char *str)
 {
@@ -332,6 +342,7 @@ static int __init root_delay_setup(char *str)
 __setup("rootflags=", root_data_setup);
 __setup("rootfstype=", fs_names_setup);
 __setup("rootdelay=", root_delay_setup);
+__setup("noramfs", force_tmpfs_setup);
 
 static void __init get_fs_names(char *page)
 {
@@ -632,8 +643,8 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
+	if (IS_ENABLED(CONFIG_TMPFS) && (force_tmpfs || (!saved_root_name[0] &&
+		(!root_fs_names || strstr(root_fs_names, "tmpfs"))))) {
 		err = shmem_init();
 		is_tmpfs = true;
 	} else {
-- 
2.7.5

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> enabled") introduced using tmpfs as the rootfs filesystem.  The use of
> tmpfs is limited to systems that do not specify "root=" on the boot
> command line.
> 
> Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
> must be a valid reason for this check, this patch introduces a new boot
> command line option named "noramfs" to force rootfs to use tmpfs.
> 
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>

How about just:

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6d..af66ede 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -632,8 +632,8 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
+	if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] ||
+		!strcmp(saved_root_name, "tmpfs"))) {
 		err = shmem_init();
 		is_tmpfs = true;
 	} else {

(Obviously-signed-off-by: Rob Landley <rob@landley.net>)

I.E. if you somehow just can't stop yourself from specifying root= when
using rootfs, have "root=tmpfs" do what you want.

(The old "I configured in tmpfs and am using rootfs but I want that rootfs
to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
it?)

> ---
>  Documentation/admin-guide/kernel-parameters.txt |  2 ++
>  init/do_mounts.c                                | 15 +++++++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)

I suppose I should do a documentation update too. Lemme send a proper one
after work...

Rob

P.S. While I'm at it, I've meant to wire up rootflags= so you can specify
a memory limit other than 50% forever, I should do that too. And resend
my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug
workaround)...

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> enabled") introduced using tmpfs as the rootfs filesystem.  The use of
> tmpfs is limited to systems that do not specify "root=" on the boot
> command line.
> 
> Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
> must be a valid reason for this check, this patch introduces a new boot
> command line option named "noramfs" to force rootfs to use tmpfs.
> 
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>

How about just:

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6d..af66ede 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -632,8 +632,8 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
+	if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] ||
+		!strcmp(saved_root_name, "tmpfs"))) {
 		err = shmem_init();
 		is_tmpfs = true;
 	} else {

(Obviously-signed-off-by: Rob Landley <rob@landley.net>)

I.E. if you somehow just can't stop yourself from specifying root= when
using rootfs, have "root=tmpfs" do what you want.

(The old "I configured in tmpfs and am using rootfs but I want that rootfs
to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
it?)

> ---
>  Documentation/admin-guide/kernel-parameters.txt |  2 ++
>  init/do_mounts.c                                | 15 +++++++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)

I suppose I should do a documentation update too. Lemme send a proper one
after work...

Rob

P.S. While I'm at it, I've meant to wire up rootflags= so you can specify
a memory limit other than 50% forever, I should do that too. And resend
my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug
workaround)...
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:
> On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> > Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> > enabled") introduced using tmpfs as the rootfs filesystem.  The use of
> > tmpfs is limited to systems that do not specify "root=" on the boot
> > command line.
> > 
> > Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
> > must be a valid reason for this check, this patch introduces a new boot
> > command line option named "noramfs" to force rootfs to use tmpfs.
> > 
> > Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> 
> How about just:
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 7cf4f6d..af66ede 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -632,8 +632,8 @@ int __init init_rootfs(void)
>  	if (err)
>  		return err;
> 
> -	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> -		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> +	if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] ||
> +		!strcmp(saved_root_name, "tmpfs"))) {
>  		err = shmem_init();
>  		is_tmpfs = true;
>  	} else {
> 
> (Obviously-signed-off-by: Rob Landley <rob@landley.net>)
> 
> I.E. if you somehow just can't stop yourself from specifying root= when
> using rootfs, have "root=tmpfs" do what you want.

I tried overloading "rootfstype=tmpfs", before posting this work
around, but for some reason that just doesn't work.

> 
> (The old "I configured in tmpfs and am using rootfs but I want that rootfs
> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> it?)

I must be missing something.  Which systems don't specify "root=" on
the boot command line.  If we want to include and restore xattrs,
there needs to be a way of using tmpfs.

Mimi

> 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |  2 ++
> >  init/do_mounts.c                                | 15 +++++++++++++--
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> I suppose I should do a documentation update too. Lemme send a proper one
> after work...
> 
> Rob
> 
> P.S. While I'm at it, I've meant to wire up rootflags= so you can specify
> a memory limit other than 50% forever, I should do that too. And resend
> my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug
> workaround)...
> 

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:
> On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> > Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> > enabled") introduced using tmpfs as the rootfs filesystem.  The use of
> > tmpfs is limited to systems that do not specify "root=" on the boot
> > command line.
> > 
> > Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
> > must be a valid reason for this check, this patch introduces a new boot
> > command line option named "noramfs" to force rootfs to use tmpfs.
> > 
> > Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> 
> How about just:
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 7cf4f6d..af66ede 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -632,8 +632,8 @@ int __init init_rootfs(void)
>  	if (err)
>  		return err;
> 
> -	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> -		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> +	if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] ||
> +		!strcmp(saved_root_name, "tmpfs"))) {
>  		err = shmem_init();
>  		is_tmpfs = true;
>  	} else {
> 
> (Obviously-signed-off-by: Rob Landley <rob@landley.net>)
> 
> I.E. if you somehow just can't stop yourself from specifying root= when
> using rootfs, have "root=tmpfs" do what you want.

I tried overloading "rootfstype=tmpfs", before posting this work
around, but for some reason that just doesn't work.

> 
> (The old "I configured in tmpfs and am using rootfs but I want that rootfs
> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> it?)

I must be missing something. ?Which systems don't specify "root=" on
the boot command line. ?If we want to include and restore xattrs,
there needs to be a way of using tmpfs.

Mimi

> 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |  2 ++
> >  init/do_mounts.c                                | 15 +++++++++++++--
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> I suppose I should do a documentation update too. Lemme send a proper one
> after work...
> 
> Rob
> 
> P.S. While I'm at it, I've meant to wire up rootflags= so you can specify
> a memory limit other than 50% forever, I should do that too. And resend
> my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug
> workaround)...
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:
> On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> > Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> > enabled") introduced using tmpfs as the rootfs filesystem.  The use of
> > tmpfs is limited to systems that do not specify "root=" on the boot
> > command line.
> > 
> > Without the check "!saved_root_name[0]", rootfs uses tmpfs.  As there
> > must be a valid reason for this check, this patch introduces a new boot
> > command line option named "noramfs" to force rootfs to use tmpfs.
> > 
> > Signed-off-by: Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> 
> How about just:
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 7cf4f6d..af66ede 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -632,8 +632,8 @@ int __init init_rootfs(void)
>  	if (err)
>  		return err;
> 
> -	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> -		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> +	if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] ||
> +		!strcmp(saved_root_name, "tmpfs"))) {
>  		err = shmem_init();
>  		is_tmpfs = true;
>  	} else {
> 
> (Obviously-signed-off-by: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>)
> 
> I.E. if you somehow just can't stop yourself from specifying root= when
> using rootfs, have "root=tmpfs" do what you want.

I tried overloading "rootfstype=tmpfs", before posting this work
around, but for some reason that just doesn't work.

> 
> (The old "I configured in tmpfs and am using rootfs but I want that rootfs
> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> it?)

I must be missing something.  Which systems don't specify "root=" on
the boot command line.  If we want to include and restore xattrs,
there needs to be a way of using tmpfs.

Mimi

> 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |  2 ++
> >  init/do_mounts.c                                | 15 +++++++++++++--
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> I suppose I should do a documentation update too. Lemme send a proper one
> after work...
> 
> Rob
> 
> P.S. While I'm at it, I've meant to wire up rootflags= so you can specify
> a memory limit other than 50% forever, I should do that too. And resend
> my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug
> workaround)...
> 

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
rootfs
>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>> it?)
> 
> I must be missing something.  Which systems don't specify "root=" on
> the boot command line.

Any system using initrd or initramfs?

I have one at https://github.com/landley/mkroot that doesn't, for
example. It's 600 lines of bash that builds simple Linux systems for a
bunch of different architectures, each with a qemu wrapper to boot it to
a shell prompt. And yes, it's using tmpfs for its initramfs, you can
tell because "grep rootfs /proc/mounts" gives a size. That's also where
I tested the patch I sent you.

The root= option specifies the filesystem to mount OVER rootfs. I.E.
it's the fallback root filesystem to mount when initramfs doesn't
contain an executable /init that can become PID 1. If you DO have an
/init in rootfs which the kernel manages to launch as PID 1, the kernel
code never reaches the part that uses the root= argument.

(Look for the call to prepare_namespace() in init/main.c, notice how
it's only called if it can't _already_ find "/init".)

That's why the test I added for initramfs vs initmpfs was "did they
specify root=", because if they did it means they're telling the kernel
what to mount over rootfs, so they're not staying in rootfs. That's what
that argument MEANS. They're telling init/main.c what fallback
filesystem to mount over rootfs _after_ failing to find /init in rootfs,
therefore they're not keeping rootfs as their root filesystem for userspace.

That said, a lot of people don't understand how this works, and they set
root= to things like /dev/ram when using initrd because "we must set
this knob to something, this is something, therefore we must set this
knob to it". The fact setting root=/dev/random would have the exact same
effect doesn't seem to bother them, they had Done It and It Worked,
therefore it was the Right Thing To Do. QED.

The patch last message was me going "alright, if people can't NOT
twiddle the knob, even when doing it breaks things in an immediate and
obvious way, and a big DO NOT TOUCH sign won't dissuade them, just give
the knob an explicit 'off' setting that literally does the same thing as
not touching it at all would".

Your solution was to add a safety catch for the knob, which is edging
into Rube Goldberg territory if you ask me.

> If we want to include and restore xattrs,
> there needs to be a way of using tmpfs.

Yes, using tmpfs for initramfs is useful, that's why I submitted patches
to hook it up back in 2013.

(Personally I find "cat /dev/zero > /filename" _not_ hard locking your
system instantly the most compelling feature. Although I believe what
motivated my initmpfs patches way back when was somebody wanting to
install an rpm into intramfs and the installer failing because ramfs
hasn't got a size so "df" always returns zero.)

> Mimi

Rob

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
rootfs
>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>> it?)
> 
> I must be missing something. ?Which systems don't specify "root=" on
> the boot command line.

Any system using initrd or initramfs?

I have one at https://github.com/landley/mkroot that doesn't, for
example. It's 600 lines of bash that builds simple Linux systems for a
bunch of different architectures, each with a qemu wrapper to boot it to
a shell prompt. And yes, it's using tmpfs for its initramfs, you can
tell because "grep rootfs /proc/mounts" gives a size. That's also where
I tested the patch I sent you.

The root= option specifies the filesystem to mount OVER rootfs. I.E.
it's the fallback root filesystem to mount when initramfs doesn't
contain an executable /init that can become PID 1. If you DO have an
/init in rootfs which the kernel manages to launch as PID 1, the kernel
code never reaches the part that uses the root= argument.

(Look for the call to prepare_namespace() in init/main.c, notice how
it's only called if it can't _already_ find "/init".)

That's why the test I added for initramfs vs initmpfs was "did they
specify root=", because if they did it means they're telling the kernel
what to mount over rootfs, so they're not staying in rootfs. That's what
that argument MEANS. They're telling init/main.c what fallback
filesystem to mount over rootfs _after_ failing to find /init in rootfs,
therefore they're not keeping rootfs as their root filesystem for userspace.

That said, a lot of people don't understand how this works, and they set
root= to things like /dev/ram when using initrd because "we must set
this knob to something, this is something, therefore we must set this
knob to it". The fact setting root=/dev/random would have the exact same
effect doesn't seem to bother them, they had Done It and It Worked,
therefore it was the Right Thing To Do. QED.

The patch last message was me going "alright, if people can't NOT
twiddle the knob, even when doing it breaks things in an immediate and
obvious way, and a big DO NOT TOUCH sign won't dissuade them, just give
the knob an explicit 'off' setting that literally does the same thing as
not touching it at all would".

Your solution was to add a safety catch for the knob, which is edging
into Rube Goldberg territory if you ask me.

> If we want to include and restore xattrs,
> there needs to be a way of using tmpfs.

Yes, using tmpfs for initramfs is useful, that's why I submitted patches
to hook it up back in 2013.

(Personally I find "cat /dev/zero > /filename" _not_ hard locking your
system instantly the most compelling feature. Although I believe what
motivated my initmpfs patches way back when was somebody wanting to
install an rpm into intramfs and the installer failing because ramfs
hasn't got a size so "df" always returns zero.)

> Mimi

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
rootfs
>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>> it?)
> 
> I must be missing something.  Which systems don't specify "root=" on
> the boot command line.

Any system using initrd or initramfs?

I have one at https://github.com/landley/mkroot that doesn't, for
example. It's 600 lines of bash that builds simple Linux systems for a
bunch of different architectures, each with a qemu wrapper to boot it to
a shell prompt. And yes, it's using tmpfs for its initramfs, you can
tell because "grep rootfs /proc/mounts" gives a size. That's also where
I tested the patch I sent you.

The root= option specifies the filesystem to mount OVER rootfs. I.E.
it's the fallback root filesystem to mount when initramfs doesn't
contain an executable /init that can become PID 1. If you DO have an
/init in rootfs which the kernel manages to launch as PID 1, the kernel
code never reaches the part that uses the root= argument.

(Look for the call to prepare_namespace() in init/main.c, notice how
it's only called if it can't _already_ find "/init".)

That's why the test I added for initramfs vs initmpfs was "did they
specify root=", because if they did it means they're telling the kernel
what to mount over rootfs, so they're not staying in rootfs. That's what
that argument MEANS. They're telling init/main.c what fallback
filesystem to mount over rootfs _after_ failing to find /init in rootfs,
therefore they're not keeping rootfs as their root filesystem for userspace.

That said, a lot of people don't understand how this works, and they set
root= to things like /dev/ram when using initrd because "we must set
this knob to something, this is something, therefore we must set this
knob to it". The fact setting root=/dev/random would have the exact same
effect doesn't seem to bother them, they had Done It and It Worked,
therefore it was the Right Thing To Do. QED.

The patch last message was me going "alright, if people can't NOT
twiddle the knob, even when doing it breaks things in an immediate and
obvious way, and a big DO NOT TOUCH sign won't dissuade them, just give
the knob an explicit 'off' setting that literally does the same thing as
not touching it at all would".

Your solution was to add a safety catch for the knob, which is edging
into Rube Goldberg territory if you ask me.

> If we want to include and restore xattrs,
> there needs to be a way of using tmpfs.

Yes, using tmpfs for initramfs is useful, that's why I submitted patches
to hook it up back in 2013.

(Personally I find "cat /dev/zero > /filename" _not_ hard locking your
system instantly the most compelling feature. Although I believe what
motivated my initmpfs patches way back when was somebody wanting to
install an rpm into intramfs and the installer failing because ramfs
hasn't got a size so "df" always returns zero.)

> Mimi

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Arvind Sankar]

On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> rootfs
> >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> >> it?)
> > 
> > I must be missing something.  Which systems don't specify "root=" on
> > the boot command line.
> 
> Any system using initrd or initramfs?
> 

Don't a lot of initramfs setups use root= to tell the initramfs which
actual root file system to switch to after early boot?

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Arvind Sankar]

On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> rootfs
> >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> >> it?)
> > 
> > I must be missing something. ?Which systems don't specify "root=" on
> > the boot command line.
> 
> Any system using initrd or initramfs?
> 

Don't a lot of initramfs setups use root= to tell the initramfs which
actual root file system to switch to after early boot?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Arvind Sankar]

On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> rootfs
> >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> >> it?)
> > 
> > I must be missing something.  Which systems don't specify "root=" on
> > the boot command line.
> 
> Any system using initrd or initramfs?
> 

Don't a lot of initramfs setups use root= to tell the initramfs which
actual root file system to switch to after early boot?

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> > On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> > rootfs
> > >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> > >> it?)
> > > 
> > > I must be missing something.  Which systems don't specify "root=" on
> > > the boot command line.
> > 
> > Any system using initrd or initramfs?
> > 
> 
> Don't a lot of initramfs setups use root= to tell the initramfs which
> actual root file system to switch to after early boot?

With your patch and specifying "root=tmpfs", dracut is complaining:

dracut: FATAL: Don't know how to handle 'root=tmpfs'
dracut: refusing to continue

Mimi

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> > On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> > rootfs
> > >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> > >> it?)
> > > 
> > > I must be missing something. ?Which systems don't specify "root=" on
> > > the boot command line.
> > 
> > Any system using initrd or initramfs?
> > 
> 
> Don't a lot of initramfs setups use root= to tell the initramfs which
> actual root file system to switch to after early boot?

With your patch and specifying "root=tmpfs", dracut is complaining:

dracut: FATAL: Don't know how to handle 'root=tmpfs'
dracut: refusing to continue

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
> > On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> > > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
> > rootfs
> > >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
> > >> it?)
> > > 
> > > I must be missing something.  Which systems don't specify "root=" on
> > > the boot command line.
> > 
> > Any system using initrd or initramfs?
> > 
> 
> Don't a lot of initramfs setups use root= to tell the initramfs which
> actual root file system to switch to after early boot?

With your patch and specifying "root=tmpfs", dracut is complaining:

dracut: FATAL: Don't know how to handle 'root=tmpfs'
dracut: refusing to continue

Mimi

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something.  Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?

You mean the option that _isn't_ passed through as an environment
variable (the way ROOT= would be) so you have to parse /proc/cmdline to
to see if it was passed in?

If you really, really, really, really, really want to double down on the
"no, this is the button, it doesn't do what I thought but I will MAKE it
work" obsession, sure.

> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

[googles]... I do not understand why this package exists.

If you're switching to another root filesystem, using a tool that
wikipedia[citation needed] says has no purpose but to switch to another
root filesystem, (so let's reproduce the kernel infrastructure in
userspace while leaving it the kernel too)... why do you need initramfs
to be tmpfs? You're using it for half a second, then discarding it,
what's the point of it being tmpfs?

Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
is configured in, even when you're then going to overmount it with
something else like you're doing, let's just _remove_ the test. If it
can be tmpfs, have it be tmpfs.

Rob

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something. ?Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?

You mean the option that _isn't_ passed through as an environment
variable (the way ROOT= would be) so you have to parse /proc/cmdline to
to see if it was passed in?

If you really, really, really, really, really want to double down on the
"no, this is the button, it doesn't do what I thought but I will MAKE it
work" obsession, sure.

> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

[googles]... I do not understand why this package exists.

If you're switching to another root filesystem, using a tool that
wikipedia[citation needed] says has no purpose but to switch to another
root filesystem, (so let's reproduce the kernel infrastructure in
userspace while leaving it the kernel too)... why do you need initramfs
to be tmpfs? You're using it for half a second, then discarding it,
what's the point of it being tmpfs?

Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
is configured in, even when you're then going to overmount it with
something else like you're doing, let's just _remove_ the test. If it
can be tmpfs, have it be tmpfs.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something.  Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?

You mean the option that _isn't_ passed through as an environment
variable (the way ROOT= would be) so you have to parse /proc/cmdline to
to see if it was passed in?

If you really, really, really, really, really want to double down on the
"no, this is the button, it doesn't do what I thought but I will MAKE it
work" obsession, sure.

> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

[googles]... I do not understand why this package exists.

If you're switching to another root filesystem, using a tool that
wikipedia[citation needed] says has no purpose but to switch to another
root filesystem, (so let's reproduce the kernel infrastructure in
userspace while leaving it the kernel too)... why do you need initramfs
to be tmpfs? You're using it for half a second, then discarding it,
what's the point of it being tmpfs?

Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
is configured in, even when you're then going to overmount it with
something else like you're doing, let's just _remove_ the test. If it
can be tmpfs, have it be tmpfs.

Rob

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:

> > With your patch and specifying "root=tmpfs", dracut is complaining:
> > 
> > dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > dracut: refusing to continue
> 
> [googles]... I do not understand why this package exists.
> 
> If you're switching to another root filesystem, using a tool that
> wikipedia[citation needed] says has no purpose but to switch to another
> root filesystem, (so let's reproduce the kernel infrastructure in
> userspace while leaving it the kernel too)... why do you need initramfs
> to be tmpfs? You're using it for half a second, then discarding it,
> what's the point of it being tmpfs?

Unlike the kernel image which is signed by the distros, the initramfs
doesn't come signed, because it is built on the target system.  Even
if the initramfs did come signed, it is beneficial to measure and
appraise the individual files in the initramfs.

> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> is configured in, even when you're then going to overmount it with
> something else like you're doing, let's just _remove_ the test. If it
> can be tmpfs, have it be tmpfs.

Very much appreciated!

thanks,

Mimi

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:

> > With your patch and specifying "root=tmpfs", dracut is complaining:
> > 
> > dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > dracut: refusing to continue
> 
> [googles]... I do not understand why this package exists.
> 
> If you're switching to another root filesystem, using a tool that
> wikipedia[citation needed] says has no purpose but to switch to another
> root filesystem, (so let's reproduce the kernel infrastructure in
> userspace while leaving it the kernel too)... why do you need initramfs
> to be tmpfs? You're using it for half a second, then discarding it,
> what's the point of it being tmpfs?

Unlike the kernel image which is signed by the distros, the initramfs
doesn't come signed, because it is built on the target system. ?Even
if the initramfs did come signed, it is beneficial to measure and
appraise the individual files in the initramfs.

> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> is configured in, even when you're then going to overmount it with
> something else like you're doing, let's just _remove_ the test. If it
> can be tmpfs, have it be tmpfs.

Very much appreciated!

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:

> > With your patch and specifying "root=tmpfs", dracut is complaining:
> > 
> > dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > dracut: refusing to continue
> 
> [googles]... I do not understand why this package exists.
> 
> If you're switching to another root filesystem, using a tool that
> wikipedia[citation needed] says has no purpose but to switch to another
> root filesystem, (so let's reproduce the kernel infrastructure in
> userspace while leaving it the kernel too)... why do you need initramfs
> to be tmpfs? You're using it for half a second, then discarding it,
> what's the point of it being tmpfs?

Unlike the kernel image which is signed by the distros, the initramfs
doesn't come signed, because it is built on the target system.  Even
if the initramfs did come signed, it is beneficial to measure and
appraise the individual files in the initramfs.

> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> is configured in, even when you're then going to overmount it with
> something else like you're doing, let's just _remove_ the test. If it
> can be tmpfs, have it be tmpfs.

Very much appreciated!

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> 
>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>
>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>> dracut: refusing to continue
>>
>> [googles]... I do not understand why this package exists.
>>
>> If you're switching to another root filesystem, using a tool that
>> wikipedia[citation needed] says has no purpose but to switch to another
>> root filesystem, (so let's reproduce the kernel infrastructure in
>> userspace while leaving it the kernel too)... why do you need initramfs
>> to be tmpfs? You're using it for half a second, then discarding it,
>> what's the point of it being tmpfs?
> 
> Unlike the kernel image which is signed by the distros, the initramfs
> doesn't come signed, because it is built on the target system.  Even
> if the initramfs did come signed, it is beneficial to measure and
> appraise the individual files in the initramfs.

You can still shoot yourself in the foot with tmpfs. People mount a /run
and a /tmp and then as a normal user you can go
https://twitter.com/landley/status/959103235305951233 and maybe the
default should be a little more clever there...

I'll throw it on the todo heap. :)

>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>> is configured in, even when you're then going to overmount it with
>> something else like you're doing, let's just _remove_ the test. If it
>> can be tmpfs, have it be tmpfs.
> 
> Very much appreciated!

Not yet tested, but something like the attached? (Sorry for the
half-finished doc changes in there, I'm at work and have a 5 minute
break. I can test properly this evening if you don't get to it...)

Rob

[-- Attachment #2: initmpfs.patch --]
[-- Type: text/x-patch, Size: 6310 bytes --]

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b98048b..a5b44b2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3771,8 +3771,14 @@
 			debug-uart get routed to the D+ and D- pins of the usb
 			port and the regular usb controller gets disabled.
 
-	root=		[KNL] Root filesystem
-			See name_to_dev_t comment in init/do_mounts.c.
+	root=		[KNL] Fallback root filesystem when not using initramfs
+			If initramfs contains an /init file to run as PID 1 the
+			kernel ignores this setting. When initramfs doesn't have
+			/init (or whatever rdinit= points to) the kernel calls
+			prepare_namespace() in init/do_mounts.c to mount another
+			filesystem over / and chroot into it, then looks for
+			/sbin/init in there. (And /etc/init, /bin/init, and
+			/bin/sh for historical reasons.)
 
 	rootdelay=	[KNL] Delay (in seconds) to pause before attempting to
 			mount the root filesystem
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
index b176928..f3c57ba 100644
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@@ -67,6 +67,10 @@ A ramfs derivative called tmpfs was created to add size limits, and the ability
 to write the data to swap space.  Normal users can be allowed write access to
 tmpfs mounts.  See Documentation/filesystems/tmpfs.txt for more information.
 
+The kernel uses tmpfs for ramfs when CONFIG_TMPFS=y and no "root=" is
+specified in the kernel command line. If you can't stop yourself from
+specifying root= you can also use "root=tmpfs".
+
 What is rootfs?
 ---------------
 
@@ -236,22 +240,10 @@ An initramfs archive is a complete self-contained root filesystem for Linux.
 If you don't already understand what shared libraries, devices, and paths
 you need to get a minimal root filesystem up and running, here are some
 references:
-http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
-http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
-http://www.linuxfromscratch.org/lfs/view/stable/
-
-The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is
-designed to be a tiny C library to statically link early userspace
-code against, along with some related utilities.  It is BSD licensed.
 
-I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
-myself.  These are LGPL and GPL, respectively.  (A self-contained initramfs
-package is planned for the busybox 1.3 release.)
-
-In theory you could use glibc, but that's not well suited for small embedded
-uses like this.  (A "hello world" program statically linked against glibc is
-over 400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to do
-name lookups, even when otherwise statically linked.)
+  http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
+  http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
+  http://www.linuxfromscratch.org/lfs/view/stable/
 
 A good first step is to get initramfs to run a statically linked "hello world"
 program as init, and test it under an emulator like qemu (www.qemu.org) or
@@ -264,11 +256,12 @@ User Mode Linux, like so:
   int main(int argc, char *argv[])
   {
     printf("Hello world!\n");
-    sleep(999999999);
+    sleep(999999999); // because if PID 1 exits the kernel panics
   }
   EOF
   gcc -static hello.c -o init
   echo init | cpio -o -H newc | gzip > test.cpio.gz
+
   # Testing external initramfs using the initrd loading mechanism.
   qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero
 
@@ -330,30 +323,3 @@ the above threads) is:
       http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
 
    and, most importantly, designed and implemented the initramfs code.
-
-Future directions:
-------------------
-
-Today (2.6.16), initramfs is always compiled in, but not always used.  The
-kernel falls back to legacy boot code that is reached only if initramfs does
-not contain an /init program.  The fallback is legacy code, there to ensure a
-smooth transition and allowing early boot functionality to gradually move to
-"early userspace" (I.E. initramfs).
-
-The move to early userspace is necessary because finding and mounting the real
-root device is complex.  Root partitions can span multiple devices (raid or
-separate journal).  They can be out on the network (requiring dhcp, setting a
-specific MAC address, logging into a server, etc).  They can live on removable
-media, with dynamically allocated major/minor numbers and persistent naming
-issues requiring a full udev implementation to sort out.  They can be
-compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
-and so on.
-
-This kind of complexity (which inevitably includes policy) is rightly handled
-in userspace.  Both klibc and busybox/uClibc are working on simple initramfs
-packages to drop into a kernel build.
-
-The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
-The kernel's current early boot code (partition detection, etc) will probably
-be migrated into a default initramfs, automatically created and used by the
-kernel build.
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6d..62232f3 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -603,7 +603,6 @@ void __init prepare_namespace(void)
 	sys_chroot(".");
 }
 
-static bool is_tmpfs;
 static struct dentry *rootfs_mount(struct file_system_type *fs_type,
 	int flags, const char *dev_name, void *data)
 {
@@ -613,7 +612,7 @@ static struct dentry *rootfs_mount(struct file_system_type *fs_type,
 	if (test_and_set_bit(0, &once))
 		return ERR_PTR(-ENODEV);
 
-	if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
+	if (IS_ENABLED(CONFIG_TMPFS))
 		fill = shmem_fill_super;
 
 	return mount_nodev(fs_type, flags, data, fill);
@@ -632,13 +631,7 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
-		err = shmem_init();
-		is_tmpfs = true;
-	} else {
-		err = init_ramfs_fs();
-	}
+	err = IS_ENABLED(CONFIG_TMPFS) ? shmem_init() : init_ramfs_fs();
 
 	if (err)
 		unregister_filesystem(&rootfs_fs_type);

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> 
>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>
>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>> dracut: refusing to continue
>>
>> [googles]... I do not understand why this package exists.
>>
>> If you're switching to another root filesystem, using a tool that
>> wikipedia[citation needed] says has no purpose but to switch to another
>> root filesystem, (so let's reproduce the kernel infrastructure in
>> userspace while leaving it the kernel too)... why do you need initramfs
>> to be tmpfs? You're using it for half a second, then discarding it,
>> what's the point of it being tmpfs?
> 
> Unlike the kernel image which is signed by the distros, the initramfs
> doesn't come signed, because it is built on the target system. ?Even
> if the initramfs did come signed, it is beneficial to measure and
> appraise the individual files in the initramfs.

You can still shoot yourself in the foot with tmpfs. People mount a /run
and a /tmp and then as a normal user you can go
https://twitter.com/landley/status/959103235305951233 and maybe the
default should be a little more clever there...

I'll throw it on the todo heap. :)

>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>> is configured in, even when you're then going to overmount it with
>> something else like you're doing, let's just _remove_ the test. If it
>> can be tmpfs, have it be tmpfs.
> 
> Very much appreciated!

Not yet tested, but something like the attached? (Sorry for the
half-finished doc changes in there, I'm at work and have a 5 minute
break. I can test properly this evening if you don't get to it...)

Rob

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> 
>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>
>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>> dracut: refusing to continue
>>
>> [googles]... I do not understand why this package exists.
>>
>> If you're switching to another root filesystem, using a tool that
>> wikipedia[citation needed] says has no purpose but to switch to another
>> root filesystem, (so let's reproduce the kernel infrastructure in
>> userspace while leaving it the kernel too)... why do you need initramfs
>> to be tmpfs? You're using it for half a second, then discarding it,
>> what's the point of it being tmpfs?
> 
> Unlike the kernel image which is signed by the distros, the initramfs
> doesn't come signed, because it is built on the target system.  Even
> if the initramfs did come signed, it is beneficial to measure and
> appraise the individual files in the initramfs.

You can still shoot yourself in the foot with tmpfs. People mount a /run
and a /tmp and then as a normal user you can go
https://twitter.com/landley/status/959103235305951233 and maybe the
default should be a little more clever there...

I'll throw it on the todo heap. :)

>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>> is configured in, even when you're then going to overmount it with
>> something else like you're doing, let's just _remove_ the test. If it
>> can be tmpfs, have it be tmpfs.
> 
> Very much appreciated!

Not yet tested, but something like the attached? (Sorry for the
half-finished doc changes in there, I'm at work and have a 5 minute
break. I can test properly this evening if you don't get to it...)

Rob

[-- Attachment #2: initmpfs.patch --]
[-- Type: text/x-patch, Size: 6310 bytes --]

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b98048b..a5b44b2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3771,8 +3771,14 @@
 			debug-uart get routed to the D+ and D- pins of the usb
 			port and the regular usb controller gets disabled.
 
-	root=		[KNL] Root filesystem
-			See name_to_dev_t comment in init/do_mounts.c.
+	root=		[KNL] Fallback root filesystem when not using initramfs
+			If initramfs contains an /init file to run as PID 1 the
+			kernel ignores this setting. When initramfs doesn't have
+			/init (or whatever rdinit= points to) the kernel calls
+			prepare_namespace() in init/do_mounts.c to mount another
+			filesystem over / and chroot into it, then looks for
+			/sbin/init in there. (And /etc/init, /bin/init, and
+			/bin/sh for historical reasons.)
 
 	rootdelay=	[KNL] Delay (in seconds) to pause before attempting to
 			mount the root filesystem
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
index b176928..f3c57ba 100644
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@@ -67,6 +67,10 @@ A ramfs derivative called tmpfs was created to add size limits, and the ability
 to write the data to swap space.  Normal users can be allowed write access to
 tmpfs mounts.  See Documentation/filesystems/tmpfs.txt for more information.
 
+The kernel uses tmpfs for ramfs when CONFIG_TMPFS=y and no "root=" is
+specified in the kernel command line. If you can't stop yourself from
+specifying root= you can also use "root=tmpfs".
+
 What is rootfs?
 ---------------
 
@@ -236,22 +240,10 @@ An initramfs archive is a complete self-contained root filesystem for Linux.
 If you don't already understand what shared libraries, devices, and paths
 you need to get a minimal root filesystem up and running, here are some
 references:
-http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
-http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
-http://www.linuxfromscratch.org/lfs/view/stable/
-
-The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is
-designed to be a tiny C library to statically link early userspace
-code against, along with some related utilities.  It is BSD licensed.
 
-I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
-myself.  These are LGPL and GPL, respectively.  (A self-contained initramfs
-package is planned for the busybox 1.3 release.)
-
-In theory you could use glibc, but that's not well suited for small embedded
-uses like this.  (A "hello world" program statically linked against glibc is
-over 400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to do
-name lookups, even when otherwise statically linked.)
+  http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
+  http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
+  http://www.linuxfromscratch.org/lfs/view/stable/
 
 A good first step is to get initramfs to run a statically linked "hello world"
 program as init, and test it under an emulator like qemu (www.qemu.org) or
@@ -264,11 +256,12 @@ User Mode Linux, like so:
   int main(int argc, char *argv[])
   {
     printf("Hello world!\n");
-    sleep(999999999);
+    sleep(999999999); // because if PID 1 exits the kernel panics
   }
   EOF
   gcc -static hello.c -o init
   echo init | cpio -o -H newc | gzip > test.cpio.gz
+
   # Testing external initramfs using the initrd loading mechanism.
   qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero
 
@@ -330,30 +323,3 @@ the above threads) is:
       http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
 
    and, most importantly, designed and implemented the initramfs code.
-
-Future directions:
-------------------
-
-Today (2.6.16), initramfs is always compiled in, but not always used.  The
-kernel falls back to legacy boot code that is reached only if initramfs does
-not contain an /init program.  The fallback is legacy code, there to ensure a
-smooth transition and allowing early boot functionality to gradually move to
-"early userspace" (I.E. initramfs).
-
-The move to early userspace is necessary because finding and mounting the real
-root device is complex.  Root partitions can span multiple devices (raid or
-separate journal).  They can be out on the network (requiring dhcp, setting a
-specific MAC address, logging into a server, etc).  They can live on removable
-media, with dynamically allocated major/minor numbers and persistent naming
-issues requiring a full udev implementation to sort out.  They can be
-compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
-and so on.
-
-This kind of complexity (which inevitably includes policy) is rightly handled
-in userspace.  Both klibc and busybox/uClibc are working on simple initramfs
-packages to drop into a kernel build.
-
-The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
-The kernel's current early boot code (partition detection, etc) will probably
-be migrated into a default initramfs, automatically created and used by the
-kernel build.
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6d..62232f3 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -603,7 +603,6 @@ void __init prepare_namespace(void)
 	sys_chroot(".");
 }
 
-static bool is_tmpfs;
 static struct dentry *rootfs_mount(struct file_system_type *fs_type,
 	int flags, const char *dev_name, void *data)
 {
@@ -613,7 +612,7 @@ static struct dentry *rootfs_mount(struct file_system_type *fs_type,
 	if (test_and_set_bit(0, &once))
 		return ERR_PTR(-ENODEV);
 
-	if (IS_ENABLED(CONFIG_TMPFS) && is_tmpfs)
+	if (IS_ENABLED(CONFIG_TMPFS))
 		fill = shmem_fill_super;
 
 	return mount_nodev(fs_type, flags, data, fill);
@@ -632,13 +631,7 @@ int __init init_rootfs(void)
 	if (err)
 		return err;
 
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
-		err = shmem_init();
-		is_tmpfs = true;
-	} else {
-		err = init_ramfs_fs();
-	}
+	err = IS_ENABLED(CONFIG_TMPFS) ? shmem_init() : init_ramfs_fs();
 
 	if (err)
 		unregister_filesystem(&rootfs_fs_type);

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > 
> >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> >>>
> >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> >>> dracut: refusing to continue
> >>
> >> [googles]... I do not understand why this package exists.
> >>
> >> If you're switching to another root filesystem, using a tool that
> >> wikipedia[citation needed] says has no purpose but to switch to another
> >> root filesystem, (so let's reproduce the kernel infrastructure in
> >> userspace while leaving it the kernel too)... why do you need initramfs
> >> to be tmpfs? You're using it for half a second, then discarding it,
> >> what's the point of it being tmpfs?
> > 
> > Unlike the kernel image which is signed by the distros, the initramfs
> > doesn't come signed, because it is built on the target system.  Even
> > if the initramfs did come signed, it is beneficial to measure and
> > appraise the individual files in the initramfs.
> 
> You can still shoot yourself in the foot with tmpfs. People mount a /run
> and a /tmp and then as a normal user you can go
> https://twitter.com/landley/status/959103235305951233 and maybe the
> default should be a little more clever there...
> 
> I'll throw it on the todo heap. :)
> 
> >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> >> is configured in, even when you're then going to overmount it with
> >> something else like you're doing, let's just _remove_ the test. If it
> >> can be tmpfs, have it be tmpfs.
> > 
> > Very much appreciated!
> 
> Not yet tested, but something like the attached? (Sorry for the
> half-finished doc changes in there, I'm at work and have a 5 minute
> break. I can test properly this evening if you don't get to it...)

Yes, rootfs is being mounted as tmpfs.

Mimi

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > 
> >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> >>>
> >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> >>> dracut: refusing to continue
> >>
> >> [googles]... I do not understand why this package exists.
> >>
> >> If you're switching to another root filesystem, using a tool that
> >> wikipedia[citation needed] says has no purpose but to switch to another
> >> root filesystem, (so let's reproduce the kernel infrastructure in
> >> userspace while leaving it the kernel too)... why do you need initramfs
> >> to be tmpfs? You're using it for half a second, then discarding it,
> >> what's the point of it being tmpfs?
> > 
> > Unlike the kernel image which is signed by the distros, the initramfs
> > doesn't come signed, because it is built on the target system. ?Even
> > if the initramfs did come signed, it is beneficial to measure and
> > appraise the individual files in the initramfs.
> 
> You can still shoot yourself in the foot with tmpfs. People mount a /run
> and a /tmp and then as a normal user you can go
> https://twitter.com/landley/status/959103235305951233 and maybe the
> default should be a little more clever there...
> 
> I'll throw it on the todo heap. :)
> 
> >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> >> is configured in, even when you're then going to overmount it with
> >> something else like you're doing, let's just _remove_ the test. If it
> >> can be tmpfs, have it be tmpfs.
> > 
> > Very much appreciated!
> 
> Not yet tested, but something like the attached? (Sorry for the
> half-finished doc changes in there, I'm at work and have a 5 minute
> break. I can test properly this evening if you don't get to it...)

Yes, rootfs is being mounted as tmpfs.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > 
> >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> >>>
> >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> >>> dracut: refusing to continue
> >>
> >> [googles]... I do not understand why this package exists.
> >>
> >> If you're switching to another root filesystem, using a tool that
> >> wikipedia[citation needed] says has no purpose but to switch to another
> >> root filesystem, (so let's reproduce the kernel infrastructure in
> >> userspace while leaving it the kernel too)... why do you need initramfs
> >> to be tmpfs? You're using it for half a second, then discarding it,
> >> what's the point of it being tmpfs?
> > 
> > Unlike the kernel image which is signed by the distros, the initramfs
> > doesn't come signed, because it is built on the target system.  Even
> > if the initramfs did come signed, it is beneficial to measure and
> > appraise the individual files in the initramfs.
> 
> You can still shoot yourself in the foot with tmpfs. People mount a /run
> and a /tmp and then as a normal user you can go
> https://twitter.com/landley/status/959103235305951233 and maybe the
> default should be a little more clever there...
> 
> I'll throw it on the todo heap. :)
> 
> >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> >> is configured in, even when you're then going to overmount it with
> >> something else like you're doing, let's just _remove_ the test. If it
> >> can be tmpfs, have it be tmpfs.
> > 
> > Very much appreciated!
> 
> Not yet tested, but something like the attached? (Sorry for the
> half-finished doc changes in there, I'm at work and have a 5 minute
> break. I can test properly this evening if you don't get to it...)

Yes, rootfs is being mounted as tmpfs.

Mimi

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Taras Kondratiuk]

Quoting Mimi Zohar (2018-02-01 13:51:52)
> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> > On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > > 
> > >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> > >>>
> > >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > >>> dracut: refusing to continue
> > >>
> > >> [googles]... I do not understand why this package exists.
> > >>
> > >> If you're switching to another root filesystem, using a tool that
> > >> wikipedia[citation needed] says has no purpose but to switch to another
> > >> root filesystem, (so let's reproduce the kernel infrastructure in
> > >> userspace while leaving it the kernel too)... why do you need initramfs
> > >> to be tmpfs? You're using it for half a second, then discarding it,
> > >> what's the point of it being tmpfs?
> > > 
> > > Unlike the kernel image which is signed by the distros, the initramfs
> > > doesn't come signed, because it is built on the target system.  Even
> > > if the initramfs did come signed, it is beneficial to measure and
> > > appraise the individual files in the initramfs.
> > 
> > You can still shoot yourself in the foot with tmpfs. People mount a /run
> > and a /tmp and then as a normal user you can go
> > https://twitter.com/landley/status/959103235305951233 and maybe the
> > default should be a little more clever there...
> > 
> > I'll throw it on the todo heap. :)
> > 
> > >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> > >> is configured in, even when you're then going to overmount it with
> > >> something else like you're doing, let's just _remove_ the test. If it
> > >> can be tmpfs, have it be tmpfs.
> > > 
> > > Very much appreciated!
> > 
> > Not yet tested, but something like the attached? (Sorry for the
> > half-finished doc changes in there, I'm at work and have a 5 minute
> > break. I can test properly this evening if you don't get to it...)
> 
> Yes, rootfs is being mounted as tmpfs.

I don't think you can unconditionally replace ramfs with initramfs by
default. Their behavior is different in some cases (e.g. pivot_root vs
switch_root) and it can break many systems that expect ramfs by default.

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Taras Kondratiuk]

Quoting Mimi Zohar (2018-02-01 13:51:52)
> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> > On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > > 
> > >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> > >>>
> > >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > >>> dracut: refusing to continue
> > >>
> > >> [googles]... I do not understand why this package exists.
> > >>
> > >> If you're switching to another root filesystem, using a tool that
> > >> wikipedia[citation needed] says has no purpose but to switch to another
> > >> root filesystem, (so let's reproduce the kernel infrastructure in
> > >> userspace while leaving it the kernel too)... why do you need initramfs
> > >> to be tmpfs? You're using it for half a second, then discarding it,
> > >> what's the point of it being tmpfs?
> > > 
> > > Unlike the kernel image which is signed by the distros, the initramfs
> > > doesn't come signed, because it is built on the target system. ?Even
> > > if the initramfs did come signed, it is beneficial to measure and
> > > appraise the individual files in the initramfs.
> > 
> > You can still shoot yourself in the foot with tmpfs. People mount a /run
> > and a /tmp and then as a normal user you can go
> > https://twitter.com/landley/status/959103235305951233 and maybe the
> > default should be a little more clever there...
> > 
> > I'll throw it on the todo heap. :)
> > 
> > >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> > >> is configured in, even when you're then going to overmount it with
> > >> something else like you're doing, let's just _remove_ the test. If it
> > >> can be tmpfs, have it be tmpfs.
> > > 
> > > Very much appreciated!
> > 
> > Not yet tested, but something like the attached? (Sorry for the
> > half-finished doc changes in there, I'm at work and have a 5 minute
> > break. I can test properly this evening if you don't get to it...)
> 
> Yes, rootfs is being mounted as tmpfs.

I don't think you can unconditionally replace ramfs with initramfs by
default. Their behavior is different in some cases (e.g. pivot_root vs
switch_root) and it can break many systems that expect ramfs by default.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Taras Kondratiuk]

Quoting Mimi Zohar (2018-02-01 13:51:52)
> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> > On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> > > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> > > 
> > >>> With your patch and specifying "root=tmpfs", dracut is complaining:
> > >>>
> > >>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> > >>> dracut: refusing to continue
> > >>
> > >> [googles]... I do not understand why this package exists.
> > >>
> > >> If you're switching to another root filesystem, using a tool that
> > >> wikipedia[citation needed] says has no purpose but to switch to another
> > >> root filesystem, (so let's reproduce the kernel infrastructure in
> > >> userspace while leaving it the kernel too)... why do you need initramfs
> > >> to be tmpfs? You're using it for half a second, then discarding it,
> > >> what's the point of it being tmpfs?
> > > 
> > > Unlike the kernel image which is signed by the distros, the initramfs
> > > doesn't come signed, because it is built on the target system.  Even
> > > if the initramfs did come signed, it is beneficial to measure and
> > > appraise the individual files in the initramfs.
> > 
> > You can still shoot yourself in the foot with tmpfs. People mount a /run
> > and a /tmp and then as a normal user you can go
> > https://twitter.com/landley/status/959103235305951233 and maybe the
> > default should be a little more clever there...
> > 
> > I'll throw it on the todo heap. :)
> > 
> > >> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> > >> is configured in, even when you're then going to overmount it with
> > >> something else like you're doing, let's just _remove_ the test. If it
> > >> can be tmpfs, have it be tmpfs.
> > > 
> > > Very much appreciated!
> > 
> > Not yet tested, but something like the attached? (Sorry for the
> > half-finished doc changes in there, I'm at work and have a 5 minute
> > break. I can test properly this evening if you don't get to it...)
> 
> Yes, rootfs is being mounted as tmpfs.

I don't think you can unconditionally replace ramfs with initramfs by
default. Their behavior is different in some cases (e.g. pivot_root vs
switch_root) and it can break many systems that expect ramfs by default.

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something.  Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?
> 
> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

"The kernel can't break this buggy userspace package."

"The kernel must give access to a new feature to this buggy userspace
package".

I think kernel policy asks you to pick one, but I could be wrong...

Rob

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something. ?Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?
> 
> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

"The kernel can't break this buggy userspace package."

"The kernel must give access to a new feature to this buggy userspace
package".

I think kernel policy asks you to pick one, but I could be wrong...

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 01/31/2018 10:22 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote:
>> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote:
>>> On 01/31/2018 04:07 PM, Mimi Zohar wrote:
>>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that
>>> rootfs
>>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>>>>> it?)
>>>>
>>>> I must be missing something.  Which systems don't specify "root=" on
>>>> the boot command line.
>>>
>>> Any system using initrd or initramfs?
>>>
>>
>> Don't a lot of initramfs setups use root= to tell the initramfs which
>> actual root file system to switch to after early boot?
> 
> With your patch and specifying "root=tmpfs", dracut is complaining:
> 
> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> dracut: refusing to continue

"The kernel can't break this buggy userspace package."

"The kernel must give access to a new feature to this buggy userspace
package".

I think kernel policy asks you to pick one, but I could be wrong...

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 02/01/2018 04:41 PM, Taras Kondratiuk wrote:
> Quoting Mimi Zohar (2018-02-01 13:51:52)
>> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
>>> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
>>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
>>>>
>>>>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>>>>
>>>>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>>>>> dracut: refusing to continue
>>>>>
>>>>> [googles]... I do not understand why this package exists.
>>>>>
>>>>> If you're switching to another root filesystem, using a tool that
>>>>> wikipedia[citation needed] says has no purpose but to switch to another
>>>>> root filesystem, (so let's reproduce the kernel infrastructure in
>>>>> userspace while leaving it the kernel too)... why do you need initramfs
>>>>> to be tmpfs? You're using it for half a second, then discarding it,
>>>>> what's the point of it being tmpfs?
>>>>
>>>> Unlike the kernel image which is signed by the distros, the initramfs
>>>> doesn't come signed, because it is built on the target system.  Even
>>>> if the initramfs did come signed, it is beneficial to measure and
>>>> appraise the individual files in the initramfs.
>>>
>>> You can still shoot yourself in the foot with tmpfs. People mount a /run
>>> and a /tmp and then as a normal user you can go
>>> https://twitter.com/landley/status/959103235305951233 and maybe the
>>> default should be a little more clever there...
>>>
>>> I'll throw it on the todo heap. :)
>>>
>>>>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>>>>> is configured in, even when you're then going to overmount it with
>>>>> something else like you're doing, let's just _remove_ the test. If it
>>>>> can be tmpfs, have it be tmpfs.
>>>>
>>>> Very much appreciated!
>>>
>>> Not yet tested, but something like the attached? (Sorry for the
>>> half-finished doc changes in there, I'm at work and have a 5 minute
>>> break. I can test properly this evening if you don't get to it...)
>>
>> Yes, rootfs is being mounted as tmpfs.
> 
> I don't think you can unconditionally replace ramfs with initramfs by
> default. Their behavior is different in some cases (e.g. pivot_root vs
> switch_root)

Both are switch_root, you can't pivot_root off of either one. (Yes, I
hit that bug and reported it, and they fixed it, back in the day...
http://lists.busybox.net/pipermail/busybox/2006-March/053529.html )

> and it can break many systems that expect ramfs by default.

The use case I told Mimi about off-list (since they stopped cc:ing the
list in one of their replies but the conversation continued) was the guy
who was extracting an initramfs bigger than 50% of system memory, which
worked with initramfs but failed with initmpfs. A quick google didn't
find the original message but it resulted in this blog entry from the
affected party:

http://www.lightofdawn.org/blog/?viewDetailed=00128

I.E. yeah, I know, I need to redo these patches tonight.

Rob

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 02/01/2018 04:41 PM, Taras Kondratiuk wrote:
> Quoting Mimi Zohar (2018-02-01 13:51:52)
>> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
>>> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
>>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
>>>>
>>>>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>>>>
>>>>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>>>>> dracut: refusing to continue
>>>>>
>>>>> [googles]... I do not understand why this package exists.
>>>>>
>>>>> If you're switching to another root filesystem, using a tool that
>>>>> wikipedia[citation needed] says has no purpose but to switch to another
>>>>> root filesystem, (so let's reproduce the kernel infrastructure in
>>>>> userspace while leaving it the kernel too)... why do you need initramfs
>>>>> to be tmpfs? You're using it for half a second, then discarding it,
>>>>> what's the point of it being tmpfs?
>>>>
>>>> Unlike the kernel image which is signed by the distros, the initramfs
>>>> doesn't come signed, because it is built on the target system. ?Even
>>>> if the initramfs did come signed, it is beneficial to measure and
>>>> appraise the individual files in the initramfs.
>>>
>>> You can still shoot yourself in the foot with tmpfs. People mount a /run
>>> and a /tmp and then as a normal user you can go
>>> https://twitter.com/landley/status/959103235305951233 and maybe the
>>> default should be a little more clever there...
>>>
>>> I'll throw it on the todo heap. :)
>>>
>>>>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>>>>> is configured in, even when you're then going to overmount it with
>>>>> something else like you're doing, let's just _remove_ the test. If it
>>>>> can be tmpfs, have it be tmpfs.
>>>>
>>>> Very much appreciated!
>>>
>>> Not yet tested, but something like the attached? (Sorry for the
>>> half-finished doc changes in there, I'm at work and have a 5 minute
>>> break. I can test properly this evening if you don't get to it...)
>>
>> Yes, rootfs is being mounted as tmpfs.
> 
> I don't think you can unconditionally replace ramfs with initramfs by
> default. Their behavior is different in some cases (e.g. pivot_root vs
> switch_root)

Both are switch_root, you can't pivot_root off of either one. (Yes, I
hit that bug and reported it, and they fixed it, back in the day...
http://lists.busybox.net/pipermail/busybox/2006-March/053529.html )

> and it can break many systems that expect ramfs by default.

The use case I told Mimi about off-list (since they stopped cc:ing the
list in one of their replies but the conversation continued) was the guy
who was extracting an initramfs bigger than 50% of system memory, which
worked with initramfs but failed with initmpfs. A quick google didn't
find the original message but it resulted in this blog entry from the
affected party:

http://www.lightofdawn.org/blog/?viewDetailed=00128

I.E. yeah, I know, I need to redo these patches tonight.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Rob Landley]

On 02/01/2018 04:41 PM, Taras Kondratiuk wrote:
> Quoting Mimi Zohar (2018-02-01 13:51:52)
>> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
>>> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
>>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
>>>>
>>>>>> With your patch and specifying "root=tmpfs", dracut is complaining:
>>>>>>
>>>>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
>>>>>> dracut: refusing to continue
>>>>>
>>>>> [googles]... I do not understand why this package exists.
>>>>>
>>>>> If you're switching to another root filesystem, using a tool that
>>>>> wikipedia[citation needed] says has no purpose but to switch to another
>>>>> root filesystem, (so let's reproduce the kernel infrastructure in
>>>>> userspace while leaving it the kernel too)... why do you need initramfs
>>>>> to be tmpfs? You're using it for half a second, then discarding it,
>>>>> what's the point of it being tmpfs?
>>>>
>>>> Unlike the kernel image which is signed by the distros, the initramfs
>>>> doesn't come signed, because it is built on the target system.  Even
>>>> if the initramfs did come signed, it is beneficial to measure and
>>>> appraise the individual files in the initramfs.
>>>
>>> You can still shoot yourself in the foot with tmpfs. People mount a /run
>>> and a /tmp and then as a normal user you can go
>>> https://twitter.com/landley/status/959103235305951233 and maybe the
>>> default should be a little more clever there...
>>>
>>> I'll throw it on the todo heap. :)
>>>
>>>>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
>>>>> is configured in, even when you're then going to overmount it with
>>>>> something else like you're doing, let's just _remove_ the test. If it
>>>>> can be tmpfs, have it be tmpfs.
>>>>
>>>> Very much appreciated!
>>>
>>> Not yet tested, but something like the attached? (Sorry for the
>>> half-finished doc changes in there, I'm at work and have a 5 minute
>>> break. I can test properly this evening if you don't get to it...)
>>
>> Yes, rootfs is being mounted as tmpfs.
> 
> I don't think you can unconditionally replace ramfs with initramfs by
> default. Their behavior is different in some cases (e.g. pivot_root vs
> switch_root)

Both are switch_root, you can't pivot_root off of either one. (Yes, I
hit that bug and reported it, and they fixed it, back in the day...
http://lists.busybox.net/pipermail/busybox/2006-March/053529.html )

> and it can break many systems that expect ramfs by default.

The use case I told Mimi about off-list (since they stopped cc:ing the
list in one of their replies but the conversation continued) was the guy
who was extracting an initramfs bigger than 50% of system memory, which
worked with initramfs but failed with initmpfs. A quick google didn't
find the original message but it resulted in this blog entry from the
affected party:

http://www.lightofdawn.org/blog/?viewDetailed=00128

I.E. yeah, I know, I need to redo these patches tonight.

Rob

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

Hi Rob,

On Thu, 2018-02-01 at 17:34 -0600, Rob Landley wrote:
> 
> On 02/01/2018 04:41 PM, Taras Kondratiuk wrote:
> > Quoting Mimi Zohar (2018-02-01 13:51:52)
> >> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> >>> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> >>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> >>>>
> >>>>>> With your patch and specifying "root=tmpfs", dracut is complaining:
> >>>>>>
> >>>>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> >>>>>> dracut: refusing to continue
> >>>>>
> >>>>> [googles]... I do not understand why this package exists.
> >>>>>
> >>>>> If you're switching to another root filesystem, using a tool that
> >>>>> wikipedia[citation needed] says has no purpose but to switch to another
> >>>>> root filesystem, (so let's reproduce the kernel infrastructure in
> >>>>> userspace while leaving it the kernel too)... why do you need initramfs
> >>>>> to be tmpfs? You're using it for half a second, then discarding it,
> >>>>> what's the point of it being tmpfs?
> >>>>
> >>>> Unlike the kernel image which is signed by the distros, the initramfs
> >>>> doesn't come signed, because it is built on the target system.  Even
> >>>> if the initramfs did come signed, it is beneficial to measure and
> >>>> appraise the individual files in the initramfs.
> >>>
> >>> You can still shoot yourself in the foot with tmpfs. People mount a /run
> >>> and a /tmp and then as a normal user you can go
> >>> https://twitter.com/landley/status/959103235305951233 and maybe the
> >>> default should be a little more clever there...
> >>>
> >>> I'll throw it on the todo heap. :)
> >>>
> >>>>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> >>>>> is configured in, even when you're then going to overmount it with
> >>>>> something else like you're doing, let's just _remove_ the test. If it
> >>>>> can be tmpfs, have it be tmpfs.
> >>>>
> >>>> Very much appreciated!
> >>>
> >>> Not yet tested, but something like the attached? (Sorry for the
> >>> half-finished doc changes in there, I'm at work and have a 5 minute
> >>> break. I can test properly this evening if you don't get to it...)
> >>
> >> Yes, rootfs is being mounted as tmpfs.
> > 
> > I don't think you can unconditionally replace ramfs with initramfs by
> > default. Their behavior is different in some cases (e.g. pivot_root vs
> > switch_root)
> 
> Both are switch_root, you can't pivot_root off of either one. (Yes, I
> hit that bug and reported it, and they fixed it, back in the day...
> http://lists.busybox.net/pipermail/busybox/2006-March/053529.html )
> 
> > and it can break many systems that expect ramfs by default.
> 
> The use case I told Mimi about off-list (since they stopped cc:ing the
> list in one of their replies but the conversation continued) was the guy
> who was extracting an initramfs bigger than 50% of system memory, which
> worked with initramfs but failed with initmpfs. A quick google didn't
> find the original message but it resulted in this blog entry from the
> affected party:
> 
> http://www.lightofdawn.org/blog/?viewDetailed=00128
> 
> I.E. yeah, I know, I need to redo these patches tonight.

I'd really like to be able to have rootfs be a tmpfs filesystem.  Any
time estimate on this patch?

thanks!

Mimi

[RFC PATCH] rootfs: force mounting rootfs as tmpfs

[Mimi Zohar]

Hi Rob,

On Thu, 2018-02-01 at 17:34 -0600, Rob Landley wrote:
> 
> On 02/01/2018 04:41 PM, Taras Kondratiuk wrote:
> > Quoting Mimi Zohar (2018-02-01 13:51:52)
> >> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote:
> >>> On 02/01/2018 09:55 AM, Mimi Zohar wrote:
> >>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote:
> >>>>
> >>>>>> With your patch and specifying "root=tmpfs", dracut is complaining:
> >>>>>>
> >>>>>> dracut: FATAL: Don't know how to handle 'root=tmpfs'
> >>>>>> dracut: refusing to continue
> >>>>>
> >>>>> [googles]... I do not understand why this package exists.
> >>>>>
> >>>>> If you're switching to another root filesystem, using a tool that
> >>>>> wikipedia[citation needed] says has no purpose but to switch to another
> >>>>> root filesystem, (so let's reproduce the kernel infrastructure in
> >>>>> userspace while leaving it the kernel too)... why do you need initramfs
> >>>>> to be tmpfs? You're using it for half a second, then discarding it,
> >>>>> what's the point of it being tmpfs?
> >>>>
> >>>> Unlike the kernel image which is signed by the distros, the initramfs
> >>>> doesn't come signed, because it is built on the target system. ?Even
> >>>> if the initramfs did come signed, it is beneficial to measure and
> >>>> appraise the individual files in the initramfs.
> >>>
> >>> You can still shoot yourself in the foot with tmpfs. People mount a /run
> >>> and a /tmp and then as a normal user you can go
> >>> https://twitter.com/landley/status/959103235305951233 and maybe the
> >>> default should be a little more clever there...
> >>>
> >>> I'll throw it on the todo heap. :)
> >>>
> >>>>> Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs
> >>>>> is configured in, even when you're then going to overmount it with
> >>>>> something else like you're doing, let's just _remove_ the test. If it
> >>>>> can be tmpfs, have it be tmpfs.
> >>>>
> >>>> Very much appreciated!
> >>>
> >>> Not yet tested, but something like the attached? (Sorry for the
> >>> half-finished doc changes in there, I'm at work and have a 5 minute
> >>> break. I can test properly this evening if you don't get to it...)
> >>
> >> Yes, rootfs is being mounted as tmpfs.
> > 
> > I don't think you can unconditionally replace ramfs with initramfs by
> > default. Their behavior is different in some cases (e.g. pivot_root vs
> > switch_root)
> 
> Both are switch_root, you can't pivot_root off of either one. (Yes, I
> hit that bug and reported it, and they fixed it, back in the day...
> http://lists.busybox.net/pipermail/busybox/2006-March/053529.html )
> 
> > and it can break many systems that expect ramfs by default.
> 
> The use case I told Mimi about off-list (since they stopped cc:ing the
> list in one of their replies but the conversation continued) was the guy
> who was extracting an initramfs bigger than 50% of system memory, which
> worked with initramfs but failed with initmpfs. A quick google didn't
> find the original message but it resulted in this blog entry from the
> affected party:
> 
> http://www.lightofdawn.org/blog/?viewDetailed=00128
> 
> I.E. yeah, I know, I need to redo these patches tonight.

I'd really like to be able to have rootfs be a tmpfs filesystem. ?Any
time estimate on this patch?

thanks!

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html