1. 24 Jun, 2022 2 commits
  2. 11 Jun, 2022 1 commit
    • Kirk McKusick's avatar
      Bug fix to UFS/FFS superblock integrity checks when reading a superblock. · 800a53b4
      Kirk McKusick authored
      One of the checks was that the cylinder group size (fs_cgsize)
      matched that calculated by CGSIZE(). The value calculated by CGSIZE()
      has changed over time as the filesystem has evolved. Thus comparing
      the value of CGSIZE() of the current generation filesystem may not
      match the size as computed by CGSIZE() that was in effect at the
      time an older filesystem was created. Therefore the check for
      fs_cgsize is changed to simply ensure that it is not larger than
      the filesystem blocksize (fs_bsize).
      
      Reported by: Martin Birgmeier
      Tested by:   Martin Birgmeier
      MFC after:   1 month (with 076002f2)
      PR:          264450
      Differential Revision: https://reviews.freebsd.org/D35219
      800a53b4
  3. 01 Jun, 2022 1 commit
    • Kirk McKusick's avatar
      Two bug fixes to UFS/FFS superblock integrity checks when reading a superblock. · bc218d89
      Kirk McKusick authored
      Two bugs have been reported with the UFS/FFS superblock integrity
      checks that were added in commit 076002f2.
      
      The code checked that fs_sblockactualloc was properly set to the
      location of the superblock. The fs_sblockactualloc field was an
      addition to the superblock in commit dffce215 on Jan 26 2018
      and used a field that was zero in filesystems created before it
      was added. The integrity check had to be expanded to accept the
      fs_sblockactualloc field being zero so as not to reject filesystems
      created before Jan 26 2018.
      
      The integrity check set an upper bound on the value of fs_maxcontig
      based on the maximum transfer size supported by the kernel. It
      required that fs->fs_maxcontig <= maxphys / fs->fs_bsize. The kernel
      variable maxphys defines the maximum transfer size permitted by the
      controllers and/or buffering. The fs_maxcontig parameter controls the
      maximum number of blocks that the filesystem will read or write in
      a single transfer. It is calculated when the filesystem is created
      as maxphys / fs_bsize. The bug appeared in the loader because it
      uses a maxphys of 128K even when running on a system that supports
      larger values. If the filesystem was built on a system that supports
      a larger maxphys (1M is typical) it will have configured fs_maxcontig
      for that larger system so would fail the test when run with the smaller
      maxphys used by the loader. So we bound the upper allowable limit
      for fs_maxconfig to be able to at least work with a 1M maxphys on the
      smallest block size filesystem: 1M / 4096 == 256. We then use the
      limit for fs_maxcontig as fs_maxcontig <= MAX(256, maxphys / fs_bsize).
      There is no harm in allowing the mounting of filesystems that make larger
      than maxphys I/O requests because those (mostly 32-bit machines) can
      (very slowly) handle I/O requests that exceed maxphys.
      
      Thanks to everyone who helped sort out the problems and the fixes.
      
      Reported by:  Cy Schubert, David Wolfskill
      Diagnosis by: Mark Johnston, John Baldwin
      Reviewed by:  Warner Losh
      Tested by:    Cy Schubert, David Wolfskill
      MFC after:    1 month (with 076002f2)
      Differential Revision: https://reviews.freebsd.org/D35219
      bc218d89
  4. 27 May, 2022 1 commit
    • Kirk McKusick's avatar
      Do comprehensive UFS/FFS superblock integrity checks when reading a superblock. · 076002f2
      Kirk McKusick authored
      Historically only minimal checks were made of a superblock when it
      was read in as it was assumed that fsck would have been run to
      correct any errors before attempting to use the filesystem. Recently
      several bug reports have been submitted reporting kernel panics
      that can be triggered by deliberately corrupting filesystem superblocks,
      see Bug 263979 - [meta] UFS / FFS / GEOM crash (panic) tracking
      which is tracking the reported corruption bugs.
      
      This change upgrades the checks that are performed. These additional
      checks should prevent panics from a corrupted superblock. Although
      it appears in only one place, the new code will apply to the kernel
      modules and (through libufs) user applications that read in superblocks.
      
      Reported by:  Robert Morris and Neeraj
      Reviewed by:  kib
      Tested by:    Peter Holm
      PR:           263979
      MFC after:    1 month
      Differential Revision: https://reviews.freebsd.org/D35219
      076002f2
  5. 15 May, 2022 1 commit
  6. 10 Jan, 2022 1 commit
    • Kirk McKusick's avatar
      Avoid unnecessary setting of UFS flag requesting fsck(8) be run. · 7ef56fb0
      Kirk McKusick authored
      When the kernel is requested to mount a filesystem with a bad superblock
      check hash, it would set the flag in the superblock requesting that the
      fsck(8) program be run. The flag is only written to disk as part of a
      superblock update. Since the superblock always has its check hash updated
      when it is written to disk, the problem for which the flag has been set
      will no longer exist. Hence, it is counter-productive to set the flag
      as it will just cause an unnecessary run of fsck if it ever gets written.
      
      Sponsored by: Netflix
      7ef56fb0
  7. 16 Nov, 2021 1 commit
  8. 15 Nov, 2021 2 commits
    • Kirk McKusick's avatar
      Add ability to suppress UFS/FFS superblock check-hash failure messages. · f2b39152
      Kirk McKusick authored
      When reading UFS/FFS superblocks that have check hashes, both the kernel
      and libufs print an error message if the check hash is incorrect. This
      commit adds the ability to request that the error message not be made.
      It is intended for use by programs like fsck that wants to print its
      own error message and by kernel subsystems like glabel that just wants
      to check for possible filesystem types.
      
      This capability will be used in followup commits.
      
      Sponsored by: Netflix
      f2b39152
    • Kirk McKusick's avatar
      Consolodate four copies of the STDSB define into a single place. · b366ee48
      Kirk McKusick authored
      The STDSB macro is passed to the ffs_sbget() routine to fetch a
      UFS/FFS superblock "from the stadard place". It was identically defined
      in lib/libufs/libufs.h, stand/libsa/ufs.c, sys/ufs/ffs/ffs_extern.h,
      and sys/ufs/ffs/ffs_subr.c. Delete it from these four files and
      define it instead in sys/ufs/ffs/fs.h. All existing uses of this macro
      already include sys/ufs/ffs/fs.h so no include changes need to be made.
      
      No functional change intended.
      
      Sponsored by: Netflix
      b366ee48
  9. 25 Oct, 2020 2 commits
    • mckusick's avatar
      Various new check-hash checks have been added to the UFS filesystem · 5ce3cee7
      mckusick authored
      over various major releases. Superblock check hashes were added for
      the 12 release and cylinder-group and inode check hashes will appear
      in the 13 release.
      
      When a disk with a UFS filesystem is writably mounted, the kernel
      clears the feature flags for anything that it does not support. For
      example, if a UFS disk from a 12-stable kernel is mounted on an
      11-stable system, the 11-stable kernel will clear the flag in the
      filesystem superblock that indicates that superblock check-hashs
      are being maintained. Thus if the disk is later moved back to a
      12-stable system, the 12-stable system will know to ignore its
      incorrect check-hash.
      
      If the only filesystem modification done on the earlier kernel is
      to run a utility such as growfs(8) that modifies the superblock but
      neither updates the check-hash nor clears the feature flag indicating
      that it does not support the check-hash, the disk will fail to mount
      if it is moved back to its original newer kernel.
      
      This patch moves the code that clears the filesystem feature flags
      from the mount code (ffs_mountfs()) to the code that reads the
      superblock (ffs_sbget()). As ffs_sbget() is used by the kernel mount
      code and is imported into libufs(3), all the filesystem utilities
      will now also clear these flags when they make modifications to the
      filesystem.
      
      As suggested by John Baldwin, fsck_ffs(8) has been changed to accept
      and repair bad superblock check-hashes rather than refusing to run.
      This change allows fsck to recover filesystems that have been impacted
      by utilities older than those created after this change and is a
      sensible thing to do in any event.
      
      Reported by:  John Baldwin (jhb@)
      MFC after:    2 weeks
      Sponsored by: Netflix
      5ce3cee7
    • Kirk McKusick's avatar
      Various new check-hash checks have been added to the UFS filesystem · 996d40f9
      Kirk McKusick authored
      over various major releases. Superblock check hashes were added for
      the 12 release and cylinder-group and inode check hashes will appear
      in the 13 release.
      
      When a disk with a UFS filesystem is writably mounted, the kernel
      clears the feature flags for anything that it does not support. For
      example, if a UFS disk from a 12-stable kernel is mounted on an
      11-stable system, the 11-stable kernel will clear the flag in the
      filesystem superblock that indicates that superblock check-hashs
      are being maintained. Thus if the disk is later moved back to a
      12-stable system, the 12-stable system will know to ignore its
      incorrect check-hash.
      
      If the only filesystem modification done on the earlier kernel is
      to run a utility such as growfs(8) that modifies the superblock but
      neither updates the check-hash nor clears the feature flag indicating
      that it does not support the check-hash, the disk will fail to mount
      if it is moved back to its original newer kernel.
      
      This patch moves the code that clears the filesystem feature flags
      from the mount code (ffs_mountfs()) to the code that reads the
      superblock (ffs_sbget()). As ffs_sbget() is used by the kernel mount
      code and is imported into libufs(3), all the filesystem utilities
      will now also clear these flags when they make modifications to the
      filesystem.
      
      As suggested by John Baldwin, fsck_ffs(8) has been changed to accept
      and repair bad superblock check-hashes rather than refusing to run.
      This change allows fsck to recover filesystems that have been impacted
      by utilities older than those created after this change and is a
      sensible thing to do in any event.
      
      Reported by:  John Baldwin (jhb@)
      MFC after:    2 weeks
      Sponsored by: Netflix
      996d40f9
  10. 01 Sep, 2020 2 commits
  11. 19 Jun, 2020 4 commits
    • mckusick's avatar
      The binary representation of the superblock (the fs structure) is written · cfac6b7d
      mckusick authored
      out verbatim to the disk: see ffs_sbput() in sys/ufs/ffs/ffs_subr.c.
      It contains a pointer to the fs_summary_info structure. This pointer
      value inadvertently causes garbage to be stored. It is garbage because
      the pointer to the fs_summary_info structure is the address the then
      current stack or heap. Although a mere pointer does not reveal anything
      useful (like a part of a private key) to an attacker, garbage output
      deteriorates reproducibility.
      
      This commit zeros out the pointer to the fs_summary_info structure
      before writing the out the superblock.
      
      Reviewed by:  kib
      Tested by:    Peter Holm
      PR:           246983
      Sponsored by: Netflix
      cfac6b7d
    • Kirk McKusick's avatar
      The binary representation of the superblock (the fs structure) is written · 93440bbe
      Kirk McKusick authored
      out verbatim to the disk: see ffs_sbput() in sys/ufs/ffs/ffs_subr.c.
      It contains a pointer to the fs_summary_info structure. This pointer
      value inadvertently causes garbage to be stored. It is garbage because
      the pointer to the fs_summary_info structure is the address the then
      current stack or heap. Although a mere pointer does not reveal anything
      useful (like a part of a private key) to an attacker, garbage output
      deteriorates reproducibility.
      
      This commit zeros out the pointer to the fs_summary_info structure
      before writing the out the superblock.
      
      Reviewed by:  kib
      Tested by:    Peter Holm
      PR:           246983
      Sponsored by: Netflix
      93440bbe
    • mckusick's avatar
      Move the pointers stored in the superblock into a separate · fc56f5d1
      mckusick authored
      fs_summary_info structure. This change was originally done
      by the CheriBSD project as they need larger pointers that
      do not fit in the existing superblock.
      
      This cleanup of the superblock eases the task of the commit
      that immediately follows this one.
      
      Suggested by: brooks
      Reviewed by:  kib
      PR:           246983
      Sponsored by: Netflix
      fc56f5d1
    • Kirk McKusick's avatar
      Move the pointers stored in the superblock into a separate · 34816cb9
      Kirk McKusick authored
      fs_summary_info structure. This change was originally done
      by the CheriBSD project as they need larger pointers that
      do not fit in the existing superblock.
      
      This cleanup of the superblock eases the task of the commit
      that immediately follows this one.
      
      Suggested by: brooks
      Reviewed by:  kib
      PR:           246983
      Sponsored by: Netflix
      34816cb9
  12. 17 Jun, 2020 2 commits
  13. 25 May, 2020 2 commits
    • chs's avatar
      This commit enables a UFS filesystem to do a forcible unmount when · c18fd016
      chs authored
      the underlying media fails or becomes inaccessible. For example
      when a USB flash memory card hosting a UFS filesystem is unplugged.
      
      The strategy for handling disk I/O errors when soft updates are
      enabled is to stop writing to the disk of the affected file system
      but continue to accept I/O requests and report that all future
      writes by the file system to that disk actually succeed. Then
      initiate an asynchronous forced unmount of the affected file system.
      
      There are two cases for disk I/O errors:
      
         - ENXIO, which means that this disk is gone and the lower layers
           of the storage stack already guarantee that no future I/O to
           this disk will succeed.
      
         - EIO (or most other errors), which means that this particular
           I/O request has failed but subsequent I/O requests to this
           disk might still succeed.
      
      For ENXIO, we can just clear the error and continue, because we
      know that the file system cannot affect the on-disk state after we
      see this error. For EIO or other errors, we arrange for the geom_vfs
      layer to reject all future I/O requests with ENXIO just like is
      done when the geom_vfs is orphaned. In both cases, the file system
      code can just clear the error and proceed with the forcible unmount.
      
      This new treatment of I/O errors is needed for writes of any buffer
      that is involved in a dependency. Most dependencies are described
      by a structure attached to the buffer's b_dep field. But some are
      created and processed as a result of the completion of the dependencies
      attached to the buffer.
      
      Clearing of some dependencies require a read. For example if there
      is a dependency that requires an inode to be written, the disk block
      containing that inode must be read, the updated inode copied into
      place in that buffer, and the buffer then written back to disk.
      
      Often the needed buffer is already in memory and can be used. But
      if it needs to be read from the disk, the read will fail, so we
      fabricate a buffer full of zeroes and pretend that the read succeeded.
      This zero'ed buffer can be updated and written back to disk.
      
      The only case where a buffer full of zeros causes the code to do
      the wrong thing is when reading an inode buffer containing an inode
      that still has an inode dependency in memory that will reinitialize
      the effective link count (i_effnlink) based on the actual link count
      (i_nlink) that we read. To handle this case we now store the i_nlink
      value that we wrote in the inode dependency so that it can be
      restored into the zero'ed buffer thus keeping the tracking of the
      inode link count consistent.
      
      Because applications depend on knowing when an attempt to write
      their data to stable storage has failed, the fsync(2) and msync(2)
      system calls need to return errors if data fails to be written to
      stable storage. So these operations return ENXIO for every call
      made on files in a file system where we have otherwise been ignoring
      I/O errors.
      
      Coauthered by: mckusick
      Reviewed by:   kib
      Tested by:     Peter Holm
      Approved by:   mckusick (mentor)
      Sponsored by:  Netflix
      Differential Revision:  https://reviews.freebsd.org/D24088
      c18fd016
    • Chuck Silvers's avatar
      This commit enables a UFS filesystem to do a forcible unmount when · d79ff54b
      Chuck Silvers authored
      the underlying media fails or becomes inaccessible. For example
      when a USB flash memory card hosting a UFS filesystem is unplugged.
      
      The strategy for handling disk I/O errors when soft updates are
      enabled is to stop writing to the disk of the affected file system
      but continue to accept I/O requests and report that all future
      writes by the file system to that disk actually succeed. Then
      initiate an asynchronous forced unmount of the affected file system.
      
      There are two cases for disk I/O errors:
      
         - ENXIO, which means that this disk is gone and the lower layers
           of the storage stack already guarantee that no future I/O to
           this disk will succeed.
      
         - EIO (or most other errors), which means that this particular
           I/O request has failed but subsequent I/O requests to this
           disk might still succeed.
      
      For ENXIO, we can just clear the error and continue, because we
      know that the file system cannot affect the on-disk state after we
      see this error. For EIO or other errors, we arrange for the geom_vfs
      layer to reject all future I/O requests with ENXIO just like is
      done when the geom_vfs is orphaned. In both cases, the file system
      code can just clear the error and proceed with the forcible unmount.
      
      This new treatment of I/O errors is needed for writes of any buffer
      that is involved in a dependency. Most dependencies are described
      by a structure attached to the buffer's b_dep field. But some are
      created and processed as a result of the completion of the dependencies
      attached to the buffer.
      
      Clearing of some dependencies require a read. For example if there
      is a dependency that requires an inode to be written, the disk block
      containing that inode must be read, the updated inode copied into
      place in that buffer, and the buffer then written back to disk.
      
      Often the needed buffer is already in memory and can be used. But
      if it needs to be read from the disk, the read will fail, so we
      fabricate a buffer full of zeroes and pretend that the read succeeded.
      This zero'ed buffer can be updated and written back to disk.
      
      The only case where a buffer full of zeros causes the code to do
      the wrong thing is when reading an inode buffer containing an inode
      that still has an inode dependency in memory that will reinitialize
      the effective link count (i_effnlink) based on the actual link count
      (i_nlink) that we read. To handle this case we now store the i_nlink
      value that we wrote in the inode dependency so that it can be
      restored into the zero'ed buffer thus keeping the tracking of the
      inode link count consistent.
      
      Because applications depend on knowing when an attempt to write
      their data to stable storage has failed, the fsync(2) and msync(2)
      system calls need to return errors if data fails to be written to
      stable storage. So these operations return ENXIO for every call
      made on files in a file system where we have otherwise been ignoring
      I/O errors.
      
      Coauthered by: mckusick
      Reviewed by:   kib
      Tested by:     Peter Holm
      Approved by:   mckusick (mentor)
      Sponsored by:  Netflix
      Differential Revision:  https://reviews.freebsd.org/D24088
      d79ff54b
  14. 11 Mar, 2020 2 commits
  15. 06 Sep, 2019 2 commits
  16. 17 Jul, 2019 2 commits
    • mckusick's avatar
      The error reported in FS-14-UFS-3 can only happen on UFS/FFS · eb5503c1
      mckusick authored
      filesystems that have block pointers that are out-of-range for their
      filesystem. These out-of-range block pointers are corrected by
      fsck(8) so are only encountered when an unchecked filesystem is
      mounted.
      
      A new "untrusted" flag has been added to the generic mount interface
      that can be set when mounting media of unknown provenance or integrity.
      For example, a daemon that automounts a filesystem on a flash drive
      when it is plugged into a system.
      
      This commit adds a test to UFS/FFS that validates all block numbers
      before using them. Because checking for out-of-range blocks adds
      unnecessary overhead to normal operation, the tests are only done
      when the filesystem is mounted as an "untrusted" filesystem.
      
      Reported by:  Christopher Krah, Thomas Barabosch, and Jan-Niclas Hilgert of Fraunhofer FKIE
      Reported as:  FS-14-UFS-3: Out of bounds read in write-2 (ffs_alloccg)
      Reviewed by:  kib
      Sponsored by: Netflix
      eb5503c1
    • Kirk McKusick's avatar
      The error reported in FS-14-UFS-3 can only happen on UFS/FFS · fdf34aa3
      Kirk McKusick authored
      filesystems that have block pointers that are out-of-range for their
      filesystem. These out-of-range block pointers are corrected by
      fsck(8) so are only encountered when an unchecked filesystem is
      mounted.
      
      A new "untrusted" flag has been added to the generic mount interface
      that can be set when mounting media of unknown provenance or integrity.
      For example, a daemon that automounts a filesystem on a flash drive
      when it is plugged into a system.
      
      This commit adds a test to UFS/FFS that validates all block numbers
      before using them. Because checking for out-of-range blocks adds
      unnecessary overhead to normal operation, the tests are only done
      when the filesystem is mounted as an "untrusted" filesystem.
      
      Reported by:  Christopher Krah, Thomas Barabosch, and Jan-Niclas Hilgert of Fraunhofer FKIE
      Reported as:  FS-14-UFS-3: Out of bounds read in write-2 (ffs_alloccg)
      Reviewed by:  kib
      Sponsored by: Netflix
      fdf34aa3
  17. 17 Jun, 2019 2 commits
  18. 15 Dec, 2018 6 commits
    • mckusick's avatar
      Ensure that the inode check-hash is not left zeroed out in the case where · bfbf739a
      mckusick authored
      the check-hash fails. Prior to the fix in -r342133 the inode with the
      zeroed out check-hash was written back to disk causing further confusion.
      
      Reported by:  Gary Jennejohn (gj)
      Sponsored by: Netflix
      bfbf739a
    • Kirk McKusick's avatar
      Ensure that the inode check-hash is not left zeroed out in the case where · c8f55fc4
      Kirk McKusick authored
      the check-hash fails. Prior to the fix in -r342133 the inode with the
      zeroed out check-hash was written back to disk causing further confusion.
      
      Reported by:  Gary Jennejohn (gj)
      Sponsored by: Netflix
      c8f55fc4
    • mckusick's avatar
      Reorder ffs_verify_dinode_ckhash() so that it checks the inode check-hash · b27d4425
      mckusick authored
      before copying in the inode so that the mode and link-count are not set
      if the check-hash fails. This change ensures that the vnode will be properly
      unwound and recycled rather than being held in the cache.
      
      Initialize the file mode is zero so that if the loading of the inode
      fails (for example because of a check-hash failure), the vnode will be
      properly unwound and recycled.
      
      Reported by:  Gary Jennejohn (gj)
      Sponsored by: Netflix
      b27d4425
    • Kirk McKusick's avatar
      Reorder ffs_verify_dinode_ckhash() so that it checks the inode check-hash · 72d28f97
      Kirk McKusick authored
      before copying in the inode so that the mode and link-count are not set
      if the check-hash fails. This change ensures that the vnode will be properly
      unwound and recycled rather than being held in the cache.
      
      Initialize the file mode is zero so that if the loading of the inode
      fails (for example because of a check-hash failure), the vnode will be
      properly unwound and recycled.
      
      Reported by:  Gary Jennejohn (gj)
      Sponsored by: Netflix
      72d28f97
    • mckusick's avatar
      Must set ip->i_effnlink = ip->i_nlink to avoid a soft updates · c376c836
      mckusick authored
      "panic: softdep_update_inodeblock: bad link count" when releasing
      a partially initialized vnode after an inode check-hash failure.
      
      Reported by:  Gary Jennejohn <gljennjohn@gmail.com>
      Reported by:  Peter Holm (pho)
      Sponsored by: Netflix
      c376c836
    • Kirk McKusick's avatar
      Must set ip->i_effnlink = ip->i_nlink to avoid a soft updates · 6fa9bc99
      Kirk McKusick authored
      "panic: softdep_update_inodeblock: bad link count" when releasing
      a partially initialized vnode after an inode check-hash failure.
      
      Reported by:  Gary Jennejohn <gljennjohn@gmail.com>
      Reported by:  Peter Holm (pho)
      Sponsored by: Netflix
      6fa9bc99
  19. 11 Dec, 2018 2 commits
    • mckusick's avatar
      Continuing efforts to provide hardening of FFS. This change adds a · 830a63af
      mckusick authored
      check hash to the filesystem inodes. Access attempts to files
      associated with an inode with an invalid check hash will fail with
      EINVAL (Invalid argument). Access is reestablished after an fsck
      is run to find and validate the inodes with invalid check-hashes.
      This check avoids a class of filesystem panics related to corrupted
      inodes. The hash is done using crc32c.
      
      Note this check-hash is for the inode itself and not any of its
      indirect blocks. Check-hash validation may be extended to also
      cover indirect block pointers, but that will be a separate (and
      more costly) feature.
      
      Check hashes are added only to UFS2 and not to UFS1 as UFS1 is
      primarily used in embedded systems with small memories and low-powered
      processors which need as light-weight a filesystem as possible.
      
      Reviewed by:  kib
      Tested by:    Peter Holm
      Sponsored by: Netflix
      830a63af
    • Kirk McKusick's avatar
      Continuing efforts to provide hardening of FFS. This change adds a · 8f829a5c
      Kirk McKusick authored
      check hash to the filesystem inodes. Access attempts to files
      associated with an inode with an invalid check hash will fail with
      EINVAL (Invalid argument). Access is reestablished after an fsck
      is run to find and validate the inodes with invalid check-hashes.
      This check avoids a class of filesystem panics related to corrupted
      inodes. The hash is done using crc32c.
      
      Note this check-hash is for the inode itself and not any of its
      indirect blocks. Check-hash validation may be extended to also
      cover indirect block pointers, but that will be a separate (and
      more costly) feature.
      
      Check hashes are added only to UFS2 and not to UFS1 as UFS1 is
      primarily used in embedded systems with small memories and low-powered
      processors which need as light-weight a filesystem as possible.
      
      Reviewed by:  kib
      Tested by:    Peter Holm
      Sponsored by: Netflix
      8f829a5c
  20. 06 Dec, 2018 2 commits
    • mckusick's avatar
      Normally when an attempt is made to mount a UFS/FFS filesystem whose · 2c9178ed
      mckusick authored
      superblock has a check-hash error, an error message noting the
      superblock check-hash failure is printed and the mount fails. The
      administrator then runs fsck to repair the filesystem and when
      successful, the filesystem can once again be mounted.
      
      This approach fails if the filesystem in question is a root filesystem
      from which you are trying to boot. Here, the loader fails when trying
      to access the filesystem to get the kernel to boot. So it is necessary
      to allow the loader to ignore the superblock check-hash error and make
      a best effort to read the kernel. The filesystem may be suffiently
      corrupted that the read attempt fails, but there is no harm in trying
      since the loader makes no attempt to write to the filesystem.
      
      Once the kernel is loaded and starts to run, it attempts to mount its
      root filesystem. Once again, failure means that it breaks to its prompt
      to ask where to get its root filesystem. Unless you have an alternate
      root filesystem, you are stuck.
      
      Since the root filesystem is initially mounted read-only, it is
      safe to make an attempt to mount the root filesystem with the failed
      superblock check-hash. Thus, when asked to mount a root filesystem
      with a failed superblock check-hash, the kernel prints a warning
      message that the root filesystem superblock check-hash needs repair,
      but notes that it is ignoring the error and proceeding. It does
      mark the filesystem as needing an fsck which prevents it from being
      enabled for writing until fsck has been run on it. The net effect
      is that the reboot fails to single user, but at least at that point
      the administrator has the tools at hand to fix the problem.
      
      Reported by:    Rick Macklem (rmacklem@)
      Discussed with: Warner Losh (imp@)
      Sponsored by:   Netflix
      2c9178ed
    • Kirk McKusick's avatar
      Normally when an attempt is made to mount a UFS/FFS filesystem whose · fb14e73c
      Kirk McKusick authored
      superblock has a check-hash error, an error message noting the
      superblock check-hash failure is printed and the mount fails. The
      administrator then runs fsck to repair the filesystem and when
      successful, the filesystem can once again be mounted.
      
      This approach fails if the filesystem in question is a root filesystem
      from which you are trying to boot. Here, the loader fails when trying
      to access the filesystem to get the kernel to boot. So it is necessary
      to allow the loader to ignore the superblock check-hash error and make
      a best effort to read the kernel. The filesystem may be suffiently
      corrupted that the read attempt fails, but there is no harm in trying
      since the loader makes no attempt to write to the filesystem.
      
      Once the kernel is loaded and starts to run, it attempts to mount its
      root filesystem. Once again, failure means that it breaks to its prompt
      to ask where to get its root filesystem. Unless you have an alternate
      root filesystem, you are stuck.
      
      Since the root filesystem is initially mounted read-only, it is
      safe to make an attempt to mount the root filesystem with the failed
      superblock check-hash. Thus, when asked to mount a root filesystem
      with a failed superblock check-hash, the kernel prints a warning
      message that the root filesystem superblock check-hash needs repair,
      but notes that it is ignoring the error and proceeding. It does
      mark the filesystem as needing an fsck which prevents it from being
      enabled for writing until fsck has been run on it. The net effect
      is that the reboot fails to single user, but at least at that point
      the administrator has the tools at hand to fix the problem.
      
      Reported by:    Rick Macklem (rmacklem@)
      Discussed with: Warner Losh (imp@)
      Sponsored by:   Netflix
      fb14e73c