All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Remove HFS support
@ 2022-08-19 13:38 Daniel Axtens
  2022-08-19 13:57 ` Daniel Kiper
  0 siblings, 1 reply; 26+ messages in thread
From: Daniel Axtens @ 2022-08-19 13:38 UTC (permalink / raw)
  To: grub-devel; +Cc: Daniel Axtens

HFS is so so very old now. According to Wikipedia, HFS was
introduced in 1985 and the successor HFS+ came out in January
1998. Mac OS dropped support for writing HFS in 2009 and dropped
support for reading HFS in 2019 with macOS 10.15.

Grub's support for it doesn't survive contact with a fuzzer, and
the issues involve some horrible mess of mutual recursion that
would be time-consuming to sort out.

HFS has been disabled under lockdown since commit 1c15848838d9
("fs/hfs: Disable under lockdown") which was part of an earlier
spin of security fixes.

I think it's time to consign HFS to the dustbin of history. It's
firmly in the category of retrocomputing at this stage.

This should not affect HFS+.

There's a little bit of mess remaining: the macbless runtime
command and HFS+ need the HFS headers for embedded volume support.
I don't think that's really deployed any more, as it would have
been part of the HFS->HFS+ transition, but I'm not really game to
mess with either, in particular as macbless writes(!) to disk live.
(I'm fairly sure the grub-macbless tool invokes code from the
macbless module as well.)

Signed-off-by: Daniel Axtens <dja@axtens.net>

---

`make check` is unchanged except for not running the hfs test any more. However,
I don't have any macs set up to boot linux with HFS+, so I can't say much more for
certain. If anyone can check grub-macbless in particular that would be wonderful.
---
 .gitignore                    |    1 -
 INSTALL                       |    2 +-
 Makefile.util.def             |    7 -
 docs/grub.texi                |   14 +-
 grub-core/Makefile.core.def   |    5 -
 grub-core/commands/gptsync.c  |    3 +-
 grub-core/commands/macbless.c |    7 +-
 grub-core/fs/hfs.c            | 1446 ---------------------------------
 tests/gettext_strings_test.in |    2 +-
 tests/hfs_test.in             |   23 -
 tests/util/grub-fs-tester.in  |   44 +-
 util/grub-install-common.c    |    2 +-
 util/grub-install.c           |   11 +-
 util/grub-macbless.c          |    2 +-
 14 files changed, 31 insertions(+), 1538 deletions(-)
 delete mode 100644 grub-core/fs/hfs.c
 delete mode 100644 tests/hfs_test.in

diff --git a/.gitignore b/.gitignore
index f6a1bd051752..b475a8b27062 100644
--- a/.gitignore
+++ b/.gitignore
@@ -218,7 +218,6 @@ widthspec.bin
 /gzcompress_test
 /hddboot_test
 /help_test
-/hfs_test
 /hfsplus_test
 /include/grub/cpu
 /include/grub/gcrypt/g10lib.h
diff --git a/INSTALL b/INSTALL
index 7bca64f69881..a815d87ba39f 100644
--- a/INSTALL
+++ b/INSTALL
@@ -73,7 +73,7 @@ Prerequisites for make-check:
 
 * If running a Linux kernel the following modules must be loaded:
   - fuse, loop
-  - btrfs, ext4, f2fs, fat, hfs, hfsplus, jfs, mac-roman, minix, nilfs2,
+  - btrfs, ext4, f2fs, fat, hfsplus, jfs, mac-roman, minix, nilfs2,
     reiserfs, udf, xfs
   - On newer kernels, the exfat kernel modules may be used instead of the
     exfat FUSE filesystem
diff --git a/Makefile.util.def b/Makefile.util.def
index d919c562c4d1..8a66c8299ead 100644
--- a/Makefile.util.def
+++ b/Makefile.util.def
@@ -103,7 +103,6 @@ library = {
   common = grub-core/fs/exfat.c;
   common = grub-core/fs/f2fs.c;
   common = grub-core/fs/fshelp.c;
-  common = grub-core/fs/hfs.c;
   common = grub-core/fs/hfsplus.c;
   common = grub-core/fs/hfspluscomp.c;
   common = grub-core/fs/iso9660.c;
@@ -840,12 +839,6 @@ script = {
   common = tests/udf_test.in;
 };
 
-script = {
-  testcase = native;
-  name = hfs_test;
-  common = tests/hfs_test.in;
-};
-
 script = {
   testcase = native;
   name = jfs_test;
diff --git a/docs/grub.texi b/docs/grub.texi
index af119dea3b51..42fd1c874113 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -361,7 +361,7 @@ Fast FileSystem (AFFS)}, @dfn{AtheOS fs}, @dfn{BeFS},
 @dfn{BtrFS} (including raid0, raid1, raid10, gzip and lzo),
 @dfn{cpio} (little- and big-endian bin, odc and newc variants),
 @dfn{Linux ext2/ext3/ext4}, @dfn{DOS FAT12/FAT16/FAT32},
-@dfn{exFAT}, @dfn{F2FS}, @dfn{HFS}, @dfn{HFS+},
+@dfn{exFAT}, @dfn{F2FS}, @dfn{HFS+},
 @dfn{ISO9660} (including Joliet, Rock-ridge and multi-chunk files),
 @dfn{JFS}, @dfn{Minix fs} (versions 1, 2 and 3), @dfn{nilfs2},
 @dfn{NTFS} (including compression), @dfn{ReiserFS}, @dfn{ROMFS},
@@ -846,7 +846,7 @@ not use any additional partition maps to access @file{/boot}
 @item
 @file{/boot} must be on one of following filesystems:
    AFFS, AFS, BFS, cpio, newc, odc, ext2/3/4, FAT, exFAT,
-   F2FS, HFS, uncompressed HFS+, ISO9660, JFS, Minix, Minix2, Minix3, NILFS2,
+   F2FS, uncompressed HFS+, ISO9660, JFS, Minix, Minix2, Minix3, NILFS2,
    NTFS, ReiserFS, ROMFS, SFS, tar, UDF, UFS1, UFS2, XFS
 @end itemize
 
@@ -5925,8 +5925,8 @@ GRUB shell may provide more information on parameters and usage.
 @item @command{lspci} - List PCI devices.
 @item @command{lssal} - Display SAL system table.
 @item @command{lsspd} - Print Memory information.
-@item @command{macppcbless} - Bless DIR of HFS or HFS+ partition for PPC macs.
-@item @command{mactelbless} - Bless FILE of HFS or HFS+ partition for intel macs.
+@item @command{macppcbless} - Bless DIR of HFS+ partition for PPC macs.
+@item @command{mactelbless} - Bless FILE of HFS+ partition for intel macs.
 @item @command{net_set_vlan} - Set an interface's vlan id.
 @item @command{outb} - Write 8-bit VALUE to PORT.
 @item @command{outl} - Write 32-bit VALUE to PORT.
@@ -5987,14 +5987,14 @@ any ASCII is valid UTF-8). There are some old CD-ROMs which use CP437
 in non-compliant way. You're still able to access files with names containing
 only ASCII characters on such filesystems though. You're also able to access
 any file if the filesystem contains valid Joliet (UTF-16) or RockRidge (UTF-8).
-AFFS, SFS and HFS never use unicode and GRUB assumes them to be in Latin1,
-Latin1 and MacRoman respectively. GRUB handles filesystem case-insensitivity
+AFFS and SFS never use unicode and GRUB assumes them to be in Latin1.
+GRUB handles filesystem case-insensitivity
 however no attempt is performed at case conversion of international characters
 so e.g. a file named lowercase greek alpha is treated as different from
 the one named as uppercase alpha. The filesystems in questions are
 NTFS (except POSIX namespace), HFS+ (configurable at mkfs time, default
 insensitive), SFS (configurable at mkfs time, default insensitive),
-JFS (configurable at mkfs time, default sensitive), HFS, AFFS, FAT, exFAT
+JFS (configurable at mkfs time, default sensitive), AFFS, FAT, exFAT
 and ZFS (configurable on per-subvolume basis by property ``casesensitivity'',
 default sensitive). On ZFS subvolumes marked as case insensitive files
 containing lowercase international characters are inaccessible.
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 7159948721e1..dc2ac1f98416 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1427,11 +1427,6 @@ module = {
   common = fs/fshelp.c;
 };
 
-module = {
-  name = hfs;
-  common = fs/hfs.c;
-};
-
 module = {
   name = hfsplus;
   common = fs/hfsplus.c;
diff --git a/grub-core/commands/gptsync.c b/grub-core/commands/gptsync.c
index 444e24874f14..f1902299f17d 100644
--- a/grub-core/commands/gptsync.c
+++ b/grub-core/commands/gptsync.c
@@ -172,8 +172,7 @@ grub_cmd_gptsync (grub_command_t cmd __attribute__ ((unused)),
 	  else if (fs && grub_strcmp (fs->name, "fat") == 0)
 	    /* FIXME: detect FAT16. */
 	    type = GRUB_PC_PARTITION_TYPE_FAT32_LBA;
-	  else if (fs && (grub_strcmp (fs->name, "hfsplus") == 0
-			  || grub_strcmp (fs->name, "hfs") == 0))
+	  else if (fs && (grub_strcmp (fs->name, "hfsplus") == 0))
 	    type = GRUB_PC_PARTITION_TYPE_HFS;
 	  else
 	    /* FIXME: detect more types. */
diff --git a/grub-core/commands/macbless.c b/grub-core/commands/macbless.c
index 3d761452ac6c..0e5dc6b8b6c5 100644
--- a/grub-core/commands/macbless.c
+++ b/grub-core/commands/macbless.c
@@ -137,8 +137,7 @@ grub_mac_bless_file (grub_device_t dev, const char *path_in, int intel)
   struct find_node_context ctx;
 
   fs = grub_fs_probe (dev);
-  if (!fs || (grub_strcmp (fs->name, "hfsplus") != 0
-	      && grub_strcmp (fs->name, "hfs") != 0))
+  if (!fs || (grub_strcmp (fs->name, "hfsplus") != 0))
     return grub_error (GRUB_ERR_BAD_FS, "no suitable FS found");
 
   path = grub_strdup (path_in);
@@ -220,10 +219,10 @@ GRUB_MOD_INIT(macbless)
 {
   cmd = grub_register_command ("mactelbless", grub_cmd_macbless,
 			       N_("FILE"),
-			       N_("Bless FILE of HFS or HFS+ partition for intel macs."));
+			       N_("Bless FILE of HFS+ partition for intel macs."));
   cmd_ppc =
     grub_register_command ("macppcbless", grub_cmd_macbless, N_("DIR"),
-			   N_("Bless DIR of HFS or HFS+ partition for PPC macs."));
+			   N_("Bless DIR of HFS+ partition for PPC macs."));
 }
 
 GRUB_MOD_FINI(macbless)
diff --git a/grub-core/fs/hfs.c b/grub-core/fs/hfs.c
deleted file mode 100644
index 91dc0e69c3de..000000000000
--- a/grub-core/fs/hfs.c
+++ /dev/null
@@ -1,1446 +0,0 @@
-/* hfs.c - HFS.  */
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2004,2005,2006,2007,2008,2009  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-/* HFS is documented at
-   http://developer.apple.com/documentation/mac/Files/Files-2.html */
-
-#include <grub/err.h>
-#include <grub/file.h>
-#include <grub/mm.h>
-#include <grub/misc.h>
-#include <grub/disk.h>
-#include <grub/dl.h>
-#include <grub/types.h>
-#include <grub/hfs.h>
-#include <grub/i18n.h>
-#include <grub/fshelp.h>
-#include <grub/lockdown.h>
-
-GRUB_MOD_LICENSE ("GPLv3+");
-
-#define	GRUB_HFS_SBLOCK		2
-#define GRUB_HFS_EMBED_HFSPLUS_SIG 0x482B
-
-#define GRUB_HFS_BLKS		(data->blksz >> 9)
-
-#define GRUB_HFS_NODE_LEAF	0xFF
-
-/* The two supported filesystems a record can have.  */
-enum
-  {
-    GRUB_HFS_FILETYPE_DIR = 1,
-    GRUB_HFS_FILETYPE_FILE = 2
-  };
-
-/* Catalog node ID (CNID).  */
-enum grub_hfs_cnid_type
-  {
-    GRUB_HFS_CNID_ROOT_PARENT = 1,
-    GRUB_HFS_CNID_ROOT = 2,
-    GRUB_HFS_CNID_EXT = 3,
-    GRUB_HFS_CNID_CAT = 4,
-    GRUB_HFS_CNID_BAD = 5
-  };
-
-/* A node descriptor.  This is the header of every node.  */
-struct grub_hfs_node
-{
-  grub_uint32_t next;
-  grub_uint32_t prev;
-  grub_uint8_t type;
-  grub_uint8_t level;
-  grub_uint16_t reccnt;
-  grub_uint16_t unused;
-} GRUB_PACKED;
-
-/* The head of the B*-Tree.  */
-struct grub_hfs_treeheader
-{
-  grub_uint16_t tree_depth;
-  /* The number of the first node.  */
-  grub_uint32_t root_node;
-  grub_uint32_t leaves;
-  grub_uint32_t first_leaf;
-  grub_uint32_t last_leaf;
-  grub_uint16_t node_size;
-  grub_uint16_t key_size;
-  grub_uint32_t nodes;
-  grub_uint32_t free_nodes;
-  grub_uint8_t unused[76];
-} GRUB_PACKED;
-
-/* The state of a mounted HFS filesystem.  */
-struct grub_hfs_data
-{
-  struct grub_hfs_sblock sblock;
-  grub_disk_t disk;
-  grub_hfs_datarecord_t extents;
-  int fileid;
-  int size;
-  int ext_root;
-  int ext_size;
-  int cat_root;
-  int cat_size;
-  int blksz;
-  int log2_blksz;
-  int rootdir;
-};
-
-/* The key as used on disk in a catalog tree.  This is used to lookup
-   file/directory nodes by parent directory ID and filename.  */
-struct grub_hfs_catalog_key
-{
-  grub_uint8_t unused;
-  grub_uint32_t parent_dir;
-
-  /* Filename length.  */
-  grub_uint8_t strlen;
-
-  /* Filename.  */
-  grub_uint8_t str[31];
-} GRUB_PACKED;
-
-/* The key as used on disk in a extent overflow tree.  Using this key
-   the extents can be looked up using a fileid and logical start block
-   as index.  */
-struct grub_hfs_extent_key
-{
-  /* The kind of fork.  This is used to store meta information like
-     icons, attributes, etc.  We will only use the datafork, which is
-     0.  */
-  grub_uint8_t forktype;
-  grub_uint32_t fileid;
-  grub_uint16_t first_block;
-} GRUB_PACKED;
-
-/* A directory record.  This is used to find out the directory ID.  */
-struct grub_hfs_dirrec
-{
-  /* For a directory, type == 1.  */
-  grub_uint8_t type;
-  grub_uint8_t unused[5];
-  grub_uint32_t dirid;
-  grub_uint32_t ctime;
-  grub_uint32_t mtime;
-} GRUB_PACKED;
-
-/* Information about a file.  */
-struct grub_hfs_filerec
-{
-  /* For a file, type == 2.  */
-  grub_uint8_t type;
-  grub_uint8_t unused[19];
-  grub_uint32_t fileid;
-  grub_uint8_t unused2[2];
-  grub_uint32_t size;
-  grub_uint8_t unused3[18];
-  grub_uint32_t mtime;
-  grub_uint8_t unused4[22];
-
-  /* The first 3 extents of the file.  The other extents can be found
-     in the extent overflow file.  */
-  grub_hfs_datarecord_t extents;
-} GRUB_PACKED;
-
-/* A record descriptor, both key and data, used to pass to call back
-   functions.  */
-struct grub_hfs_record
-{
-  void *key;
-  grub_size_t keylen;
-  void *data;
-  grub_size_t datalen;
-};
-
-static grub_dl_t my_mod;
-\f
-static int grub_hfs_find_node (struct grub_hfs_data *, char *,
-			       grub_uint32_t, int, char *, grub_size_t);
-
-/* Find block BLOCK of the file FILE in the mounted UFS filesystem
-   DATA.  The first 3 extents are described by DAT.  If cache is set,
-   using caching to improve non-random reads.  */
-static unsigned int
-grub_hfs_block (struct grub_hfs_data *data, grub_hfs_datarecord_t dat,
-		int file, int block, int cache)
-{
-  grub_hfs_datarecord_t dr;
-  int pos = 0;
-  struct grub_hfs_extent_key key;
-
-  int tree = 0;
-  static int cache_file = 0;
-  static int cache_pos = 0;
-  static grub_hfs_datarecord_t cache_dr;
-
-  grub_memcpy (dr, dat, sizeof (dr));
-
-  key.forktype = 0;
-  key.fileid = grub_cpu_to_be32 (file);
-
-  if (cache && cache_file == file  && block > cache_pos)
-    {
-      pos = cache_pos;
-      key.first_block = grub_cpu_to_be16 (pos);
-      grub_memcpy (dr, cache_dr, sizeof (cache_dr));
-    }
-
-  for (;;)
-    {
-      int i;
-
-      /* Try all 3 extents.  */
-      for (i = 0; i < 3; i++)
-	{
-	  /* Check if the block is stored in this extent.  */
-	  if (grub_be_to_cpu16 (dr[i].count) + pos > block)
-	    {
-	      int first = grub_be_to_cpu16 (dr[i].first_block);
-
-	      /* If the cache is enabled, store the current position
-		 in the tree.  */
-	      if (tree && cache)
-		{
-		  cache_file = file;
-		  cache_pos = pos;
-		  grub_memcpy (cache_dr, dr, sizeof (cache_dr));
-		}
-
-	      return (grub_be_to_cpu16 (data->sblock.first_block)
-		      + (first + block - pos) * GRUB_HFS_BLKS);
-	    }
-
-	  /* Try the next extent.  */
-	  pos += grub_be_to_cpu16 (dr[i].count);
-	}
-
-      /* Lookup the block in the extent overflow file.  */
-      key.first_block = grub_cpu_to_be16 (pos);
-      tree = 1;
-      grub_hfs_find_node (data, (char *) &key, data->ext_root,
-			  1, (char *) &dr, sizeof (dr));
-      if (grub_errno)
-	return 0;
-    }
-}
-
-
-/* Read LEN bytes from the file described by DATA starting with byte
-   POS.  Return the amount of read bytes in READ.  */
-static grub_ssize_t
-grub_hfs_read_file (struct grub_hfs_data *data,
-		    grub_disk_read_hook_t read_hook, void *read_hook_data,
-		    grub_uint32_t pos, grub_size_t len, char *buf)
-{
-  grub_off_t i;
-  grub_off_t blockcnt;
-
-  /* Files are at most 2G/4G - 1 bytes on hfs. Avoid 64-bit division.
-     Moreover len > 0 as checked in upper layer.  */
-  blockcnt = (len + pos - 1) / data->blksz + 1;
-
-  for (i = pos / data->blksz; i < blockcnt; i++)
-    {
-      grub_disk_addr_t blknr;
-      grub_off_t blockoff;
-      grub_off_t blockend = data->blksz;
-
-      int skipfirst = 0;
-
-      blockoff = pos % data->blksz;
-
-      blknr = grub_hfs_block (data, data->extents, data->fileid, i, 1);
-      if (grub_errno)
-	return -1;
-
-      /* Last block.  */
-      if (i == blockcnt - 1)
-	{
-	  blockend = (len + pos) % data->blksz;
-
-	  /* The last portion is exactly EXT2_BLOCK_SIZE (data).  */
-	  if (! blockend)
-	    blockend = data->blksz;
-	}
-
-      /* First block.  */
-      if (i == pos / data->blksz)
-	{
-	  skipfirst = blockoff;
-	  blockend -= skipfirst;
-	}
-
-      /* If the block number is 0 this block is not stored on disk but
-	 is zero filled instead.  */
-      if (blknr)
-	{
-	  data->disk->read_hook = read_hook;
-	  data->disk->read_hook_data = read_hook_data;
-	  grub_disk_read (data->disk, blknr, skipfirst,
-			  blockend, buf);
-	  data->disk->read_hook = 0;
-	  if (grub_errno)
-	    return -1;
-	}
-
-      buf += data->blksz - skipfirst;
-    }
-
-  return len;
-}
-
-
-/* Mount the filesystem on the disk DISK.  */
-static struct grub_hfs_data *
-grub_hfs_mount (grub_disk_t disk)
-{
-  struct grub_hfs_data *data;
-  struct grub_hfs_catalog_key key;
-  struct grub_hfs_dirrec dir;
-  int first_block;
-
-  struct
-  {
-    struct grub_hfs_node node;
-    struct grub_hfs_treeheader head;
-  } treehead;
-
-  data = grub_malloc (sizeof (struct grub_hfs_data));
-  if (!data)
-    return 0;
-
-  /* Read the superblock.  */
-  if (grub_disk_read (disk, GRUB_HFS_SBLOCK, 0,
-		      sizeof (struct grub_hfs_sblock), &data->sblock))
-    goto fail;
-
-  /* Check if this is a HFS filesystem.  */
-  if (grub_be_to_cpu16 (data->sblock.magic) != GRUB_HFS_MAGIC
-      || data->sblock.blksz == 0
-      || (data->sblock.blksz & grub_cpu_to_be32_compile_time (0xc00001ff)))
-    {
-      grub_error (GRUB_ERR_BAD_FS, "not an HFS filesystem");
-      goto fail;
-    }
-
-  /* Check if this is an embedded HFS+ filesystem.  */
-  if (grub_be_to_cpu16 (data->sblock.embed_sig) == GRUB_HFS_EMBED_HFSPLUS_SIG)
-    {
-      grub_error (GRUB_ERR_BAD_FS, "embedded HFS+ filesystem");
-      goto fail;
-    }
-
-  data->blksz = grub_be_to_cpu32 (data->sblock.blksz);
-  data->disk = disk;
-
-  /* Lookup the root node of the extent overflow tree.  */
-  first_block = ((grub_be_to_cpu16 (data->sblock.extent_recs[0].first_block)
-		  * GRUB_HFS_BLKS)
-		 + grub_be_to_cpu16 (data->sblock.first_block));
-
-  if (grub_disk_read (data->disk, first_block, 0,
-		      sizeof (treehead), &treehead))
-    goto fail;
-  data->ext_root = grub_be_to_cpu32 (treehead.head.root_node);
-  data->ext_size = grub_be_to_cpu16 (treehead.head.node_size);
-
-  /* Lookup the root node of the catalog tree.  */
-  first_block = ((grub_be_to_cpu16 (data->sblock.catalog_recs[0].first_block)
-		  * GRUB_HFS_BLKS)
-		 + grub_be_to_cpu16 (data->sblock.first_block));
-  if (grub_disk_read (data->disk, first_block, 0,
-		      sizeof (treehead), &treehead))
-    goto fail;
-  data->cat_root = grub_be_to_cpu32 (treehead.head.root_node);
-  data->cat_size = grub_be_to_cpu16 (treehead.head.node_size);
-
-  if (data->cat_size == 0
-      || data->blksz < data->cat_size
-      || data->blksz < data->ext_size)
-    goto fail;
-
-  /* Lookup the root directory node in the catalog tree using the
-     volume name.  */
-  key.parent_dir = grub_cpu_to_be32_compile_time (1);
-  key.strlen = data->sblock.volname[0];
-  grub_strcpy ((char *) key.str, (char *) (data->sblock.volname + 1));
-
-  if (grub_hfs_find_node (data, (char *) &key, data->cat_root,
-			  0, (char *) &dir, sizeof (dir)) == 0)
-    {
-      grub_error (GRUB_ERR_BAD_FS, "cannot find the HFS root directory");
-      goto fail;
-    }
-
-  if (grub_errno)
-    goto fail;
-
-  data->rootdir = grub_be_to_cpu32 (dir.dirid);
-
-  return data;
- fail:
-  grub_free (data);
-
-  if (grub_errno == GRUB_ERR_OUT_OF_RANGE)
-    grub_error (GRUB_ERR_BAD_FS, "not a HFS filesystem");
-
-  return 0;
-}
-
-/* Compare the K1 and K2 catalog file keys using HFS character ordering.  */
-static int
-grub_hfs_cmp_catkeys (const struct grub_hfs_catalog_key *k1,
-		      const struct grub_hfs_catalog_key *k2)
-{
-  /* Taken from hfsutils 3.2.6 and converted to a readable form */
-  static const unsigned char hfs_charorder[256] = {
-    [0x00] = 0,
-    [0x01] = 1,
-    [0x02] = 2,
-    [0x03] = 3,
-    [0x04] = 4,
-    [0x05] = 5,
-    [0x06] = 6,
-    [0x07] = 7,
-    [0x08] = 8,
-    [0x09] = 9,
-    [0x0A] = 10,
-    [0x0B] = 11,
-    [0x0C] = 12,
-    [0x0D] = 13,
-    [0x0E] = 14,
-    [0x0F] = 15,
-    [0x10] = 16,
-    [0x11] = 17,
-    [0x12] = 18,
-    [0x13] = 19,
-    [0x14] = 20,
-    [0x15] = 21,
-    [0x16] = 22,
-    [0x17] = 23,
-    [0x18] = 24,
-    [0x19] = 25,
-    [0x1A] = 26,
-    [0x1B] = 27,
-    [0x1C] = 28,
-    [0x1D] = 29,
-    [0x1E] = 30,
-    [0x1F] = 31,
-    [' '] = 32,		[0xCA] = 32,
-    ['!'] = 33,
-    ['"'] = 34,
-    [0xD2] = 35,
-    [0xD3] = 36,
-    [0xC7] = 37,
-    [0xC8] = 38,
-    ['#'] = 39,
-    ['$'] = 40,
-    ['%'] = 41,
-    ['&'] = 42,
-    ['\''] = 43,
-    [0xD4] = 44,
-    [0xD5] = 45,
-    ['('] = 46,
-    [')'] = 47,
-    ['*'] = 48,
-    ['+'] = 49,
-    [','] = 50,
-    ['-'] = 51,
-    ['.'] = 52,
-    ['/'] = 53,
-    ['0'] = 54,
-    ['1'] = 55,
-    ['2'] = 56,
-    ['3'] = 57,
-    ['4'] = 58,
-    ['5'] = 59,
-    ['6'] = 60,
-    ['7'] = 61,
-    ['8'] = 62,
-    ['9'] = 63,
-    [':'] = 64,
-    [';'] = 65,
-    ['<'] = 66,
-    ['='] = 67,
-    ['>'] = 68,
-    ['?'] = 69,
-    ['@'] = 70,
-    ['A'] = 71,		['a'] = 71,
-    [0x88] = 72,	[0xCB] = 72,
-    [0x80] = 73,	[0x8A] = 73,
-    [0x8B] = 74,	[0xCC] = 74,
-    [0x81] = 75,	[0x8C] = 75,
-    [0xAE] = 76,	[0xBE] = 76,
-    ['`'] = 77,
-    [0x87] = 78,
-    [0x89] = 79,
-    [0xBB] = 80,
-    ['B'] = 81,		['b'] = 81,
-    ['C'] = 82,		['c'] = 82,
-    [0x82] = 83,	[0x8D] = 83,
-    ['D'] = 84,		['d'] = 84,
-    ['E'] = 85,		['e'] = 85,
-    [0x83] = 86,	[0x8E] = 86,
-    [0x8F] = 87,
-    [0x90] = 88,
-    [0x91] = 89,
-    ['F'] = 90,		['f'] = 90,
-    ['G'] = 91,		['g'] = 91,
-    ['H'] = 92,		['h'] = 92,
-    ['I'] = 93,		['i'] = 93,
-    [0x92] = 94,
-    [0x93] = 95,
-    [0x94] = 96,
-    [0x95] = 97,
-    ['J'] = 98,		['j'] = 98,
-    ['K'] = 99,		['k'] = 99,
-    ['L'] = 100,	['l'] = 100,
-    ['M'] = 101,	['m'] = 101,
-    ['N'] = 102,	['n'] = 102,
-    [0x84] = 103,	[0x96] = 103,
-    ['O'] = 104,	['o'] = 104,
-    [0x85] = 105,	[0x9A] = 105,
-    [0x9B] = 106,	[0xCD] = 106,
-    [0xAF] = 107,	[0xBF] = 107,
-    [0xCE] = 108,	[0xCF] = 108,
-    [0x97] = 109,
-    [0x98] = 110,
-    [0x99] = 111,
-    [0xBC] = 112,
-    ['P'] = 113,	['p'] = 113,
-    ['Q'] = 114,	['q'] = 114,
-    ['R'] = 115,	['r'] = 115,
-    ['S'] = 116,	['s'] = 116,
-    [0xA7] = 117,
-    ['T'] = 118,	['t'] = 118,
-    ['U'] = 119,	['u'] = 119,
-    [0x86] = 120,	[0x9F] = 120,
-    [0x9C] = 121,
-    [0x9D] = 122,
-    [0x9E] = 123,
-    ['V'] = 124,	['v'] = 124,
-    ['W'] = 125,	['w'] = 125,
-    ['X'] = 126,	['x'] = 126,
-    ['Y'] = 127,	['y'] = 127,
-    [0xD8] = 128,
-    ['Z'] = 129,	['z'] = 129,
-    ['['] = 130,
-    ['\\'] = 131,
-    [']'] = 132,
-    ['^'] = 133,
-    ['_'] = 134,
-    ['{'] = 135,
-    ['|'] = 136,
-    ['}'] = 137,
-    ['~'] = 138,
-    [0x7F] = 139,
-    [0xA0] = 140,
-    [0xA1] = 141,
-    [0xA2] = 142,
-    [0xA3] = 143,
-    [0xA4] = 144,
-    [0xA5] = 145,
-    [0xA6] = 146,
-    [0xA8] = 147,
-    [0xA9] = 148,
-    [0xAA] = 149,
-    [0xAB] = 150,
-    [0xAC] = 151,
-    [0xAD] = 152,
-    [0xB0] = 153,
-    [0xB1] = 154,
-    [0xB2] = 155,
-    [0xB3] = 156,
-    [0xB4] = 157,
-    [0xB5] = 158,
-    [0xB6] = 159,
-    [0xB7] = 160,
-    [0xB8] = 161,
-    [0xB9] = 162,
-    [0xBA] = 163,
-    [0xBD] = 164,
-    [0xC0] = 165,
-    [0xC1] = 166,
-    [0xC2] = 167,
-    [0xC3] = 168,
-    [0xC4] = 169,
-    [0xC5] = 170,
-    [0xC6] = 171,
-    [0xC9] = 172,
-    [0xD0] = 173,
-    [0xD1] = 174,
-    [0xD6] = 175,
-    [0xD7] = 176,
-    [0xD9] = 177,
-    [0xDA] = 178,
-    [0xDB] = 179,
-    [0xDC] = 180,
-    [0xDD] = 181,
-    [0xDE] = 182,
-    [0xDF] = 183,
-    [0xE0] = 184,
-    [0xE1] = 185,
-    [0xE2] = 186,
-    [0xE3] = 187,
-    [0xE4] = 188,
-    [0xE5] = 189,
-    [0xE6] = 190,
-    [0xE7] = 191,
-    [0xE8] = 192,
-    [0xE9] = 193,
-    [0xEA] = 194,
-    [0xEB] = 195,
-    [0xEC] = 196,
-    [0xED] = 197,
-    [0xEE] = 198,
-    [0xEF] = 199,
-    [0xF0] = 200,
-    [0xF1] = 201,
-    [0xF2] = 202,
-    [0xF3] = 203,
-    [0xF4] = 204,
-    [0xF5] = 205,
-    [0xF6] = 206,
-    [0xF7] = 207,
-    [0xF8] = 208,
-    [0xF9] = 209,
-    [0xFA] = 210,
-    [0xFB] = 211,
-    [0xFC] = 212,
-    [0xFD] = 213,
-    [0xFE] = 214,
-    [0xFF] = 215,
-  };
-  int i;
-  int cmp;
-  int minlen = (k1->strlen < k2->strlen) ? k1->strlen : k2->strlen;
-
-  cmp = (grub_be_to_cpu32 (k1->parent_dir) - grub_be_to_cpu32 (k2->parent_dir));
-  if (cmp != 0)
-    return cmp;
-
-  for (i = 0; i < minlen; i++)
-    {
-      cmp = (hfs_charorder[k1->str[i]] - hfs_charorder[k2->str[i]]);
-      if (cmp != 0)
-	return cmp;
-    }
-
-  /* Shorter strings precede long ones.  */
-  return (k1->strlen - k2->strlen);
-}
-
-
-/* Compare the K1 and K2 extent overflow file keys.  */
-static int
-grub_hfs_cmp_extkeys (const struct grub_hfs_extent_key *k1,
-		      const struct grub_hfs_extent_key *k2)
-{
-  int cmp = k1->forktype - k2->forktype;
-  if (cmp == 0)
-    cmp = grub_be_to_cpu32 (k1->fileid) - grub_be_to_cpu32 (k2->fileid);
-  if (cmp == 0)
-    cmp = (grub_be_to_cpu16 (k1->first_block)
-	   - grub_be_to_cpu16 (k2->first_block));
-  return cmp;
-}
-
-
-/* Iterate the records in the node with index IDX in the mounted HFS
-   filesystem DATA.  This node holds data of the type TYPE (0 =
-   catalog node, 1 = extent overflow node).  If this is set, continue
-   iterating to the next node.  For every records, call NODE_HOOK.  */
-static grub_err_t
-grub_hfs_iterate_records (struct grub_hfs_data *data, int type, int idx,
-			  int this, int (*node_hook) (struct grub_hfs_node *hnd,
-						      struct grub_hfs_record *,
-						      void *hook_arg),
-			  void *hook_arg)
-{
-  grub_size_t nodesize = type == 0 ? data->cat_size : data->ext_size;
-
-  union node_union
-  {
-    struct grub_hfs_node node;
-    char rawnode[0];
-    grub_uint16_t offsets[0];
-  } *node;
-
-  if (nodesize < sizeof (struct grub_hfs_node))
-    nodesize = sizeof (struct grub_hfs_node);
-
-  node = grub_malloc (nodesize);
-  if (!node)
-    return grub_errno;
-
-  do
-    {
-      int i;
-      struct grub_hfs_extent *dat;
-      int blk;
-      grub_uint16_t reccnt;
-
-      dat = (struct grub_hfs_extent *) (type == 0
-					? (&data->sblock.catalog_recs)
-					: (&data->sblock.extent_recs));
-
-      /* Read the node into memory.  */
-      blk = grub_hfs_block (data, dat,
-                            (type == 0) ? GRUB_HFS_CNID_CAT : GRUB_HFS_CNID_EXT,
-			    idx / (data->blksz / nodesize), 0);
-      blk += (idx % (data->blksz / nodesize));
-
-      if (grub_errno || grub_disk_read (data->disk, blk, 0,
-					nodesize, node))
-	{
-	  grub_free (node);
-	  return grub_errno;
-	}
-
-      reccnt = grub_be_to_cpu16 (node->node.reccnt);
-      if (reccnt > (nodesize >> 1))
-	reccnt = (nodesize >> 1);
-
-      /* Iterate over all records in this node.  */
-      for (i = 0; i < reccnt; i++)
-	{
-	  int pos = (nodesize >> 1) - 1 - i;
- 	  struct pointer
-	  {
-	    grub_uint8_t keylen;
-	    grub_uint8_t key;
-	  } GRUB_PACKED *pnt;
-	  grub_uint16_t off = grub_be_to_cpu16 (node->offsets[pos]);
-	  if (off > nodesize - sizeof(*pnt))
-	    continue;
-	  pnt = (struct pointer *) (off + node->rawnode);
-	  if (nodesize < (grub_size_t) off + pnt->keylen + 1)
-	    continue;
-
-	  struct grub_hfs_record rec =
-	    {
-	      &pnt->key,
-	      pnt->keylen,
-	      &pnt->key + pnt->keylen +(pnt->keylen + 1) % 2,
-	      nodesize - off - pnt->keylen - 1
-	    };
-
-	  if (node_hook (&node->node, &rec, hook_arg))
-	    {
-	      grub_free (node);
-	      return 0;
-	    }
-	}
-
-      idx = grub_be_to_cpu32 (node->node.next);
-    } while (idx && this);
-  grub_free (node);
-  return 0;
-}
-
-struct grub_hfs_find_node_node_found_ctx
-{
-  int found;
-  int isleaf;
-  int done;
-  int type;
-  const char *key;
-  char *datar;
-  grub_size_t datalen;
-};
-
-static int
-grub_hfs_find_node_node_found (struct grub_hfs_node *hnd, struct grub_hfs_record *rec,
-			       void *hook_arg)
-{
-  struct grub_hfs_find_node_node_found_ctx *ctx = hook_arg;
-  int cmp = 1;
-
-  if (ctx->type == 0)
-    cmp = grub_hfs_cmp_catkeys (rec->key, (const void *) ctx->key);
-  else
-    cmp = grub_hfs_cmp_extkeys (rec->key, (const void *) ctx->key);
-
-  /* If the key is smaller or equal to the current node, mark the
-     entry.  In case of a non-leaf mode it will be used to lookup
-     the rest of the tree.  */
-  if (cmp <= 0)
-    ctx->found = grub_be_to_cpu32 (grub_get_unaligned32 (rec->data));
-  else /* The key can not be found in the tree. */
-    return 1;
-
-  /* Check if this node is a leaf node.  */
-  if (hnd->type == GRUB_HFS_NODE_LEAF)
-    {
-      ctx->isleaf = 1;
-
-      /* Found it!!!!  */
-      if (cmp == 0)
-	{
-	  ctx->done = 1;
-
-	  grub_memcpy (ctx->datar, rec->data,
-		       rec->datalen < ctx->datalen ? rec->datalen : ctx->datalen);
-	  return 1;
-	}
-    }
-
-  return 0;
-}
-
-
-/* Lookup a record in the mounted filesystem DATA using the key KEY.
-   The index of the node on top of the tree is IDX.  The tree is of
-   the type TYPE (0 = catalog node, 1 = extent overflow node).  Return
-   the data in DATAR with a maximum length of DATALEN.  */
-static int
-grub_hfs_find_node (struct grub_hfs_data *data, char *key,
-		    grub_uint32_t idx, int type, char *datar, grub_size_t datalen)
-{
-  struct grub_hfs_find_node_node_found_ctx ctx =
-    {
-      .found = -1,
-      .isleaf = 0,
-      .done = 0,
-      .type = type,
-      .key = key,
-      .datar = datar,
-      .datalen = datalen
-    };
-
-  do
-    {
-      ctx.found = -1;
-
-      if (grub_hfs_iterate_records (data, type, idx, 0, grub_hfs_find_node_node_found, &ctx))
-        return 0;
-
-      if (ctx.found == -1)
-        return 0;
-
-      idx = ctx.found;
-    } while (! ctx.isleaf);
-
-  return ctx.done;
-}
-
-struct grub_hfs_iterate_dir_node_found_ctx
-{
-  grub_uint32_t dir_be;
-  int found;
-  int isleaf;
-  grub_uint32_t next;
-  int (*hook) (struct grub_hfs_record *, void *hook_arg);
-  void *hook_arg;
-};
-
-static int
-grub_hfs_iterate_dir_node_found (struct grub_hfs_node *hnd, struct grub_hfs_record *rec,
-				 void *hook_arg)
-{
-  struct grub_hfs_iterate_dir_node_found_ctx *ctx = hook_arg;
-  struct grub_hfs_catalog_key *ckey = rec->key;
-
-  /* The lowest key possible with DIR as root directory.  */
-  const struct grub_hfs_catalog_key key = {0, ctx->dir_be, 0, ""};
-
-  if (grub_hfs_cmp_catkeys (rec->key, &key) <= 0)
-    ctx->found = grub_be_to_cpu32 (grub_get_unaligned32 (rec->data));
-
-  if (hnd->type == 0xFF && ckey->strlen > 0)
-    {
-      ctx->isleaf = 1;
-      ctx->next = grub_be_to_cpu32 (hnd->next);
-
-      /* An entry was found.  */
-      if (ckey->parent_dir == ctx->dir_be)
-	return ctx->hook (rec, ctx->hook_arg);
-    }
-
-  return 0;
-}
-
-static int
-grub_hfs_iterate_dir_it_dir (struct grub_hfs_node *hnd __attribute ((unused)),
-			     struct grub_hfs_record *rec,
-			     void *hook_arg)
-{
-  struct grub_hfs_catalog_key *ckey = rec->key;
-  struct grub_hfs_iterate_dir_node_found_ctx *ctx = hook_arg;
-
-  /* Stop when the entries do not match anymore.  */
-  if (ckey->parent_dir != ctx->dir_be)
-    return 1;
-
-  return ctx->hook (rec, ctx->hook_arg);
-}
-
-
-/* Iterate over the directory with the id DIR.  The tree is searched
-   starting with the node ROOT_IDX.  For every entry in this directory
-   call HOOK.  */
-static grub_err_t
-grub_hfs_iterate_dir (struct grub_hfs_data *data, grub_uint32_t root_idx,
-		      grub_uint32_t dir, int (*hook) (struct grub_hfs_record *, void *hook_arg),
-		      void *hook_arg)
-{
-  struct grub_hfs_iterate_dir_node_found_ctx ctx =
-  {
-    .dir_be = grub_cpu_to_be32 (dir),
-    .found = -1,
-    .isleaf = 0,
-    .next = 0,
-    .hook = hook,
-    .hook_arg = hook_arg
-  };
-
-  do
-    {
-      ctx.found = -1;
-
-      if (grub_hfs_iterate_records (data, 0, root_idx, 0, grub_hfs_iterate_dir_node_found, &ctx))
-        return grub_errno;
-
-      if (ctx.found == -1)
-        return 0;
-
-      root_idx = ctx.found;
-    } while (! ctx.isleaf);
-
-  /* If there was a matching record in this leaf node, continue the
-     iteration until the last record was found.  */
-  grub_hfs_iterate_records (data, 0, ctx.next, 1, grub_hfs_iterate_dir_it_dir, &ctx);
-  return grub_errno;
-}
-
-#define MAX_UTF8_PER_MAC_ROMAN 3
-
-static const char macroman[0x80][MAX_UTF8_PER_MAC_ROMAN + 1] =
-  {
-    /* 80 */ "\xc3\x84",
-    /* 81 */ "\xc3\x85",
-    /* 82 */ "\xc3\x87",
-    /* 83 */ "\xc3\x89",
-    /* 84 */ "\xc3\x91",
-    /* 85 */ "\xc3\x96",
-    /* 86 */ "\xc3\x9c",
-    /* 87 */ "\xc3\xa1",
-    /* 88 */ "\xc3\xa0",
-    /* 89 */ "\xc3\xa2",
-    /* 8A */ "\xc3\xa4",
-    /* 8B */ "\xc3\xa3",
-    /* 8C */ "\xc3\xa5",
-    /* 8D */ "\xc3\xa7",
-    /* 8E */ "\xc3\xa9",
-    /* 8F */ "\xc3\xa8",
-    /* 90 */ "\xc3\xaa",
-    /* 91 */ "\xc3\xab",
-    /* 92 */ "\xc3\xad",
-    /* 93 */ "\xc3\xac",
-    /* 94 */ "\xc3\xae",
-    /* 95 */ "\xc3\xaf",
-    /* 96 */ "\xc3\xb1",
-    /* 97 */ "\xc3\xb3",
-    /* 98 */ "\xc3\xb2",
-    /* 99 */ "\xc3\xb4",
-    /* 9A */ "\xc3\xb6",
-    /* 9B */ "\xc3\xb5",
-    /* 9C */ "\xc3\xba",
-    /* 9D */ "\xc3\xb9",
-    /* 9E */ "\xc3\xbb",
-    /* 9F */ "\xc3\xbc",
-    /* A0 */ "\xe2\x80\xa0",
-    /* A1 */ "\xc2\xb0",
-    /* A2 */ "\xc2\xa2",
-    /* A3 */ "\xc2\xa3",
-    /* A4 */ "\xc2\xa7",
-    /* A5 */ "\xe2\x80\xa2",
-    /* A6 */ "\xc2\xb6",
-    /* A7 */ "\xc3\x9f",
-    /* A8 */ "\xc2\xae",
-    /* A9 */ "\xc2\xa9",
-    /* AA */ "\xe2\x84\xa2",
-    /* AB */ "\xc2\xb4",
-    /* AC */ "\xc2\xa8",
-    /* AD */ "\xe2\x89\xa0",
-    /* AE */ "\xc3\x86",
-    /* AF */ "\xc3\x98",
-    /* B0 */ "\xe2\x88\x9e",
-    /* B1 */ "\xc2\xb1",
-    /* B2 */ "\xe2\x89\xa4",
-    /* B3 */ "\xe2\x89\xa5",
-    /* B4 */ "\xc2\xa5",
-    /* B5 */ "\xc2\xb5",
-    /* B6 */ "\xe2\x88\x82",
-    /* B7 */ "\xe2\x88\x91",
-    /* B8 */ "\xe2\x88\x8f",
-    /* B9 */ "\xcf\x80",
-    /* BA */ "\xe2\x88\xab",
-    /* BB */ "\xc2\xaa",
-    /* BC */ "\xc2\xba",
-    /* BD */ "\xce\xa9",
-    /* BE */ "\xc3\xa6",
-    /* BF */ "\xc3\xb8",
-    /* C0 */ "\xc2\xbf",
-    /* C1 */ "\xc2\xa1",
-    /* C2 */ "\xc2\xac",
-    /* C3 */ "\xe2\x88\x9a",
-    /* C4 */ "\xc6\x92",
-    /* C5 */ "\xe2\x89\x88",
-    /* C6 */ "\xe2\x88\x86",
-    /* C7 */ "\xc2\xab",
-    /* C8 */ "\xc2\xbb",
-    /* C9 */ "\xe2\x80\xa6",
-    /* CA */ "\xc2\xa0",
-    /* CB */ "\xc3\x80",
-    /* CC */ "\xc3\x83",
-    /* CD */ "\xc3\x95",
-    /* CE */ "\xc5\x92",
-    /* CF */ "\xc5\x93",
-    /* D0 */ "\xe2\x80\x93",
-    /* D1 */ "\xe2\x80\x94",
-    /* D2 */ "\xe2\x80\x9c",
-    /* D3 */ "\xe2\x80\x9d",
-    /* D4 */ "\xe2\x80\x98",
-    /* D5 */ "\xe2\x80\x99",
-    /* D6 */ "\xc3\xb7",
-    /* D7 */ "\xe2\x97\x8a",
-    /* D8 */ "\xc3\xbf",
-    /* D9 */ "\xc5\xb8",
-    /* DA */ "\xe2\x81\x84",
-    /* DB */ "\xe2\x82\xac",
-    /* DC */ "\xe2\x80\xb9",
-    /* DD */ "\xe2\x80\xba",
-    /* DE */ "\xef\xac\x81",
-    /* DF */ "\xef\xac\x82",
-    /* E0 */ "\xe2\x80\xa1",
-    /* E1 */ "\xc2\xb7",
-    /* E2 */ "\xe2\x80\x9a",
-    /* E3 */ "\xe2\x80\x9e",
-    /* E4 */ "\xe2\x80\xb0",
-    /* E5 */ "\xc3\x82",
-    /* E6 */ "\xc3\x8a",
-    /* E7 */ "\xc3\x81",
-    /* E8 */ "\xc3\x8b",
-    /* E9 */ "\xc3\x88",
-    /* EA */ "\xc3\x8d",
-    /* EB */ "\xc3\x8e",
-    /* EC */ "\xc3\x8f",
-    /* ED */ "\xc3\x8c",
-    /* EE */ "\xc3\x93",
-    /* EF */ "\xc3\x94",
-    /* F0 */ "\xef\xa3\xbf",
-    /* F1 */ "\xc3\x92",
-    /* F2 */ "\xc3\x9a",
-    /* F3 */ "\xc3\x9b",
-    /* F4 */ "\xc3\x99",
-    /* F5 */ "\xc4\xb1",
-    /* F6 */ "\xcb\x86",
-    /* F7 */ "\xcb\x9c",
-    /* F8 */ "\xc2\xaf",
-    /* F9 */ "\xcb\x98",
-    /* FA */ "\xcb\x99",
-    /* FB */ "\xcb\x9a",
-    /* FC */ "\xc2\xb8",
-    /* FD */ "\xcb\x9d",
-    /* FE */ "\xcb\x9b",
-    /* FF */ "\xcb\x87",
-  };
-
-static void
-macroman_to_utf8 (char *to, const grub_uint8_t *from, grub_size_t len,
-		  int translate_slash)
-{
-  char *optr = to;
-  const grub_uint8_t *iptr;
-
-  for (iptr = from; iptr < from + len && *iptr; iptr++)
-    {
-      /* Translate '/' to ':' as per HFS spec.  */
-      if (*iptr == '/' && translate_slash)
-	{
-	  *optr++ = ':';
-	  continue;
-	}
-      if (!(*iptr & 0x80))
-	{
-	  *optr++ = *iptr;
-	  continue;
-	}
-      optr = grub_stpcpy (optr, macroman[*iptr & 0x7f]);
-    }
-  *optr = 0;
-}
-
-static grub_ssize_t
-utf8_to_macroman (grub_uint8_t *to, const char *from)
-{
-  grub_uint8_t *end = to + 31;
-  grub_uint8_t *optr = to;
-  const char *iptr = from;
-
-  while (*iptr && optr < end)
-    {
-      int i, clen;
-      /* Translate ':' to '/' as per HFS spec.  */
-      if (*iptr == ':')
-	{
-	  *optr++ = '/';
-	  iptr++;
-	  continue;
-	}
-      if (!(*iptr & 0x80))
-	{
-	  *optr++ = *iptr++;
-	  continue;
-	}
-      clen = 2;
-      if ((*iptr & 0xf0) == 0xe0)
-	clen++;
-      for (i = 0; i < 0x80; i++)
-	if (grub_memcmp (macroman[i], iptr, clen) == 0)
-	  break;
-      if (i == 0x80)
-	break;
-      *optr++ = i | 0x80;
-      iptr += clen;
-    }
-  /* Too long or not encodable.  */
-  if (*iptr)
-    return -1;
-  return optr - to;
-}
-
-union grub_hfs_anyrec {
-  struct grub_hfs_filerec frec;
-  struct grub_hfs_dirrec dir;
-};
-
-struct grub_fshelp_node
-{
-  struct grub_hfs_data *data;
-  union grub_hfs_anyrec fdrec;
-  grub_uint32_t inode;
-};
-
-static grub_err_t
-lookup_file (grub_fshelp_node_t dir,
-	     const char *name,
-	     grub_fshelp_node_t *foundnode,
-	     enum grub_fshelp_filetype *foundtype)
-{
-  struct grub_hfs_catalog_key key;
-  grub_ssize_t slen;
-  union grub_hfs_anyrec fdrec;
-
-  key.parent_dir = grub_cpu_to_be32 (dir->inode);
-  slen = utf8_to_macroman (key.str, name);
-  if (slen < 0)
-    /* Not found */
-    return GRUB_ERR_NONE;
-  key.strlen = slen;
-
-  /* Lookup this node.  */
-  if (! grub_hfs_find_node (dir->data, (char *) &key, dir->data->cat_root,
-			    0, (char *) &fdrec.frec, sizeof (fdrec.frec)))
-    /* Not found */
-    return GRUB_ERR_NONE;
-
-  *foundnode = grub_malloc (sizeof (struct grub_fshelp_node));
-  if (!*foundnode)
-    return grub_errno;
-
-  (*foundnode)->inode = grub_be_to_cpu32 (fdrec.dir.dirid);
-  (*foundnode)->fdrec = fdrec;
-  (*foundnode)->data = dir->data;
-  *foundtype = (fdrec.frec.type == GRUB_HFS_FILETYPE_DIR) ? GRUB_FSHELP_DIR : GRUB_FSHELP_REG;
-  return GRUB_ERR_NONE;
-}
-
-/* Find a file or directory with the pathname PATH in the filesystem
-   DATA.  Return the file record in RETDATA when it is non-zero.
-   Return the directory number in RETINODE when it is non-zero.  */
-static grub_err_t
-grub_hfs_find_dir (struct grub_hfs_data *data, const char *path,
-		   grub_fshelp_node_t *found,
-		   enum grub_fshelp_filetype exptype)
-{
-  struct grub_fshelp_node root = {
-    .data = data,
-    .inode = data->rootdir,
-    .fdrec = {
-      .frec = {
-	.type = GRUB_HFS_FILETYPE_DIR
-      }
-    }
-  };
-  grub_err_t err;
-
-  err = grub_fshelp_find_file_lookup (path, &root, found, lookup_file, NULL, exptype);
-
-  if (&root == *found)
-    {
-      *found = grub_malloc (sizeof (root));
-      if (!*found)
-	return grub_errno;
-      grub_memcpy (*found, &root, sizeof (root));
-    }
-  return err;
-}
-
-struct grub_hfs_dir_hook_ctx
-{
-  grub_fs_dir_hook_t hook;
-  void *hook_data;
-};
-
-static int
-grub_hfs_dir_hook (struct grub_hfs_record *rec, void *hook_arg)
-{
-  struct grub_hfs_dir_hook_ctx *ctx = hook_arg;
-  struct grub_hfs_dirrec *drec = rec->data;
-  struct grub_hfs_filerec *frec = rec->data;
-  struct grub_hfs_catalog_key *ckey = rec->key;
-  char fname[sizeof (ckey->str) * MAX_UTF8_PER_MAC_ROMAN + 1];
-  struct grub_dirhook_info info;
-  grub_size_t len;
-
-  grub_memset (fname, 0, sizeof (fname));
-
-  grub_memset (&info, 0, sizeof (info));
-
-  len = ckey->strlen;
-  if (len > sizeof (ckey->str))
-    len = sizeof (ckey->str);
-  macroman_to_utf8 (fname, ckey->str, len, 1);
-
-  info.case_insensitive = 1;
-
-  if (drec->type == GRUB_HFS_FILETYPE_DIR)
-    {
-      info.dir = 1;
-      info.mtimeset = 1;
-      info.inodeset = 1;
-      info.mtime = grub_be_to_cpu32 (drec->mtime) - 2082844800;
-      info.inode = grub_be_to_cpu32 (drec->dirid);
-      return ctx->hook (fname, &info, ctx->hook_data);
-    }
-  if (frec->type == GRUB_HFS_FILETYPE_FILE)
-    {
-      info.dir = 0;
-      info.mtimeset = 1;
-      info.inodeset = 1;
-      info.mtime = grub_be_to_cpu32 (frec->mtime) - 2082844800;
-      info.inode = grub_be_to_cpu32 (frec->fileid);
-      return ctx->hook (fname, &info, ctx->hook_data);
-    }
-
-  return 0;
-}
-
-\f
-static grub_err_t
-grub_hfs_dir (grub_device_t device, const char *path, grub_fs_dir_hook_t hook,
-	      void *hook_data)
-{
-  struct grub_hfs_data *data;
-  struct grub_hfs_dir_hook_ctx ctx =
-    {
-      .hook = hook,
-      .hook_data = hook_data
-    };
-  grub_fshelp_node_t found = NULL;
-
-  grub_dl_ref (my_mod);
-
-  data = grub_hfs_mount (device->disk);
-  if (!data)
-    goto fail;
-
-  /* First the directory ID for the directory.  */
-  if (grub_hfs_find_dir (data, path, &found, GRUB_FSHELP_DIR))
-    goto fail;
-
-  grub_hfs_iterate_dir (data, data->cat_root, found->inode, grub_hfs_dir_hook, &ctx);
-
- fail:
-  grub_free (found);
-  grub_free (data);
-
-  grub_dl_unref (my_mod);
-
-  return grub_errno;
-}
-
-
-/* Open a file named NAME and initialize FILE.  */
-static grub_err_t
-grub_hfs_open (struct grub_file *file, const char *name)
-{
-  struct grub_hfs_data *data;
-  grub_fshelp_node_t found = NULL;
-
-  grub_dl_ref (my_mod);
-
-  data = grub_hfs_mount (file->device->disk);
-
-  if (!data)
-    {
-      grub_dl_unref (my_mod);
-      return grub_errno;
-    }
-
-  if (grub_hfs_find_dir (data, name, &found, GRUB_FSHELP_REG))
-    {
-      grub_free (data);
-      grub_free (found);
-      grub_dl_unref (my_mod);
-      return grub_errno;
-    }
-
-  grub_memcpy (data->extents, found->fdrec.frec.extents, sizeof (grub_hfs_datarecord_t));
-  file->size = grub_be_to_cpu32 (found->fdrec.frec.size);
-  data->size = grub_be_to_cpu32 (found->fdrec.frec.size);
-  data->fileid = grub_be_to_cpu32 (found->fdrec.frec.fileid);
-  file->offset = 0;
-
-  file->data = data;
-
-  grub_free (found);
-
-  return 0;
-}
-
-static grub_ssize_t
-grub_hfs_read (grub_file_t file, char *buf, grub_size_t len)
-{
-  struct grub_hfs_data *data =
-    (struct grub_hfs_data *) file->data;
-
-  return grub_hfs_read_file (data, file->read_hook, file->read_hook_data,
-			     file->offset, len, buf);
-}
-
-
-static grub_err_t
-grub_hfs_close (grub_file_t file)
-{
-  grub_free (file->data);
-
-  grub_dl_unref (my_mod);
-
-  return 0;
-}
-
-
-static grub_err_t
-grub_hfs_label (grub_device_t device, char **label)
-{
-  struct grub_hfs_data *data;
-
-  data = grub_hfs_mount (device->disk);
-
-  if (data)
-    {
-      grub_size_t len = data->sblock.volname[0];
-      if (len > sizeof (data->sblock.volname) - 1)
-	len = sizeof (data->sblock.volname) - 1;
-      *label = grub_calloc (MAX_UTF8_PER_MAC_ROMAN + 1, len);
-      if (*label)
-	macroman_to_utf8 (*label, data->sblock.volname + 1,
-			  len + 1, 0);
-    }
-  else
-    *label = 0;
-
-  grub_free (data);
-  return grub_errno;
-}
-
-static grub_err_t
-grub_hfs_mtime (grub_device_t device, grub_int64_t *tm)
-{
-  struct grub_hfs_data *data;
-
-  data = grub_hfs_mount (device->disk);
-
-  if (data)
-    *tm = grub_be_to_cpu32 (data->sblock.mtime) - 2082844800;
-  else
-    *tm = 0;
-
-  grub_free (data);
-  return grub_errno;
-}
-
-static grub_err_t
-grub_hfs_uuid (grub_device_t device, char **uuid)
-{
-  struct grub_hfs_data *data;
-
-  grub_dl_ref (my_mod);
-
-  data = grub_hfs_mount (device->disk);
-  if (data && data->sblock.num_serial != 0)
-    {
-      *uuid = grub_xasprintf ("%016llx",
-			     (unsigned long long)
-			     grub_be_to_cpu64 (data->sblock.num_serial));
-    }
-  else
-    *uuid = NULL;
-
-  grub_dl_unref (my_mod);
-
-  grub_free (data);
-
-  return grub_errno;
-}
-
-
-\f
-static struct grub_fs grub_hfs_fs =
-  {
-    .name = "hfs",
-    .fs_dir = grub_hfs_dir,
-    .fs_open = grub_hfs_open,
-    .fs_read = grub_hfs_read,
-    .fs_close = grub_hfs_close,
-    .fs_label = grub_hfs_label,
-    .fs_uuid = grub_hfs_uuid,
-    .fs_mtime = grub_hfs_mtime,
-#ifdef GRUB_UTIL
-    .reserved_first_sector = 1,
-    .blocklist_install = 1,
-#endif
-    .next = 0
-  };
-
-GRUB_MOD_INIT(hfs)
-{
-  if (!grub_is_lockdown ())
-    grub_fs_register (&grub_hfs_fs);
-  my_mod = mod;
-}
-
-GRUB_MOD_FINI(hfs)
-{
-  if (!grub_is_lockdown())
-    grub_fs_unregister (&grub_hfs_fs);
-}
diff --git a/tests/gettext_strings_test.in b/tests/gettext_strings_test.in
index 1c37fe41b13b..cc44cf4ec88f 100644
--- a/tests/gettext_strings_test.in
+++ b/tests/gettext_strings_test.in
@@ -11,7 +11,7 @@ xgettext -f po/POTFILES.in -L C -o "$tdir/"skip3.pot -x po/grub.pot --keyword=vo
 cat po/POTFILES.in | xargs grep -hE -o "(  |    ){\"[a-z0-9\-]*\",[[:space:]]*('.'|[0-9]|-[0-9])," |sed "s,[[:space:]]*{\",,g;s,\"\,[[:space:]]*\('.'\|[0-9]\|-[0-9]\)\,,,g" | awk '{ print "msgid \"" $0 "\"\nmsgstr \"\"" ; }' > "$tdir/"opts.pot
 cat po/POTFILES.in | xargs grep -hE -o "[[:space:]]*\.name[[:space:]]*=[[:space:]]*\"[a-zA-Z0-9 ()]*\"" |sed "s,[[:space:]]*\.name[[:space:]]*=[[:space:]]*\",,g;s,\",,g" | awk '{ print "msgid \"" $0 "\"\nmsgstr \"\"" ; }' > "$tdir/"name.pot
 
