Skip to content
Snippets Groups Projects
  1. Jan 03, 2022
    • Song Liu's avatar
      md/raid1: fix missing bitmap update w/o WriteMostly devices · 46669e86
      Song Liu authored
      
      commit [1] causes missing bitmap updates when there isn't any WriteMostly
      devices.
      
      Detailed steps to reproduce by Norbert (which somehow didn't make to lore):
      
         # setup md10 (raid1) with two drives (1 GByte sparse files)
         dd if=/dev/zero of=disk1 bs=1024k seek=1024 count=0
         dd if=/dev/zero of=disk2 bs=1024k seek=1024 count=0
      
         losetup /dev/loop11 disk1
         losetup /dev/loop12 disk2
      
         mdadm --create /dev/md10 --level=1 --raid-devices=2 /dev/loop11 /dev/loop12
      
         # add bitmap (aka write-intent log)
         mdadm /dev/md10 --grow --bitmap=internal
      
         echo check > /sys/block/md10/md/sync_action
      
         root:# cat /sys/block/md10/md/mismatch_cnt
         0
         root:#
      
         # remove member drive disk2 (loop12)
         mdadm /dev/md10 -f loop12 ; mdadm /dev/md10 -r loop12
      
         # modify degraded md device
         dd if=/dev/urandom of=/dev/md10 bs=512 count=1
      
         # no blocks recorded as out of sync on the remaining member disk1/loop11
         root:# mdadm -X /dev/loop11 | grep Bitmap
                   Bitmap : 16 bits (chunks), 0 dirty (0.0%)
         root:#
      
         # re-add disk2, nothing synced because of empty bitmap
         mdadm /dev/md10 --re-add /dev/loop12
      
         # check integrity again
         echo check > /sys/block/md10/md/sync_action
      
         # disk1 and disk2 are no longer in sync, reads return differend data
         root:# cat /sys/block/md10/md/mismatch_cnt
         128
         root:#
      
         # clean up
         mdadm -S /dev/md10
         losetup -d /dev/loop11
         losetup -d /dev/loop12
         rm disk1 disk2
      
      Fix this by moving the WriteMostly check to the if condition for
      alloc_behind_master_bio().
      
      [1] commit fd3b6975 ("md/raid1: only allocate write behind bio for WriteMostly device")
      Fixes: fd3b6975 ("md/raid1: only allocate write behind bio for WriteMostly device")
      Cc: stable@vger.kernel.org # v5.12+
      Cc: Guoqing Jiang <guoqing.jiang@linux.dev>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reported-by: default avatarNorbert Warmuth <nwarmuth@t-online.de>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      46669e86
  2. Dec 15, 2021
    • Mike Snitzer's avatar
      dm integrity: fix data corruption due to improper use of bvec_kmap_local · 1cef171a
      Mike Snitzer authored
      
      Commit 25058d1c ("dm integrity: use bvec_kmap_local in
      __journal_read_write") didn't account for __journal_read_write() later
      adding the biovec's bv_offset. As such using bvec_kmap_local() caused
      the start of the biovec to be skipped.
      
      Trivial test that illustrates data corruption:
      
        # integritysetup format /dev/pmem0
        # integritysetup open /dev/pmem0 integrityroot
        # mkfs.xfs /dev/mapper/integrityroot
        ...
        bad magic number
        bad magic number
        Metadata corruption detected at xfs_sb block 0x0/0x1000
        libxfs_writebufr: write verifer failed on xfs_sb bno 0x0/0x1000
        releasing dirty buffer (bulk) to free list!
      
      Fix this by using kmap_local_page() instead of bvec_kmap_local() in
      __journal_read_write().
      
      Fixes: 25058d1c ("dm integrity: use bvec_kmap_local in __journal_read_write")
      Reported-by: default avatarTony Asleson <tasleson@redhat.com>
      Reviewed-by: default avatarHeinz Mauelshagen <heinzm@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      1cef171a
    • Lin Feng's avatar
      bcache: fix NULL pointer reference in cached_dev_detach_finish · aa97f6cd
      Lin Feng authored
      
      Commit 0259d449 ("bcache: move calc_cached_dev_sectors to proper
      place on backing device detach") tries to fix calc_cached_dev_sectors
      when bcache device detaches, but now we have:
      
      cached_dev_detach_finish
          ...
          bcache_device_detach(&dc->disk);
              ...
              closure_put(&d->c->caching);
              d->c = NULL; [*explicitly set dc->disk.c to NULL*]
          list_move(&dc->list, &uncached_devices);
          calc_cached_dev_sectors(dc->disk.c); [*passing a NULL pointer*]
          ...
      
      Upper codeflows shows how bug happens, this patch fix the problem by
      caching dc->disk.c beforehand, and cache_set won't be freed under us
      because c->caching closure at least holds a reference count and closure
      callback __cache_set_unregister only being called by bch_cache_set_stop
      which using closure_queue(&c->caching), that means c->caching closure
      callback for destroying cache_set won't be trigger by previous
      closure_put(&d->c->caching).
      So at this stage(while cached_dev_detach_finish is calling) it's safe to
      access cache_set dc->disk.c.
      
      Fixes: 0259d449 ("bcache: move calc_cached_dev_sectors to proper place on backing device detach")
      Signed-off-by: default avatarLin Feng <linf@wangsu.com>
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Link: https://lore.kernel.org/r/20211112053629.3437-2-colyli@suse.de
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      aa97f6cd
  3. Dec 10, 2021
  4. Nov 24, 2021
  5. Nov 08, 2021
  6. Nov 03, 2021
  7. Nov 02, 2021
  8. Nov 01, 2021
  9. Oct 29, 2021
  10. Oct 27, 2021
    • Michael Weiß's avatar
      dm crypt: log aead integrity violations to audit subsystem · 58d0f180
      Michael Weiß authored
      
      Since dm-crypt target can be stacked on dm-integrity targets to
      provide authenticated encryption, integrity violations are recognized
      here during aead computation. We use the dm-audit submodule to
      signal those events to user space, too.
      
      The construction and destruction of crypt device mappings are also
      logged as audit events.
      
      Signed-off-by: default avatarMichael Weiß <michael.weiss@aisec.fraunhofer.de>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      58d0f180
    • Michael Weiß's avatar
      dm integrity: log audit events for dm-integrity target · 82bb8599
      Michael Weiß authored
      
      dm-integrity signals integrity violations by returning I/O errors
      to user space. To identify integrity violations by a controlling
      instance, the kernel audit subsystem can be used to emit audit
      events to user space. We use the new dm-audit submodule allowing
      to emit audit events on relevant I/O errors.
      
      The construction and destruction of integrity device mappings are
      also relevant for auditing a system. Thus, those events are also
      logged as audit events.
      
      Signed-off-by: default avatarMichael Weiß <michael.weiss@aisec.fraunhofer.de>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      82bb8599
    • Michael Weiß's avatar
      dm: introduce audit event module for device mapper · 2cc1ae48
      Michael Weiß authored
      
      To be able to send auditing events to user space, we introduce a
      generic dm-audit module. It provides helper functions to emit audit
      events through the kernel audit subsystem. We claim the
      AUDIT_DM_CTRL type=1336 and AUDIT_DM_EVENT type=1337 out of the
      audit event messages range in the corresponding userspace api in
      'include/uapi/linux/audit.h' for those events.
      
      AUDIT_DM_CTRL is used to provide information about creation and
      destruction of device mapper targets which are triggered by user space
      admin control actions.
      AUDIT_DM_EVENT is used to provide information about actual errors
      during operation of the mapped device, showing e.g. integrity
      violations in audit log.
      
      Following commits to device mapper targets actually will make use of
      this to emit those events in relevant cases.
      
      The audit logs look like this if executing the following simple test:
      
       # dd if=/dev/zero of=test.img bs=1M count=1024
       # losetup -f test.img
       # integritysetup -vD format --integrity sha256 -t 32 /dev/loop0
       # integritysetup open -D /dev/loop0 --integrity sha256 integritytest
       # integritysetup status integritytest
       # integritysetup close integritytest
       # integritysetup open -D /dev/loop0 --integrity sha256 integritytest
       # integritysetup status integritytest
       # dd if=/dev/urandom of=/dev/loop0 bs=512 count=1 seek=100000
       # dd if=/dev/mapper/integritytest of=/dev/null
      
      -------------------------
      audit.log from auditd
      
      type=UNKNOWN[1336] msg=audit(1630425039.363:184): module=integrity
      op=ctr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      type=UNKNOWN[1336] msg=audit(1630425039.471:185): module=integrity
      op=dtr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      type=UNKNOWN[1336] msg=audit(1630425039.611:186): module=integrity
      op=ctr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      type=UNKNOWN[1336] msg=audit(1630425054.475:187): module=integrity
      op=dtr ppid=3807 pid=3819 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      
      type=UNKNOWN[1336] msg=audit(1630425073.171:191): module=integrity
      op=ctr ppid=3807 pid=3883 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      
      type=UNKNOWN[1336] msg=audit(1630425087.239:192): module=integrity
      op=dtr ppid=3807 pid=3902 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      
      type=UNKNOWN[1336] msg=audit(1630425093.755:193): module=integrity
      op=ctr ppid=3807 pid=3906 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
      egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="integritysetup"
      exe="/sbin/integritysetup" subj==unconfined dev=254:3
      error_msg='success' res=1
      
      type=UNKNOWN[1337] msg=audit(1630425112.119:194): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:195): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:196): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:197): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:198): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:199): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:200): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:201): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:202): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      type=UNKNOWN[1337] msg=audit(1630425112.119:203): module=integrity
      op=integrity-checksum dev=254:3 sector=77480 res=0
      
      Signed-off-by: default avatarMichael Weiß <michael.weiss@aisec.fraunhofer.de>
      Signed-off-by: Paul Moore <paul@paul-moore.com> # fix audit.h numbering
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      2cc1ae48
  11. Oct 21, 2021
  12. Oct 20, 2021
  13. Oct 18, 2021
Loading