[bug #57652] minix filesystem detection too optimistic

[Stefan Seyfried]

URL:
  <https://savannah.gnu.org/bugs/?57652>

                 Summary: minix filesystem detection too optimistic
                 Project: GNU GRUB
            Submitted by: seife
            Submitted on: Wed 22 Jan 2020 08:24:04 AM UTC
                Category: Filesystem
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 
                 Release: 2.02
         Reproducibility: Every Time
         Planned Release: None

    _______________________________________________________

Details:

I encountered an intermittent issue where grub-install would fail with "not a
directory" error after trying minix_be detection:

grub-core/kern/fs.c:79: nilfs2 detection failed.
grub-core/kern/fs.c:57: Detecting newc...
grub-core/kern/fs.c:79: newc detection failed.
grub-core/kern/fs.c:57: Detecting minix_be...
grub-core/osdep/hostdisk.c:408: reusing open device `/dev/loop0'
grub-core/kern/fs.c:79: minix_be detection failed.
grub2-install: error: not a directory.

The reason for this (I found this after days of debugging...) is, that the
minix filesystem detection in grub-core/fs/minix.c:grub_minix_mount() is
overly optimistic. It just checks for the FS magic number and sanity-checks
some other size fields, then decides "this is minix".

The problem is, that grub_fs_probe calls the dir() function of every file
system as

   dir(device, "/", ...)

and if this does not return an error other than GRUB_ERR_BAD_FS, then this is
considered fatal.

Now the grub_minix_dir(.., path, ...) function (which is dir() for minix) does
the following (pseudocode):

  grub_minix_mount() || return GRUB_ERR_BAD_FS # this is the detection if it
is a minix fs
  ...
  data = grub_minix_find_file(path) || return grub_errno
  if (MODE(data) != ISDIR)
     return "not a directory"

if grub_minix_mount would have failed, this would be a non-fatal error, but it
only fails afterwards when checking if "/" is a directory, which is then
considered fatal, and causes grub-install to abort with the strange (if you do
not know all the circumstances :-) "not a directory" message.

Now how can the MINIX FS magic number appear?

The answer is easy: the on-disk location of grub_minix_sblock.magic is the
same as the on-disk location of grub_ext2_sblock.free_inodes, so if you happen
to install grub onto a file system with a matching number of free inodes, you
can trigger this reliably. Any you'll never guess what the problem is ;-)

I wrote about this with more hints and a workaorund on
https://seifesrants.blogspot.com/2020/01/fun-with-grub2-install.html 

The attached patch fixes the issue for me.
It is not ready for inclusion and includes some additional debug code, which
of course can be omitted.

What it does is put the additional steps that "dir('/')" does directly into
the grub_minix_mount() code, and only return successfully if this succeeds and
finds that "/" actually is a directory.

In the long run, it would be beneficial if grub-install got an option to
specify "--filesystems=ext2,xfs,btrfs" to skip probing for unrelated
filesystems. I'm quite sure there are more possibilities to get this
autodetection wrong for different filesystem types.

I'll try to craft a script to reproduce this easily.

Note that I have encountered and debugged this on a SUSE Linux Enterprise
Server 15 SP1 code base. However, I checked the current git masterand the
minix fs code is identical, so I'm pretty sure the problem is still present in
the current code base.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 22 Jan 2020 08:24:04 AM UTC  Name: grub2-minix-probe-fix.diff  Size:
4KiB   By: seife
POC fix (with debug code)
<http://savannah.gnu.org/bugs/download.php?file_id=48271>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57652>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/