-out="$(cat po/POTFILES.in | grep -v '\(colors.c\|lsefisystab.c\|lsefimmap.c\|lssal.c\|hdparm.c\|sendkey.c\|lsacpi.c\|lspci.c\|usbtest.c\|legacy_parse.c\|/libgcrypt/\|hfs.c\|/efi\.c$\|gnulib\|tests/\|util/ieee1275/ofpath.c\|minilzo.c\|terminfo.c\|setpci.c\|bin2h.c\|cb_timestamps.c\|grub-pe2elf.c\|getroot_[a-z]*.c\|getroot.c\|arc/init.c\|color.c\|grub-mklayout.c\|gentrigtables.c\|lzodefs.h\|lsefi.c\|cbls.c\|/zfs\.h$\|grub-macho2img.c\|syslinux_parse.c\|lvm.c\|efidisk.c\|grub-mkfont.c\|reiserfs.c\|LzmaEnc.c\)' | xgettext -f - -L C -o - -x po/grub.pot -x "$tdir/"skip.pot -x "$tdir/"skip2.pot -x "$tdir/"skip3.pot -x "$tdir/"opts.pot -x "$tdir/"name.pot -x po/exclude.pot -a --from-code=iso-8859-1)"
+out="$(cat po/POTFILES.in | grep -v '\(colors.c\|lsefisystab.c\|lsefimmap.c\|lssal.c\|hdparm.c\|sendkey.c\|lsacpi.c\|lspci.c\|usbtest.c\|legacy_parse.c\|/libgcrypt/\|/efi\.c$\|gnulib\|tests/\|util/ieee1275/ofpath.c\|minilzo.c\|terminfo.c\|setpci.c\|bin2h.c\|cb_timestamps.c\|grub-pe2elf.c\|getroot_[a-z]*.c\|getroot.c\|arc/init.c\|color.c\|grub-mklayout.c\|gentrigtables.c\|lzodefs.h\|lsefi.c\|cbls.c\|/zfs\.h$\|grub-macho2img.c\|syslinux_parse.c\|lvm.c\|efidisk.c\|grub-mkfont.c\|reiserfs.c\|LzmaEnc.c\)' | xgettext -f - -L C -o - -x po/grub.pot -x "$tdir/"skip.pot -x "$tdir/"skip2.pot -x "$tdir/"skip3.pot -x "$tdir/"opts.pot -x "$tdir/"name.pot -x po/exclude.pot -a --from-code=iso-8859-1)"
 rm -rf "$tdir"
 if [ x"$out" != x ]; then
     echo "$out"
