[Bug 1604499] Re: include loopback and squash4 modules in EFI binary

[Steve Langasek]

Thanks for the review, Seth.

> There may be data format mismatches between grub2 and the linux kernel's
> idea of squashfs:

> These are the structures from grub2 for file and long_file:
> grub_uint32_t block_size[0];

> These are the structures from the linux kernel for squashfs_reg_inode and
> squashfs_lreg_inode:
> __le16 block_list[0];

I wasn't sure if you were raising this as a possible security issue or
not.  I'm also not clear what an array of 0 elements is supposed to do
here.  But you were comparing this with the Linux kernel headers, and
the Linux kernel never writes squashfs, it only reads it... which means
the inconsistency could be a bug in Linux rather than grub.

Here's what squashfs-tools has to say:

struct squashfs_reg_inode_header {
        unsigned short          inode_type;
        unsigned short          mode;
        unsigned short          uid;
        unsigned short          guid;
        int                     mtime;
        unsigned int            inode_number;
        unsigned int            start_block;
        unsigned int            fragment;
        unsigned int            offset;
        unsigned int            file_size;
        unsigned int            block_list[0];
};

struct squashfs_lreg_inode_header {
        unsigned short          inode_type;
        unsigned short          mode;
        unsigned short          uid;
        unsigned short          guid;
        int                     mtime;
        unsigned int            inode_number;
        squashfs_block          start_block;
        long long               file_size;
        long long               sparse;
        unsigned int            nlink;
        unsigned int            fragment;
        unsigned int            offset;
        unsigned int            xattr;
        unsigned int            block_list[0];
};

This shows a 32-bit int for the block_list, which matches grub rather
than the kernel.  So it doesn't look like this is going to cause
corruption due to a long read with a genuine squashfs.  And anyway,
grub's handling of the block_size field seems well-guarded to me.  Based
on this, I conclude that there are no blockers here for secureboot
signing of this code.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1604499

Title:
  include loopback and squash4 modules in EFI binary

Status in grub2 package in Ubuntu:
  New
Status in grub2 source package in Xenial:
  New

Bug description:
  Development versions of snappy Ubuntu Core leverage grub's squashfs
  support to load kernels and initramfs directly from the kernel snap
  (which is a squashfs-format archive).  This requires the loopback and
  the squash4 grub modules to be loaded.

  Currently, neither of these modules is included in the signed EFI
  binaries, therefore this boot strategy is not compatible with
  SecureBoot.

  We should verify that the loopback and squash4 modules are suitable
  for inclusion in the signed binary, and include them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1604499/+subscriptions