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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1604499

Title:
  include loopback and squash4 modules in EFI binary

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to