diff --git a/tests/hfs_test.in b/tests/hfs_test.in
deleted file mode 100644
index 960f1cbd0f42..000000000000
--- a/tests/hfs_test.in
+++ /dev/null
@@ -1,23 +0,0 @@
-#!@BUILD_SHEBANG@
-
-set -e
-
-if [ "x$EUID" = "x" ] ; then
-  EUID=`id -u`
-fi
-
-if [ "$EUID" != 0 ] ; then
-   exit 99
-fi
-
-if ! which mkfs.hfs >/dev/null 2>&1; then
-   echo "mkfs.hfs not installed; cannot test HFS."
-   exit 99
-fi
-
-if ! grep -q mac_roman /proc/modules && ! modprobe mac_roman; then
-   echo "no mac-roman support; cannot test HFS."
-   exit 99
-fi
-
-"@builddir@/grub-fs-tester" hfs
diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in
index 43f6175c3b89..1be46f4a1300 100644
--- a/tests/util/grub-fs-tester.in
+++ b/tests/util/grub-fs-tester.in
@@ -128,12 +128,6 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 	    # It could go further but it requires more and more space
 	    MAXBLKSIZE=8286208
 	    ;;
-	xhfs)
-	    MINBLKSIZE=512
-	    # OS LIMITATION: should be 1048576 but linux hangs on unmnount with
-	    # >= 524288
-	    MAXBLKSIZE=262144
-	    ;;
 	xhfsplus | xhfsplus_casesens | xhfsplus_wrap)
 	    MINBLKSIZE=512
 	    MAXBLKSIZE=1048576
