On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote:
>
> On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote:
> >> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >>>>>
> >>>>> Are you using an initrd not an initramfs? According to
> >>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> >>>> CONFIG_TMPFS
> >>>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
> >>>>>
> >>>> Yes, that what I thought too, but it seems that it is not really the
> >>>> case because of this test:
> >>>>
> >>>> 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();
> >>>> }
> >>>
> >>> [CC'ing Rob Landley, lsm, lkml]
> >>>
> >>> Thanks! "saved_root_name" is set to the boot command line "root="
> >>> option, which in my case is the UUID. I'm not sure why real root should
> >>> impact the initramfs tmpfs/ramfs decision.
> >>>
> >>> Unless there is a good explanation, did you want to post a patch to
> >>> remove the test?
> >>
> >> I added support last year, here's the start of the patch series:
> >>
> >> https://lkml.org/lkml/2013/6/29/101
> >>
> >> The logic is that if you specify a fallback root via root=, then you're
> >> not staying on rootfs (that's what root= _means_, "here is the root
> >> filesystem the kernel is to mount over rootfs"), and thus the extra
> >> infrastructure for tmpfs instead of ramfs is unnecessary.
> >
> > Thanks Rob for the explanation. The problem is that ramfs does not
> > support extended attributes, while tmpfs does.
>
> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.
The menu entry looks like:
linux /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f
ro ...
initrd /initramfs-3.17.0+.img
Because "root=" is specified, rootfs is not using tmpfs.
> > The boot loader could
> > "measure" (trusted boot) the initramfs, but as the initramfs is
> > generated on the target system, the initramfs is not signed, preventing
> > it from being appraised (secure Boot). To close the initramfs integrity
> > appraisal gap requires verifying the individual initramfs file
> > signatures, which are stored as extended attributes.
>
> Faced with the phrases "trusted boot" and "integrity appraisal", I plead
> the third.
Fine. Bottom line, rootfs needs to support extended attributes.
> (In the wake of the Snowden infodump,
All the more reason to allow only those files that are properly signed
to be read/executed.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