@@ -381,9 +375,6 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		# FS LIMITATION: SFS is latin1. At most 30 characters
 		x"sfs"*)
 		    FSLABEL="GRUB tt öäüé;/àèç åø¿ª©þð׫»µ¬";;
-		# FS LIMITATION:  HFS is Mac-Roman. At most 27 characters
-		x"hfs")
-		    FSLABEL="grub_t;/estéàèèéie fiucnree";;
 		# FS LIMITATION: UDF label is either up to 127 latin1 characters or 63 UTF-16 ones
 		# OS LIMITATION: Linux UDF tools force ASCII label ...
 		x"udf")
@@ -425,7 +416,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 	    fi
 
 	    case x"$fs" in
-		xvfat* | xmsdos* | xexfat* | xhfs | xhfsplus | xhfsplus_wrap | xaffs \
+		xvfat* | xmsdos* | xexfat* | xhfsplus | xhfsplus_wrap | xaffs \
 		    | xaffs_intl | xjfs_caseins | xsfs_caseins \
 		    | xzfs_caseins | xiso9660)
 		    CASESENS=n;;
@@ -486,7 +477,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		    # FS LIMITATION: These FS have int32 as file size field
 		    # FIXME: not so sure about AFFS
 		    # OS LIMITATION: minix2/minix3 could be formatted in a way to permit more.
-		x"minix3" | x"minix2" | x"hfs"| x"affs" | xaffs_intl | xreiserfs_old | xext2_old)
+		x"minix3" | x"minix2" | x"affs" | xaffs_intl | xreiserfs_old | xext2_old)
 		    BIGBLOCKCNT=$((0x7fffffff));;
 
 		# FS LIMITATION: redundant storage
@@ -504,16 +495,16 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 
 	    NOSYMLINK=n
 	    case x"$fs" in
-		# FS LIMITATION: no symlinks on FAT, exFAT, HFS, plain ISO9660 and Joliet
+		# FS LIMITATION: no symlinks on FAT, exFAT, plain ISO9660 and Joliet
 		# OS LIMITATION: ntfs-3g  creates interix symlinks which aren't real symlinks
-		x"vfat"* | xmsdos* | x"hfs" | x"exfat" | x"ntfs"* \
+		x"vfat"* | xmsdos* | x"exfat" | x"ntfs"* \
 		    | xiso9660 | xjoliet| xiso9660_1999 | xjoliet_1999)
 		    NOSYMLINK=y;;
 	    esac
 	    NOHARDLINK=n
 	    case x"$fs" in
-		# FS LIMITATION: no hardlinks on BFS, exfat, fat, hfs and SFS
-		xbfs | xexfat | x"vfat"* | xmsdos* | xhfs | xsfs | xsfs_caseins)
+		# FS LIMITATION: no hardlinks on BFS, exfat, fat, and SFS
+		xbfs | xexfat | x"vfat"* | xmsdos* | xsfs | xsfs_caseins)
 		    NOHARDLINK=y;;
 		# GRUB LIMITATION: no hardlink support on newc and hfs+
 		xcpio_crc | xcpio_newc | xhfsplus*)
@@ -524,8 +515,6 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 	    case x"$fs" in
 		x"cpio_ustar")
 		    LONGNAME="`echo $LONGNAME |head -c 99`";;
-		x"hfs")
-		    LONGNAME="`echo $LONGNAME |head -c 31`";;
 		x"minix" | x"minix2" | x"affs" | xaffs_intl | xiso9660)
 		    LONGNAME="`echo $LONGNAME |head -c 30`";;
 		x"sfs"*)
@@ -553,10 +542,6 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		    | x"tarfs" | x"cpio_"* | x"minix" | x"minix2" \
 		    | x"minix3" | x"ntfs"* | x"udf" | x"sfs"*)
 		    NOFSTIME=y;;
-		# OS LIMITATION: Linux doesn't update fstime.
-		# OS LIMITATION: Linux apparently uses localtime instead of UTC
-		xhfs)
-		    NOFILETIME=y; NOFSTIME=y;;
 		# GRUB LIMITATION:  FAT and exFAT use localtime. Unusable for GRUB
 		x"vfat"* | x"msdos"* | x"exfat")
 		    NOFILETIME=y; NOFSTIME=y;;
@@ -694,7 +679,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		x"minix")
 		    "mkfs.minix" "${MOUNTDEVICE}"
 		    ;;
-		# mkfs.hfs and mkfs.hfsplus don't fill UUID.
+		# mkfs.hfsplus doesn't fill UUID.
 		x"hfsplus")
 		    "mkfs.hfsplus" -b $BLKSIZE -v "$FSLABEL" "${MOUNTDEVICE}"
 		    dd if=/dev/urandom of="${MOUNTDEVICE}" bs=1 seek=$((0x468)) conv=notrunc count=8 ;;
@@ -706,11 +691,6 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		    "mkfs.hfsplus" -s -b $BLKSIZE -v "$FSLABEL" "${MOUNTDEVICE}"
 		    dd if=/dev/urandom of="${MOUNTDEVICE}" bs=1 seek=$((0x468)) conv=notrunc count=8
 		    MOUNTFS="hfsplus";;
-		x"hfs")
-		    "mkfs.hfs" -b $BLKSIZE -v "`echo $FSLABEL |recode utf8..macroman`" -h "${MOUNTDEVICE}"
-		    dd if=/dev/urandom of="${MOUNTDEVICE}" bs=1 seek=$((0x474)) conv=notrunc count=8
-		    MOUNTOPTS="iocharset=utf8,codepage=macroman,"
-		    ;;
 		x"vfat"*|xmsdos*)
 		    BITS="${fs/vfat/}"
 		    BITS="${BITS/msdos/}"
@@ -870,8 +850,8 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		# FS LIMITATION: AFFS is limited in file name length (30)
 		x"affs" | xaffs_intl)
 		    NASTYFILE=".?*\\!\"#@\$'()+ ,-;<=>^{_}[]\`|~.";;
-		# FS LIMITATION: hfs, minix and minix2 are limited in file name length (30 or 31)
-		x"hfs" | x"minix" | x"minix2")
+		# FS LIMITATION: minix and minix2 are limited in file name length (30 or 31)
+		x"minix" | x"minix2")
 		    NASTYFILE=".?*\\!\"#@\$&'()+ ,-:;<=>{}[]\`|~.";;
 		# FS LIMITATION: FAT doesn't accept ?, *, \, ", :,  <, >, |
 		# FS LIMITATION: FAT discards dots at the end.
@@ -890,8 +870,8 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 	    esac
 
 	    case x"$fs" in
-		# FS LIMITATION: HFS, AFFS and SFS use legacy codepage (mac-roman or latin1)
-		x"sfs"* | x"hfs" | x"affs" | xaffs_intl)
+		# FS LIMITATION: AFFS and SFS use legacy codepage (latin1)
+		x"sfs"* | x"affs" | xaffs_intl)
 		    IFILE="éàèüöäëñ"
 		    ISYM="ëñéüöäàè"
 		    ;;
@@ -1347,7 +1327,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do
 		    ;;
 	    esac
 	    case x"$fs" in
-		x"hfs"*)
+		x"hfsplus"*)
 		    GRUBUUID="`run_grubfstest xnu_uuid "$GRUBDEVICE"`"
 		    if [ x"$GRUBUUID" = x"$FSUUID" ]; then
 			:
diff --git a/util/grub-install-common.c b/util/grub-install-common.c
index 347558bf5412..43bb6e44b87f 100644
--- a/util/grub-install-common.c
+++ b/util/grub-install-common.c
@@ -368,7 +368,7 @@ grub_install_is_short_mbrgap_supported (void)
     {
      "part_msdos", "biosdisk", "affs", "afs", "bfs", "archelp",
      "cpio", "cpio_be", "newc", "odc", "ext2", "fat", "exfat",
-     "f2fs", "fshelp", "hfs", "hfsplus", "iso9660", "jfs", "minix",
+     "f2fs", "fshelp", "hfsplus", "iso9660", "jfs", "minix",
      "minix2", "minix3", "minix_be", "minix2_be", "nilfs2", "ntfs",
      "ntfscomp", "reiserfs", "romfs", "sfs", "tar", "udf", "ufs1",
      "ufs1_be", "ufs2", "xfs"
diff --git a/util/grub-install.c b/util/grub-install.c
index 7b04bd3c534b..8d2bd930bc85 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -1087,8 +1087,7 @@ main (int argc, char *argv[])
 
       efidir_is_mac = 0;
 
-      if (grub_strcmp (fs->name, "hfs") == 0
-	  || grub_strcmp (fs->name, "hfsplus") == 0)
+      if (grub_strcmp (fs->name, "hfsplus") == 0)
 	efidir_is_mac = 1;
 
       if (!efidir_is_mac && grub_strcmp (fs->name, "fat") != 0)
@@ -1238,13 +1237,11 @@ main (int argc, char *argv[])
 	  if (! fs)
 	    grub_util_error ("%s", grub_errmsg);
 
-	  if (grub_strcmp (fs->name, "hfs") != 0
-	      && grub_strcmp (fs->name, "hfsplus") != 0
+	  if (grub_strcmp (fs->name, "hfsplus") != 0
 	      && !is_guess)
-	    grub_util_error (_("filesystem on %s is neither HFS nor HFS+"),
+	    grub_util_error (_("filesystem on %s is not HFS+"),
 			     macppcdir);
-	  if (grub_strcmp (fs->name, "hfs") == 0
-	      || grub_strcmp (fs->name, "hfsplus") == 0)
+	  if (grub_strcmp (fs->name, "hfsplus") == 0)
 	    {
 	      install_device = macppcdir_device_names[0];
 	      is_prep = 0;
diff --git a/util/grub-macbless.c b/util/grub-macbless.c
index e9b15a053df2..36fddec94276 100644
--- a/util/grub-macbless.c
+++ b/util/grub-macbless.c
@@ -155,7 +155,7 @@ argp_parser (int key, char *arg, struct argp_state *state)
 
 static struct argp argp = {
   options, argp_parser, N_("--ppc PATH|--x86 FILE"),
-  N_("Mac-style bless on HFS or HFS+"),
+  N_("Mac-style bless on HFS+"),
   NULL, NULL, NULL
 };
 
-- 
2.25.1



^ permalink raw reply related	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 13:38 [PATCH] Remove HFS support Daniel Axtens
@ 2022-08-19 13:57 ` Daniel Kiper
  2022-08-19 14:03   ` John Paul Adrian Glaubitz
  0 siblings, 1 reply; 26+ messages in thread
From: Daniel Kiper @ 2022-08-19 13:57 UTC (permalink / raw)
  To: Daniel Axtens; +Cc: grub-devel

On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
> HFS is so so very old now. According to Wikipedia, HFS was
> introduced in 1985 and the successor HFS+ came out in January
> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
> support for reading HFS in 2019 with macOS 10.15.
>
> Grub's support for it doesn't survive contact with a fuzzer, and
> the issues involve some horrible mess of mutual recursion that
> would be time-consuming to sort out.
>
> HFS has been disabled under lockdown since commit 1c15848838d9
> ("fs/hfs: Disable under lockdown") which was part of an earlier
> spin of security fixes.
>
> I think it's time to consign HFS to the dustbin of history. It's
> firmly in the category of retrocomputing at this stage.
>
> This should not affect HFS+.
>
> There's a little bit of mess remaining: the macbless runtime
> command and HFS+ need the HFS headers for embedded volume support.
> I don't think that's really deployed any more, as it would have
> been part of the HFS->HFS+ transition, but I'm not really game to
> mess with either, in particular as macbless writes(!) to disk live.
> (I'm fairly sure the grub-macbless tool invokes code from the
> macbless module as well.)
>
> Signed-off-by: Daniel Axtens <dja@axtens.net>

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel, thank you for preparing this patch!

If I do not hear any major objections in the following weeks I will
merge this patch or a variant of it in the second half of September.

> ---
>
> `make check` is unchanged except for not running the hfs test any more. However,
> I don't have any macs set up to boot linux with HFS+, so I can't say much more for
> certain. If anyone can check grub-macbless in particular that would be wonderful.

Yeah, that would be prefect. Any volunteers?

Daniel


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 13:57 ` Daniel Kiper
@ 2022-08-19 14:03   ` John Paul Adrian Glaubitz
  2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
                       ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-19 14:03 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Daniel Axtens



> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>> HFS is so so very old now. According to Wikipedia, HFS was
>> introduced in 1985 and the successor HFS+ came out in January
>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>> support for reading HFS in 2019 with macOS 10.15.
>> 
>> Grub's support for it doesn't survive contact with a fuzzer, and
>> the issues involve some horrible mess of mutual recursion that
>> would be time-consuming to sort out.
>> 
>> HFS has been disabled under lockdown since commit 1c15848838d9
>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>> spin of security fixes.
>> 
>> I think it's time to consign HFS to the dustbin of history. It's
>> firmly in the category of retrocomputing at this stage.
>> 
>> This should not affect HFS+.
>> 
>> There's a little bit of mess remaining: the macbless runtime
>> command and HFS+ need the HFS headers for embedded volume support.
>> I don't think that's really deployed any more, as it would have
>> been part of the HFS->HFS+ transition, but I'm not really game to
>> mess with either, in particular as macbless writes(!) to disk live.
>> (I'm fairly sure the grub-macbless tool invokes code from the
>> macbless module as well.)
>> 
>> Signed-off-by: Daniel Axtens <dja@axtens.net>
> 
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> 
> Daniel, thank you for preparing this patch!
> 
> If I do not hear any major objections in the following weeks I will
> merge this patch or a variant of it in the second half of September.

We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs using HFS, so this change would be a breaking change for us.

So, that would be a no from Debian’s side.

Adrian


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 14:03   ` John Paul Adrian Glaubitz
@ 2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
  2022-08-20 14:23       ` Daniel Axtens
  2022-08-19 18:09     ` Steve McIntyre
  2022-08-20 13:53     ` Daniel Axtens
  2 siblings, 1 reply; 26+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2022-08-19 17:57 UTC (permalink / raw)
  To: The development of GNU GRUB

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

No go from me either. Older macs may not be able to read HFS+ /boot. Also
HFS+ presents couple of problems the biggest one is that in case of sudden
reboot HFS+ often needs to be mounted by OSX or cleaning dirty flag
manually before it becomes writeable.

Le ven. 19 août 2022, 16:05, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> a écrit :

>
>
> > On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
> >
> > On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
> >> HFS is so so very old now. According to Wikipedia, HFS was
> >> introduced in 1985 and the successor HFS+ came out in January
> >> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
> >> support for reading HFS in 2019 with macOS 10.15.
> >>
> >> Grub's support for it doesn't survive contact with a fuzzer, and
> >> the issues involve some horrible mess of mutual recursion that
> >> would be time-consuming to sort out.
> >>
> >> HFS has been disabled under lockdown since commit 1c15848838d9
> >> ("fs/hfs: Disable under lockdown") which was part of an earlier
> >> spin of security fixes.
> >>
> >> I think it's time to consign HFS to the dustbin of history. It's
> >> firmly in the category of retrocomputing at this stage.
> >>
> >> This should not affect HFS+.
> >>
> >> There's a little bit of mess remaining: the macbless runtime
> >> command and HFS+ need the HFS headers for embedded volume support.
> >> I don't think that's really deployed any more, as it would have
> >> been part of the HFS->HFS+ transition, but I'm not really game to
> >> mess with either, in particular as macbless writes(!) to disk live.
> >> (I'm fairly sure the grub-macbless tool invokes code from the
> >> macbless module as well.)
> >>
> >> Signed-off-by: Daniel Axtens <dja@axtens.net>
> >
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > Daniel, thank you for preparing this patch!
> >
> > If I do not hear any major objections in the following weeks I will
> > merge this patch or a variant of it in the second half of September.
>
> We’re still formatting our /boot partitions for Debian PowerPC for
> PowerMacs using HFS, so this change would be a breaking change for us.
>
> So, that would be a no from Debian’s side.
>
> Adrian
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3519 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 14:03   ` John Paul Adrian Glaubitz
  2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
@ 2022-08-19 18:09     ` Steve McIntyre
  2022-08-19 18:38       ` John Paul Adrian Glaubitz
  2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
  2022-08-20 13:53     ` Daniel Axtens
  2 siblings, 2 replies; 26+ messages in thread
From: Steve McIntyre @ 2022-08-19 18:09 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Daniel Axtens

On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote:
>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
>> 
>> If I do not hear any major objections in the following weeks I will
>> merge this patch or a variant of it in the second half of September.
>
>We’re still formatting our /boot partitions for Debian PowerPC for
>PowerMacs using HFS, so this change would be a breaking change for
>us.
>
>So, that would be a no from Debian’s side.

Not so fast please, Adrian. At the risk of sounding harsh, non-release
old ports like powerpc *really* don't get to dictate things in Debian
terms.

As Daniel Axtens has been finding out, the HFS code is terrible in
terms of security. If you still need it for old/semi-dead machines,
maybe you should fork an older grub release and stay with that?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 18:09     ` Steve McIntyre
@ 2022-08-19 18:38       ` John Paul Adrian Glaubitz
  2022-08-19 19:04         ` Dimitri John Ledkov
  2022-08-20 14:13         ` Daniel Axtens
  2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
  1 sibling, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-19 18:38 UTC (permalink / raw)
  To: The development of GNU GRUB, Steve McIntyre; +Cc: Daniel Axtens

On 8/19/22 20:09, Steve McIntyre wrote:
> On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote:
>>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
>>>
>>> If I do not hear any major objections in the following weeks I will
>>> merge this patch or a variant of it in the second half of September.
>>
>> We’re still formatting our /boot partitions for Debian PowerPC for
>> PowerMacs using HFS, so this change would be a breaking change for
>> us.
>>
>> So, that would be a no from Debian’s side.
> 
> Not so fast please, Adrian. At the risk of sounding harsh, non-release
> old ports like powerpc *really* don't get to dictate things in Debian
> terms.

Add "Ports" to this.

> As Daniel Axtens has been finding out, the HFS code is terrible in
> terms of security. If you still need it for old/semi-dead machines,
> maybe you should fork an older grub release and stay with that?

I don't know what should be the deal with the security of a boot loader
to be honest. If someone has access to your hardware so they can control
your bootloader, you have much worse problems anyway.

Forking is also a terrible idea as every forked package means having to
track it manually.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 18:09     ` Steve McIntyre
  2022-08-19 18:38       ` John Paul Adrian Glaubitz
@ 2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
  2022-08-26 15:46         ` John Paul Adrian Glaubitz
  1 sibling, 1 reply; 26+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2022-08-19 19:01 UTC (permalink / raw)
  To: The development of GNU GRUB

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

Le ven. 19 août 2022, 20:11, Steve McIntyre <steve@einval.com> a écrit :

> On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote:
> >> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
> >>
> >> If I do not hear any major objections in the following weeks I will
> >> merge this patch or a variant of it in the second half of September.
> >
> >We’re still formatting our /boot partitions for Debian PowerPC for
> >PowerMacs using HFS, so this change would be a breaking change for
> >us.
> >
> >So, that would be a no from Debian’s side.
>
> Not so fast please, Adrian. At the risk of sounding harsh, non-release
> old ports like powerpc *really* don't get to dictate things in Debian
> terms.
>
But booting old machines is still desirable for GRUB. Is there a reason why
HFS is actively bad for modern machines? Especially if it's disabled in
case of lockdown.
Can I have more details about your security concerns? I may consider
rewriting parts of HFS code to improve it.

>
> As Daniel Axtens has been finding out, the HFS code is terrible in
> terms of security. If you still need it for old/semi-dead machines,
> maybe you should fork an older grub release and stay with that?
>
> --
> Steve McIntyre, Cambridge, UK.
> steve@einval.com
>   Getting a SCSI chain working is perfectly simple if you remember that
> there
>   must be exactly three terminations: one on one end of the cable, one on
> the
>   far end, and the goat, terminated over the SCSI chain with a
> silver-handled
>   knife whilst burning *black* candles. --- Anthony DeBoer
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2762 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 18:38       ` John Paul Adrian Glaubitz
@ 2022-08-19 19:04         ` Dimitri John Ledkov
  2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
  2022-08-24  7:16           ` John Paul Adrian Glaubitz
  2022-08-20 14:13         ` Daniel Axtens
  1 sibling, 2 replies; 26+ messages in thread
From: Dimitri John Ledkov @ 2022-08-19 19:04 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Steve McIntyre, Daniel Axtens

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

There is no need for that code on any signed grubs or upstream. Ports that
want to support this patch can have it conditionally compiled / enabled
only on that arch, but not other.

For example, in Ubuntu we already use separate builds for signed & unsigned
bootloaders. Or one may keep grub-2.06 as separate source package. It's not
like those old platforms need any new features in the bootloader ever again.

The issue of insecure code is for signed bootloaders. Because there is a
separate level of protection that prevents replacing arbitrary bootloaders
(whilst potentially allow downgrade/upgrade attacks). Thus a responsible
upstream should drop this code.

On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, <
glaubitz@physik.fu-berlin.de> wrote:

> On 8/19/22 20:09, Steve McIntyre wrote:
> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz
> wrote:
> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
> >>>
> >>> If I do not hear any major objections in the following weeks I will
> >>> merge this patch or a variant of it in the second half of September.
> >>
> >> We’re still formatting our /boot partitions for Debian PowerPC for
> >> PowerMacs using HFS, so this change would be a breaking change for
> >> us.
> >>
> >> So, that would be a no from Debian’s side.
> >
> > Not so fast please, Adrian. At the risk of sounding harsh, non-release
> > old ports like powerpc *really* don't get to dictate things in Debian
> > terms.
>
> Add "Ports" to this.
>
> > As Daniel Axtens has been finding out, the HFS code is terrible in
> > terms of security. If you still need it for old/semi-dead machines,
> > maybe you should fork an older grub release and stay with that?
>
> I don't know what should be the deal with the security of a boot loader
> to be honest. If someone has access to your hardware so they can control
> your bootloader, you have much worse problems anyway.
>
> Forking is also a terrible idea as every forked package means having to
> track it manually.
>
> Adrian
>
> --
>   .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3265 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 19:04         ` Dimitri John Ledkov
@ 2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
  2022-08-20 14:05             ` Daniel Axtens
  2022-08-24  7:17             ` John Paul Adrian Glaubitz
  2022-08-24  7:16           ` John Paul Adrian Glaubitz
  1 sibling, 2 replies; 26+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2022-08-19 19:45 UTC (permalink / raw)
  To: The development of GNU GRUB

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

Le ven. 19 août 2022, 21:05, Dimitri John Ledkov <
dimitri.ledkov@canonical.com> a écrit :

> There is no need for that code on any signed grubs or upstream. Ports that
> want to support this patch can have it conditionally compiled / enabled
> only on that arch, but not other.
>
> For example, in Ubuntu we already use separate builds for signed &
> unsigned bootloaders. Or one may keep grub-2.06 as separate source package.
> It's not like those old platforms need any new features in the bootloader
> ever again.
>
> The issue of insecure code is for signed bootloaders. Because there is a
> separate level of protection that prevents replacing arbitrary bootloaders
> (whilst potentially allow downgrade/upgrade attacks). Thus a responsible
> upstream should drop this code.
>

This kind of consideration was taken into account when designing security
system and even when GRUB2 itself was designed. The solution is modules
whitelist. There are many modules that can be dropped from signed build not
just filesystems but also commands or loaders. There is no need to cut old
systems from new grub if existing infrastructure can handle it.



> On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, <
> glaubitz@physik.fu-berlin.de> wrote:
>
>> On 8/19/22 20:09, Steve McIntyre wrote:
>> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz
>> wrote:
>> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl>
>> wrote:
>> >>>
>> >>> If I do not hear any major objections in the following weeks I will
>> >>> merge this patch or a variant of it in the second half of September.
>> >>
>> >> We’re still formatting our /boot partitions for Debian PowerPC for
>> >> PowerMacs using HFS, so this change would be a breaking change for
>> >> us.
>> >>
>> >> So, that would be a no from Debian’s side.
>> >
>> > Not so fast please, Adrian. At the risk of sounding harsh, non-release
>> > old ports like powerpc *really* don't get to dictate things in Debian
>> > terms.
>>
>> Add "Ports" to this.
>>
>> > As Daniel Axtens has been finding out, the HFS code is terrible in
>> > terms of security. If you still need it for old/semi-dead machines,
>> > maybe you should fork an older grub release and stay with that?
>>
>> I don't know what should be the deal with the security of a boot loader
>> to be honest. If someone has access to your hardware so they can control
>> your bootloader, you have much worse problems anyway.
>>
>> Forking is also a terrible idea as every forked package means having to
>> track it manually.
>>
>> Adrian
>>
>> --
>>   .''`.  John Paul Adrian Glaubitz
>> : :' :  Debian Developer
>> `. `'   Physicist
>>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 4704 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 14:03   ` John Paul Adrian Glaubitz
  2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
  2022-08-19 18:09     ` Steve McIntyre
@ 2022-08-20 13:53     ` Daniel Axtens
  2022-08-24  7:21       ` John Paul Adrian Glaubitz
  2 siblings, 1 reply; 26+ messages in thread
From: Daniel Axtens @ 2022-08-20 13:53 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz, The development of GNU GRUB

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:

>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl> wrote:
>> 
>> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>>> HFS is so so very old now. According to Wikipedia, HFS was
>>> introduced in 1985 and the successor HFS+ came out in January
>>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>>> support for reading HFS in 2019 with macOS 10.15.
>>> 
>>> Grub's support for it doesn't survive contact with a fuzzer, and
>>> the issues involve some horrible mess of mutual recursion that
>>> would be time-consuming to sort out.
>>> 
>>> HFS has been disabled under lockdown since commit 1c15848838d9
>>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>>> spin of security fixes.
>>> 
>>> I think it's time to consign HFS to the dustbin of history. It's
>>> firmly in the category of retrocomputing at this stage.
>>> 
>>> This should not affect HFS+.
>>> 
>>> There's a little bit of mess remaining: the macbless runtime
>>> command and HFS+ need the HFS headers for embedded volume support.
>>> I don't think that's really deployed any more, as it would have
>>> been part of the HFS->HFS+ transition, but I'm not really game to
>>> mess with either, in particular as macbless writes(!) to disk live.
>>> (I'm fairly sure the grub-macbless tool invokes code from the
>>> macbless module as well.)
>>> 
>>> Signed-off-by: Daniel Axtens <dja@axtens.net>
>> 
>> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>> 
>> Daniel, thank you for preparing this patch!
>> 
>> If I do not hear any major objections in the following weeks I will
>> merge this patch or a variant of it in the second half of September.
>
> We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs using HFS, so this change would be a breaking change for us.
>

Really, plain HFS, not HFS+? Wowsers!

Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so
machines last produced around 2006?

Have you checked that you can't boot them with HFS+? Because HFS+
came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
I'd be really surprised if the firmware didn't support booting from
HFS+. I'd be very keen to hear.

Anyway, if I've understood correctly, the _most recent_ PowerMacs date
from around 16 years ago, and potentially the machines broken by this
would be even older. I still think that's in the domain of
retrocomputing and I don't understand the use case for running modern
software on something where the performance per watt is worse than a
recent raspberry pi.

Kind regards,
Daniel


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
@ 2022-08-20 14:05             ` Daniel Axtens
  2022-08-24  7:17             ` John Paul Adrian Glaubitz
  1 sibling, 0 replies; 26+ messages in thread
From: Daniel Axtens @ 2022-08-20 14:05 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:

> Le ven. 19 août 2022, 21:05, Dimitri John Ledkov <
> dimitri.ledkov@canonical.com> a écrit :
>
>> There is no need for that code on any signed grubs or upstream. Ports that
>> want to support this patch can have it conditionally compiled / enabled
>> only on that arch, but not other.
>>
>> For example, in Ubuntu we already use separate builds for signed &
>> unsigned bootloaders. Or one may keep grub-2.06 as separate source package.
>> It's not like those old platforms need any new features in the bootloader
>> ever again.
>>
>> The issue of insecure code is for signed bootloaders. Because there is a
>> separate level of protection that prevents replacing arbitrary bootloaders
>> (whilst potentially allow downgrade/upgrade attacks). Thus a responsible
>> upstream should drop this code.
>>
>
> This kind of consideration was taken into account when designing security
> system and even when GRUB2 itself was designed. The solution is modules
> whitelist. There are many modules that can be dropped from signed build not
> just filesystems but also commands or loaders. There is no need to cut old
> systems from new grub if existing infrastructure can handle it.

At least one grub binary signed as part of the UEFI shim process
contains the HFS code. (I'm not involved in the process that signs off
on what should be permitted in a signed grub.) Fortunately, the patch I
wrote earlier to disable HFS in lockdown should be sufficient to protect
the users of that binary.

That binary comes from one of the larger software companies in the
world, and passed the shim signing process. If they got a shim signed
that trusts a grub with HFS built in, I'm not sure we can really trust a
module whitelist as a good way to protect end users.

You ask in your other email what my concerns with the HFS code are and
how it could be fixed. The HFS code crashes when fuzz tested: that is,
you can construct a number of HFS images such that `grub-fstest hfs.img
ls '(loop0)/'` crashes. (There is public information on fuzzing grub
now, and that information is sufficient to reproduce the crashes I've
found. I can also provide sample crashing inputs.) It would be really
nice if the file systems in grub could survive malicious input, even if
ideally they would not be built into a signed grub binary.

Kind regards,
Daniel
>
>
>> On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, <
>> glaubitz@physik.fu-berlin.de> wrote:
>>
>>> On 8/19/22 20:09, Steve McIntyre wrote:
>>> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz
>>> wrote:
>>> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkiper@net-space.pl>
>>> wrote:
>>> >>>
>>> >>> If I do not hear any major objections in the following weeks I will
>>> >>> merge this patch or a variant of it in the second half of September.
>>> >>
>>> >> We’re still formatting our /boot partitions for Debian PowerPC for
>>> >> PowerMacs using HFS, so this change would be a breaking change for
>>> >> us.
>>> >>
>>> >> So, that would be a no from Debian’s side.
>>> >
>>> > Not so fast please, Adrian. At the risk of sounding harsh, non-release
>>> > old ports like powerpc *really* don't get to dictate things in Debian
>>> > terms.
>>>
>>> Add "Ports" to this.
>>>
>>> > As Daniel Axtens has been finding out, the HFS code is terrible in
>>> > terms of security. If you still need it for old/semi-dead machines,
>>> > maybe you should fork an older grub release and stay with that?
>>>
>>> I don't know what should be the deal with the security of a boot loader
>>> to be honest. If someone has access to your hardware so they can control
>>> your bootloader, you have much worse problems anyway.
>>>
>>> Forking is also a terrible idea as every forked package means having to
>>> track it manually.
>>>
>>> Adrian
>>>
>>> --
>>>   .''`.  John Paul Adrian Glaubitz
>>> : :' :  Debian Developer
>>> `. `'   Physicist
>>>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 18:38       ` John Paul Adrian Glaubitz
  2022-08-19 19:04         ` Dimitri John Ledkov
@ 2022-08-20 14:13         ` Daniel Axtens
  1 sibling, 0 replies; 26+ messages in thread
From: Daniel Axtens @ 2022-08-20 14:13 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz, The development of GNU GRUB, Steve McIntyre

>> As Daniel Axtens has been finding out, the HFS code is terrible in
>> terms of security. If you still need it for old/semi-dead machines,
>> maybe you should fork an older grub release and stay with that?
>
> I don't know what should be the deal with the security of a boot loader
> to be honest. If someone has access to your hardware so they can control
> your bootloader, you have much worse problems anyway.
>
> Forking is also a terrible idea as every forked package means having to
> track it manually.

Not to engage in the Debian specific parts of this, but fwiw the threat
model isn't hardware access. Firmware-enforced secure boot (e.g. UEFI,
AIX and Linux on PowerVM, whatever modern macs do) basically goes:

 - assume an attacker gets root on a running system
 - prevent the attacker from compromising the kernel

On Linux this takes 2 parts: some form of signing grub that gets
validated by firmware, and lockdown mode once Linux is booted.

Now I haven't really used a PowerMac since I was a kid, but if memory
serves, they had no concept of this. If you got access to Mac OS (or if
you got root on linux), there is no way to protect the kernel. There is,
in effect, no security boundary between root and the kernel.

Kind regards,
Daniel

>
> Adrian
>
> -- 
>   .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
@ 2022-08-20 14:23       ` Daniel Axtens
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Axtens @ 2022-08-20 14:23 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:

> No go from me either. Older macs may not be able to read HFS+ /boot. Also
> HFS+ presents couple of problems the biggest one is that in case of sudden
> reboot HFS+ often needs to be mounted by OSX or cleaning dirty flag
> manually before it becomes writeable.

I don't understand what you mean about the HFS+ dirtying issue. Aren't
grub's accesses to the file-system read-only anyway?

I'd really genuinely like to know how old a mac has to be not to support
booting from HFS+, a filesystem that came out around 1998, ~24 years
ago. I'd also like to know what use people have for running modern grub
on a machine that old.

Kind regards,
Daniel



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 19:04         ` Dimitri John Ledkov
  2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
@ 2022-08-24  7:16           ` John Paul Adrian Glaubitz
  1 sibling, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-24  7:16 UTC (permalink / raw)
  To: The development of GNU GRUB, Dimitri John Ledkov
  Cc: Steve McIntyre, Daniel Axtens

Hello!

On 8/19/22 21:04, Dimitri John Ledkov wrote:
> There is no need for that code on any signed grubs or upstream. Ports that want to
> support this patch can have it conditionally compiled / enabled only on that arch,
> but not other.

That's not how open source works. Individual projects do not get to determine what
upstream software supports and what not. And that goes both ways.

> For example, in Ubuntu we already use separate builds for signed & unsigned bootloaders.
> Or one may keep grub-2.06 as separate source package. It's not like those old platforms
> need any new features in the bootloader ever again.

That's not the point. Packages are constantly rebuild in Debian for various reasons and
having to maintain the package manually in Debian is quite annoying.

Forcing older ports to use forks of upstream projects is an "elegant" way to kill of these
ports as the maintenance burn gets too high.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
  2022-08-20 14:05             ` Daniel Axtens
@ 2022-08-24  7:17             ` John Paul Adrian Glaubitz
  1 sibling, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-24  7:17 UTC (permalink / raw)
  To: The development of GNU GRUB, Vladimir 'phcoder' Serbinenko

Hi Vladimir!

On 8/19/22 21:45, Vladimir 'phcoder' Serbinenko wrote:
> This kind of consideration was taken into account when designing security system and
> even when GRUB2 itself was designed. The solution is modules whitelist. There are many
> modules that can be dropped from signed build not just filesystems but also commands
> or loaders. There is no need to cut old systems from new grub if existing infrastructure
> can handle it.

Thank you! I don't understand why maintainers concerned with security can't just do that.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-20 13:53     ` Daniel Axtens
@ 2022-08-24  7:21       ` John Paul Adrian Glaubitz
  2022-08-26 13:31         ` Daniel Axtens
  0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-24  7:21 UTC (permalink / raw)
  To: Daniel Axtens; +Cc: The development of GNU GRUB

On 8/20/22 15:53, Daniel Axtens wrote:
> Really, plain HFS, not HFS+? Wowsers!

Yes, we're currently using HFS.

> Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so
> machines last produced around 2006?

Yes.

> Have you checked that you can't boot them with HFS+? Because HFS+
> came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
> I'd be really surprised if the firmware didn't support booting from
> HFS+. I'd be very keen to hear.

I have not tested that due to lack of time. The problem is that some early
firmware versions might have issues with HFS+ that we haven't verified
yet.

> Anyway, if I've understood correctly, the _most recent_ PowerMacs date
> from around 16 years ago, and potentially the machines broken by this
> would be even older. I still think that's in the domain of
> retrocomputing and I don't understand the use case for running modern
> software on something where the performance per watt is worse than a
> recent raspberry pi.

What's wrong with retrocomputing? Debian's popcon currently reports more
machines running the 32-bit big-endian Debian port than the 64-bit little
endian port, see [1].

I understand the need to sometimes get rid of old code, but since the HFS
module can be blacklisted as Vladimir explains, I don't really understand
the reasoning in this particular case.

FWIW, Gentoo also still uses HFS for booting PowerMacs [2].

Adrian

> [1] https://popcon.debian.org/
> [2] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC)

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-24  7:21       ` John Paul Adrian Glaubitz
@ 2022-08-26 13:31         ` Daniel Axtens
  2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
                             ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Daniel Axtens @ 2022-08-26 13:31 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: The development of GNU GRUB

Let me answer this out of order.

> I understand the need to sometimes get rid of old code, but since the HFS
> module can be blacklisted as Vladimir explains, I don't really understand
> the reasoning in this particular case.

I want _all_ grub code to reach a minimum standard of not crashing or
corrupting memory in the presence of malicious input. HFS does not reach
that standard.

Whether or not the HFS module could be omitted from a signed binary
doesn't really bear on the fact that there are bugs in the code, the
presence of bugs has been publicly known for over 18 months (see commit
1c15848838d9) and no-one has shown any intention of fixing the bugs.

If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
clean, then that'd be great. If no-one is able to bring it up to what is
*not* an especially high standard, then it should be considered
abandoned by developers and therefore removed.

(And as I said in another email, HFS has in fact been built in to a
signed binary recently. Module-based protection is great in theory but
this example demonstrates that it falls down in practice.)

>> Have you checked that you can't boot them with HFS+? Because HFS+
>> came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
>> I'd be really surprised if the firmware didn't support booting from
>> HFS+. I'd be very keen to hear.
>
> I have not tested that due to lack of time. The problem is that some early
> firmware versions might have issues with HFS+ that we haven't verified
> yet.

Any approach that says 'we must wait for test results for very old macs'
puts the grub community in a bind. I'm not aware of anyone else stepping
up to contribute test results on old macs, and I can't go across to an
apple store and buy one. So in order to test this, the entire grub
upstream stalls on (AFAICT) you personally.

This not the first time we find ourselves in this situation either.  For
example, RH is carrying the 'powerpc-ieee1275: support larger core.elf
images' series out of tree because they need it to boot on modern Power
boxes. It broke on your machine in a way no-one else has reproduced, and
I last emailled you asking for more information to debug the failure in
May.

For me, this is not a desirable, sustainable, or acceptable
situation. For the project to sustainably support 24 year old macs, we
need more than the tests you do in your free time.

Finally and in conclusion:

> What's wrong with retrocomputing? Debian's popcon currently reports more
> machines running the 32-bit big-endian Debian port than the 64-bit little
> endian port, see [1].

I have no complaint with running _old_ software on old hardware. That's
a cool hobby and an important part of preserving the history of computing.

My complaint about running _new_ grub on very old hardware is that the
inaccessibility of said hardware and the lack of a well-resourced
community or company to do the work are all getting in the way of people
trying to make grub a modern bootloader, reaching modern security
standards, for modern systems.

Kind regards,
Daniel


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 13:31         ` Daniel Axtens
@ 2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
  2022-08-30 18:28             ` Robbie Harwood
  2022-09-01 14:01             ` Daniel Axtens
  2022-08-26 15:27           ` John Paul Adrian Glaubitz
  2022-08-30 16:37           ` Robbie Harwood
  2 siblings, 2 replies; 26+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2022-08-26 15:17 UTC (permalink / raw)
  To: The development of GNU GRUB

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

Le ven. 26 août 2022, 15:47, Daniel Axtens <dja@axtens.net> a écrit :

> Let me answer this out of order.
>
> > I understand the need to sometimes get rid of old code, but since the HFS
> > module can be blacklisted as Vladimir explains, I don't really understand
> > the reasoning in this particular case.
>
> I want _all_ grub code to reach a minimum standard of not crashing or
> corrupting memory in the presence of malicious input. HFS does not reach
> that standard.
>
That is a very high standard. Products with a huge security team like
Chrome don't reach this standard. It's reasonable that you submit the
improvements. Also it's reasonable for you to blacklist code that gets in
the way of security. E.g. all compressors that are not used should be
blacklisted.

>
> Whether or not the HFS module could be omitted from a signed binary
> doesn't really bear on the fact that there are bugs in the code, the
> presence of bugs has been publicly known for over 18 months (see commit
> 1c15848838d9) and no-one has shown any intention of fixing the bugs.
>
That is besides the point of using GRUB on PowerMac or any other platform
with unsigned bootchain. And for signed bootchains it can be blacklisted in
the code like it already is. Which problem do you try to solve?

>
> If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
> clean, then that'd be great. If no-one is able to bring it up to what is
> *not* an especially high standard, then it should be considered
> abandoned by developers and therefore removed.
>
Show me the fuzzes that create problems and I'll improve the code

>
> (And as I said in another email, HFS has in fact been built in to a
> signed binary recently. Module-based protection is great in theory but
> this example demonstrates that it falls down in practice.)
>
Then implement a better module-based security with security attributes
stored in a special section of the binary how we do with the license to
allow only EFISB-approved modules to load under lockdown

>
> >> Have you checked that you can't boot them with HFS+? Because HFS+
> >> came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
> >> I'd be really surprised if the firmware didn't support booting from
> >> HFS+. I'd be very keen to hear.
> >
> > I have not tested that due to lack of time. The problem is that some
> early
> > firmware versions might have issues with HFS+ that we haven't verified
> > yet.
>
> Any approach that says 'we must wait for test results for very old macs'
> puts the grub community in a bind. I'm not aware of anyone else stepping
> up to contribute test results on old macs, and I can't go across to an
> apple store and buy one.


Old PowerMacs are available in most countries for under $50 next day. Other
PowerPC machines often cost thousands and you need to wait weeks. So
PowerMacs are important for the entire PPC ecosystem as a whole as it's the
most available platform if you're not employed by someone with a stake in
PPC.
Maintenance is a collaborative effort and it's inevitable that some
platforms

> So in order to test this, the entire grub
> upstream stalls on (AFAICT) you personally.
>
It's fine to commit patches that improve for other PPC without waiting for
PowerMacs. In fact I have often seen benefits from such moves.

>
> This not the first time we find ourselves in this situation either.  For
> example, RH is carrying the 'powerpc-ieee1275: support larger core.elf
> images' series out of tree because they need it to boot on modern Power
> boxes. It broke on your machine in a way no-one else has reproduced, and
> I last emailled you asking for more information to debug the failure in
> May.
>
This can happen with EFI as well. And indeed have. Several times. Should we
drop EFI support?

>
> For me, this is not a desirable, sustainable, or acceptable
> situation. For the project to sustainably support 24 year old macs, we
> need more than the tests you do in your free time.
>
> Finally and in conclusion:
>
> > What's wrong with retrocomputing? Debian's popcon currently reports more
> > machines running the 32-bit big-endian Debian port than the 64-bit little
> > endian port, see [1].
>
> I have no complaint with running _old_ software on old hardware. That's
> a cool hobby and an important part of preserving the history of computing.
>
> My complaint about running _new_ grub on very old hardware is that the
> inaccessibility

The "inaccessible" part is just wrong. They were manufactured in hundreds
of millions and are still the cheapest and most available way to test
software on big-endian machine and for this having an entire stack with
modern software is extremely useful even though there are some limitations
like lack of some graphics APIs

> of said hardware and the lack of a well-resourced
> community or company to do the work are all getting in the way of people
> trying to make grub a modern bootloader, reaching modern security
> standards, for modern systems.
>
Nobody's preventing you from adding blockers from loading undesirable
modules. What is a problem is "I don't need this code, let's kill it"

>
> Kind regards,
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 7913 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 13:31         ` Daniel Axtens
  2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
@ 2022-08-26 15:27           ` John Paul Adrian Glaubitz
  2022-08-30 16:37           ` Robbie Harwood
  2 siblings, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-26 15:27 UTC (permalink / raw)
  To: Daniel Axtens; +Cc: The development of GNU GRUB

On 8/26/22 15:31, Daniel Axtens wrote:
> I want _all_ grub code to reach a minimum standard of not crashing or
> corrupting memory in the presence of malicious input. HFS does not reach
> that standard.

I surely understand that although it sounds a little academic to me.

> Whether or not the HFS module could be omitted from a signed binary
> doesn't really bear on the fact that there are bugs in the code, the
> presence of bugs has been publicly known for over 18 months (see commit
> 1c15848838d9) and no-one has shown any intention of fixing the bugs.

Well, I wasn't fully aware of the situation. I am not doing GRUB work
professionally, it's just one of the many projects I sometimes touch.

> If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
> clean, then that'd be great. If no-one is able to bring it up to what is
> *not* an especially high standard, then it should be considered
> abandoned by developers and therefore removed.

Sometimes code just works as-is that's why people don't complain.

> (And as I said in another email, HFS has in fact been built in to a
> signed binary recently. Module-based protection is great in theory but
> this example demonstrates that it falls down in practice.)

Isn't it up to the distributions what they support and what not?

>>> Have you checked that you can't boot them with HFS+? Because HFS+
>>> came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
>>> I'd be really surprised if the firmware didn't support booting from
>>> HFS+. I'd be very keen to hear.
>>
>> I have not tested that due to lack of time. The problem is that some early
>> firmware versions might have issues with HFS+ that we haven't verified
>> yet.
> 
> Any approach that says 'we must wait for test results for very old macs'
> puts the grub community in a bind. I'm not aware of anyone else stepping
> up to contribute test results on old macs, and I can't go across to an
> apple store and buy one. So in order to test this, the entire grub
> upstream stalls on (AFAICT) you personally.
> 
> This not the first time we find ourselves in this situation either.  For
> example, RH is carrying the 'powerpc-ieee1275: support larger core.elf
> images' series out of tree because they need it to boot on modern Power
> boxes. It broke on your machine in a way no-one else has reproduced, and
> I last emailled you asking for more information to debug the failure in
> May.

Well, I have tested the things you asked me to test. And besides that it didn't
work, I don't that we agreed on something else.

I am not the only one using it on old Macs, it's just me who is on this mailing
list. It's not like everyone using any software in the Linux world is subscribed
to any project's mailing list. I don't understand why some people assume that.

People will just at some point complain that it no longer works when they upgrade
their software running their distributions.

> For me, this is not a desirable, sustainable, or acceptable
> situation. For the project to sustainably support 24 year old macs, we
> need more than the tests you do in your free time.

Well, GRUB is supposed to be a universal bootloader, isn't it?

> Finally and in conclusion:
> 
>> What's wrong with retrocomputing? Debian's popcon currently reports more
>> machines running the 32-bit big-endian Debian port than the 64-bit little
>> endian port, see [1].
> 
> I have no complaint with running _old_ software on old hardware. That's
> a cool hobby and an important part of preserving the history of computing.
> 
> My complaint about running _new_ grub on very old hardware is that the
> inaccessibility of said hardware and the lack of a well-resourced

I don't think PowerMacs are really that inaccessible, are they? They are
usually easy to buy off eBay and other used hardware platforms.

The problem with removing hardware support is that you are continuously
making it harder to run software on these machines which would otherwise
run fine up to a point where it breaks rendering all the work that people
have poured into keeping these ports working useless.

POWER hardware is usually rather expensive, so PowerMacs are usually the
only kind of PowerPC hardware that most people can afford.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
@ 2022-08-26 15:46         ` John Paul Adrian Glaubitz
  2022-08-26 17:02           ` Vladimir 'phcoder' Serbinenko
  0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-26 15:46 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko; +Cc: The development of GNU GRUB

Hi Vladimir!

On 8/19/22 21:01, Vladimir 'phcoder' Serbinenko wrote:
> But booting old machines is still desirable for GRUB. Is there a reason why
> HFS is actively bad for modern machines? Especially if it's disabled in case
> of lockdown.
>
> Can I have more details about your security concerns? I may consider rewriting
> parts of HFS code to improve it.

FWIW, in case you would be really interested on improving the HFS code, it should
be no problem to collect some funds in the PowerPC community to financially support
that task, e.g. through a Bountysource campaign.

We have done this in the past to support similar projects in GCC and LLVM.

What do you think?

Thanks,
Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 15:46         ` John Paul Adrian Glaubitz
@ 2022-08-26 17:02           ` Vladimir 'phcoder' Serbinenko
  0 siblings, 0 replies; 26+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2022-08-26 17:02 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: The development of GNU GRUB

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

Le ven. 26 août 2022, 17:46, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> a écrit :

> Hi Vladimir!
>
> On 8/19/22 21:01, Vladimir 'phcoder' Serbinenko wrote:
> > But booting old machines is still desirable for GRUB. Is there a reason
> why
> > HFS is actively bad for modern machines? Especially if it's disabled in
> case
> > of lockdown.
> >
> > Can I have more details about your security concerns? I may consider
> rewriting
> > parts of HFS code to improve it.
>
> FWIW, in case you would be really interested on improving the HFS code, it
> should
> be no problem to collect some funds in the PowerPC community to
> financially support
> that task, e.g. through a Bountysource campaign.
>
> We have done this in the past to support similar projects in GCC and LLVM.
>
> What do you think?
>
I have checked HFS code in general and it looks pretty neat safe for few
bugs like cache collision. If I can get these fuses I can probably fix
them. I'm currently on weekend and my laptop has died but I can have a look
using my phone + VPS

>
> Thanks,
> Adrian
>
> --
>   .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
>

[-- Attachment #2: Type: text/html, Size: 1854 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 13:31         ` Daniel Axtens
  2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
  2022-08-26 15:27           ` John Paul Adrian Glaubitz
@ 2022-08-30 16:37           ` Robbie Harwood
  2022-08-30 17:21             ` John Paul Adrian Glaubitz
  2 siblings, 1 reply; 26+ messages in thread
From: Robbie Harwood @ 2022-08-30 16:37 UTC (permalink / raw)
  To: Daniel Axtens, John Paul Adrian Glaubitz; +Cc: The development of GNU GRUB

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

Daniel Axtens <dja@axtens.net> writes:

>>> Have you checked that you can't boot them with HFS+? Because HFS+
>>> came in 1998, which was (AFAICT) pretty early on in the G3
>>> lifecycle. So I'd be really surprised if the firmware didn't support
>>> booting from HFS+. I'd be very keen to hear.
>>
>> I have not tested that due to lack of time. The problem is that some
>> early firmware versions might have issues with HFS+ that we haven't
>> verified yet.
>
> Any approach that says 'we must wait for test results for very old
> macs' puts the grub community in a bind. I'm not aware of anyone else
> stepping up to contribute test results on old macs, and I can't go
> across to an apple store and buy one. So in order to test this, the
> entire grub upstream stalls on (AFAICT) you personally.
>
> This not the first time we find ourselves in this situation either.
> For example, RH is carrying the 'powerpc-ieee1275: support larger
> core.elf images' series out of tree because they need it to boot on
> modern Power boxes. It broke on your machine in a way no-one else has
> reproduced, and I last emailled you asking for more information to
> debug the failure in May.

As the person currently responsible for the Red Hat tree: I am also not
happy about this state of affairs.

If a use case is to be supported, someone needs to actually do the leg
work to support it.  Bug reports are all well and good, but if no one's
actually able to fix them, they're just making a pile that's in the way.
What I mean is this: right now the project has people (you) *testing*
power macs, but no one actually *fixing* power macs, and unless someone
starts fixing problems that materialize, it's at odds with reality to
call it a supported platform.  (And to be clear here, problems that
materialize includes other people's patches, and debugging/sending fixes
to them as would be expected from a subject matter expert.)

As you point out downthread, I could go out and spend money on a vintage
mac almost as old as I am to attempt to debug the problem myself.  (This
money would have to be my own, because Red Hat, RHEL, and Fedora are all
uninterested in supporting power macs.)  I would then have to learn the
ins and outs of a platform that the manufacturer has not supported for
about fifteen years.[1]  We're talking about at least a month of my time,
probably more, and that assumes it even reproduces on my machine - which
there's no guarantee of.  (If I did all that, and it didn't, what
then?)

It's time I don't have, and quite frankly it's more important to me to
have grub support currently shipping hardware.  Or I could just take the
POWER patches from Daniel and IBM folks downstream, and keep a platform
that customers care about working.  This takes very little of my time in
comparison, but fails to heal the current divergence.

Be well,
--Robbie

1: Having grown up with these beige boxes, I did previously owned an
   iBook G3 on which I did run Linux - but have not in this decade (as
   it is far from a capable computing platform in the modern era), nor
   would I have been able to debug it at the time.  I do still use the
   AEK & AEK II as daily drivers, though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-30 16:37           ` Robbie Harwood
@ 2022-08-30 17:21             ` John Paul Adrian Glaubitz
  2022-08-30 18:43               ` Robbie Harwood
  0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2022-08-30 17:21 UTC (permalink / raw)
  To: Robbie Harwood, Daniel Axtens; +Cc: The development of GNU GRUB

On 8/30/22 18:37, Robbie Harwood wrote:
> As the person currently responsible for the Red Hat tree: I am also not
> happy about this state of affairs.

I don't want to sound rude, but GRUB isn't a RedHat-only project, it's a
community project. So, while I understand RH's point of view, I would also
like to ask you to see other people's perspectives.

> If a use case is to be supported, someone needs to actually do the leg
> work to support it.  Bug reports are all well and good, but if no one's
> actually able to fix them, they're just making a pile that's in the way.

Vladimir has asked multiple times for bug reports on the issues and he said,
he would fix them. I also offered that we do a crowd-funding campaign to
fund the development. I would be happy to throw in some money as well.

So, if we could get some report on what needs to be addressed, that would
be great.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
@ 2022-08-30 18:28             ` Robbie Harwood
  2022-09-01 14:01             ` Daniel Axtens
  1 sibling, 0 replies; 26+ messages in thread
From: Robbie Harwood @ 2022-08-30 18:28 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

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

"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:

> Le ven. 26 août 2022, 15:47, Daniel Axtens <dja@axtens.net> a écrit :
>
>> Let me answer this out of order.
>>
>>> I understand the need to sometimes get rid of old code, but since
>>> the HFS module can be blacklisted as Vladimir explains, I don't
>>> really understand the reasoning in this particular case.
>>
>> I want _all_ grub code to reach a minimum standard of not crashing or
>> corrupting memory in the presence of malicious input. HFS does not
>> reach that standard.
>
> That is a very high standard. Products with a huge security team like
> Chrome don't reach this standard.

That's not accurate.  See
https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules
(the important parts of which are that Google not only pays out for
fuzzing crashes but provides infrastructure to run your fuzzers on).

>> Whether or not the HFS module could be omitted from a signed binary
>> doesn't really bear on the fact that there are bugs in the code, the
>> presence of bugs has been publicly known for over 18 months (see commit
>> 1c15848838d9) and no-one has shown any intention of fixing the bugs.
>
> That is besides the point of using GRUB on PowerMac or any other
> platform with unsigned bootchain. And for signed bootchains it can be
> blacklisted in the code like it already is. Which problem do you try
> to solve?

Every time there's a CVE found in the project, it reflects poorly on the
project.  I think we both know that that's not really fair - CVEs just
mean the project is being looked at, and are not a measure of quality -
but we're talking about a public perception issue here.  If a project
knows that there are potential security problems in an area of its code,
and not only doesn't take steps to address them but instead actively
resists doing so, it will be assumed to be an unhealthy project - and
rightly so, I think.

>> (And as I said in another email, HFS has in fact been built in to a
>> signed binary recently. Module-based protection is great in theory
>> but this example demonstrates that it falls down in practice.)
>
> Then implement a better module-based security with security attributes
> stored in a special section of the binary how we do with the license
> to allow only EFISB-approved modules to load under lockdown

It is incumbent on those who want HFS support to, you know, work at
supporting HFS.  Telling other people to do it instead does not further
that goal - it just pushes them away.

> It's fine to commit patches that improve for other PPC without waiting for
> PowerMacs. In fact I have often seen benefits from such moves.

Sure, but it is bad practice to commit patches that are known to break a
platform (which is what we're talking about here) without some plan to
handle that going forward.  Specifically, I imagine Daniel Axtens and I
would be happy if the "powerpc-ieee1275: support larger core.elf images"
series landed as-is, but I doubt Adrian would be.

>> This not the first time we find ourselves in this situation either.  For
>> example, RH is carrying the 'powerpc-ieee1275: support larger core.elf
>> images' series out of tree because they need it to boot on modern Power
>> boxes. It broke on your machine in a way no-one else has reproduced, and
>> I last emailled you asking for more information to debug the failure in
>> May.
>
> This can happen with EFI as well. And indeed have. Several times. Should we
> drop EFI support?

That's not how this works, or has worked.  Those who care about EFI work
with maintainers and patch authors to keep their use case operational.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-30 17:21             ` John Paul Adrian Glaubitz
@ 2022-08-30 18:43               ` Robbie Harwood
  0 siblings, 0 replies; 26+ messages in thread
From: Robbie Harwood @ 2022-08-30 18:43 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz, Daniel Axtens; +Cc: The development of GNU GRUB

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

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:

> On 8/30/22 18:37, Robbie Harwood wrote:
>
>> As the person currently responsible for the Red Hat tree: I am also
>> not happy about this state of affairs.
>
> I don't want to sound rude, but GRUB isn't a RedHat-only project, it's a
> community project.

Nowhere in my post did I say I was speaking for grub - the tag at the
top literally says that my post is intended as the Red Hat tree
maintainer.

I'm not an upstream maintainer and it is not reasonable to presume that
I speak for grub, or that my views represent those of the project.

> So, while I understand RH's point of view, I would also like to ask
> you to see other people's perspectives.

If you're going to make claims like this, you need to actually engage
with what others are saying.  Seeing someone else's perspective doesn't
mean you think they're right: it means you're trying to engage with
their viewpoint in order to reach consensus.  I do not see engagement
with my viewpoint from you, and meanwhile I'm trying to engage with
yours.

>> If a use case is to be supported, someone needs to actually do the
>> leg work to support it.  Bug reports are all well and good, but if no
>> one's actually able to fix them, they're just making a pile that's in
>> the way.
>
> Vladimir has asked multiple times for bug reports on the issues and he
> said, he would fix them. I also offered that we do a crowd-funding
> campaign to fund the development. I would be happy to throw in some
> money as well.

That's nice of you to offer, but you should know that those of us
already employed full-time in software will likely be unable to receive
those funds.  It is also not the same thing as having that work get
done.  For my part, I reviewed the original POWER patch and am happy to
review changes to make it powermac compatible.

> So, if we could get some report on what needs to be addressed, that would
> be great.

I think I was pretty clear about this in the part of my message that you
trimmed out, but I'll reiterate just in case: the series Daniel Axtens
and I are talking about is "powerpc-ieee1275: support larger core.elf
images" on which you provided feedback on 2021-11-23.  Daniel Axtens
last asked you on-list for additional debugging information on
2022-05-17, to which you have not replied.  Daniel also indicated in
that post that they are likely at the limit of their ability to debug
the failure regardless.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] Remove HFS support
  2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
  2022-08-30 18:28             ` Robbie Harwood
@ 2022-09-01 14:01             ` Daniel Axtens
  1 sibling, 0 replies; 26+ messages in thread
From: Daniel Axtens @ 2022-09-01 14:01 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:

> Le ven. 26 août 2022, 15:47, Daniel Axtens <dja@axtens.net> a écrit :
>
>> Let me answer this out of order.
>>
>> > I understand the need to sometimes get rid of old code, but since the HFS
>> > module can be blacklisted as Vladimir explains, I don't really understand
>> > the reasoning in this particular case.
>>
>> I want _all_ grub code to reach a minimum standard of not crashing or
>> corrupting memory in the presence of malicious input. HFS does not reach
>> that standard.
>>
> That is a very high standard. Products with a huge security team like
> Chrome don't reach this standard. It's reasonable that you submit the
> improvements. Also it's reasonable for you to blacklist code that gets in
> the way of security. E.g. all compressors that are not used should be
> blacklisted.

ext and fat file systems (and several other more obsure file systems)
and all our image parsers reach this standard, best as I can tell. As
far as I can tell the grub IPv4 networking stack does too, although I am
not as certain that my coverage was very thorough.

Several of us are actively working to get all of grub to this
standard. grub is a lot simpler than Chrome, so I am optimistic.

>> If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
>> clean, then that'd be great. If no-one is able to bring it up to what is
>> *not* an especially high standard, then it should be considered
>> abandoned by developers and therefore removed.
>>
> Show me the fuzzes that create problems and I'll improve the code

The following two files cause crashes on stock grub-fstest

stack overflow (unbounded recursion): files.intermittent.network/grub/hfs.stack-overflow
stack buffer overflow -> eventual segv: files.intermittent.network/grub/hfs.stack-buffer-overflow

There are an additional set of files that cause crashes when grub is
compiled with ASAN:

files.intermittent.network/grub/hfs.tar.xz (18MB, 210MB uncompressed)

There are 222 files. The corpus is not de-duplicated (there are not
222 unique bugs) and includes the two files called out above, plus
other some different heap buffer overflows.

I compile grub with ASAN using:
ASAN_OPTIONS=detect_leaks=0 make CFLAGS="-fsanitize=address" -j8

Modern gcc works fine. grub-emu will fail to link, but grub-fstest
should build fine.

In all cases, the crashes reproduce with:

./grub-fstest <file> ls '(loop0)/'

Good luck, the stack-overflow one in particular looks especially
painful.

I will leave your other points for others to address. 

Kind regards,
Daniel


^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2022-09-01 14:01 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-19 13:38 [PATCH] Remove HFS support Daniel Axtens
2022-08-19 13:57 ` Daniel Kiper
2022-08-19 14:03   ` John Paul Adrian Glaubitz
2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:23       ` Daniel Axtens
2022-08-19 18:09     ` Steve McIntyre
2022-08-19 18:38       ` John Paul Adrian Glaubitz
2022-08-19 19:04         ` Dimitri John Ledkov
2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:05             ` Daniel Axtens
2022-08-24  7:17             ` John Paul Adrian Glaubitz
2022-08-24  7:16           ` John Paul Adrian Glaubitz
2022-08-20 14:13         ` Daniel Axtens
2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
2022-08-26 15:46         ` John Paul Adrian Glaubitz
2022-08-26 17:02           ` Vladimir 'phcoder' Serbinenko
2022-08-20 13:53     ` Daniel Axtens
2022-08-24  7:21       ` John Paul Adrian Glaubitz
2022-08-26 13:31         ` Daniel Axtens
2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
2022-08-30 18:28             ` Robbie Harwood
2022-09-01 14:01             ` Daniel Axtens
2022-08-26 15:27           ` John Paul Adrian Glaubitz
2022-08-30 16:37           ` Robbie Harwood
2022-08-30 17:21             ` John Paul Adrian Glaubitz
2022-08-30 18:43               ` Robbie Harwood

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.