is cryptographically secure integrity checking possible with btrfs?
Hey. For encryption we have dm-crypt and in principle I'm happy with having that at the block device level below the filesystem - perhaps except for any possible performance issues, especially when used with software RAID (regardless of whether MD or btrfs')[0]. But obviously integrity protection is still missing... and I guess for many people this would actually be much more interesting than encryption. Now as far as I understand btrfs, everything, data and metadata is checksummed (right now only with CRC32, but enough space would be left for something better). And further, these checksums are verified on each read. Are these checksums chained? I.e. when a datablock is written/changed, not only its checksum is affected, but also those of all meta-data blocks up to the super blocks? If so, one could perhaps use this like git for integrity protection. For example when unmounting a btrfs filesystem, it could print the final checksum of the superblock. The user could store this on some safe device (for the paranoid one e.g. on a USB stick that always travels along and that by coincidence also contains boot loader, kernel+initrd and the dm-crypt keys necessary to decrypt the fully encrypted system). On mount one could then specify the expected checksum for the superblock. If it differs already, then the mount should obviously fails right away (or try backup superblocks and that like, but again only use them if they match the sum). Obviously one would also need an operation mode in which btrfs dies with bells and red signs as soon as something (data or metadata) is read afterwards, which doesn't match the expected checksums. again, RAID copies, etc. could of course be tried - but if no valid copy is found, then it should assume compromise and the read operation should error out and not deliver any data at all (it may be compromised and nothing should use it). Of course people might still want to read such compromised blocks (e.g. when they are sure that they've only suffered from accidental data corruption and try to rescue as much as possible), but that should then require a special mount option. Well I'm not that crypto expert,... and btrfs would probably at least need more than CRC32. Unfortunately the 512bit version of Keccak wouldn't fit in, would it? ;) Cheers, Chris. [0] Does anyone know the current status of this? When I have say a btrfs RAID6 with n disks, each actually being a dm-crypt device... will this run all in one IO thread killing the performance? smime.p7s Description: S/MIME cryptographic signature
Re: btrfs: kernel BUG at fs/btrfs/extent_io.c:676!
On 10/14/2014 02:31 AM, Chris Mason wrote: On Sun, Oct 12, 2014 at 10:15 PM, Sasha Levin sasha.le...@oracle.com wrote: Ping? This BUG_ON()ing due to GFP_ATOMIC allocation failure is really silly :( Agreed, I have a patch for this in testing. It didn't make my first pull but I'll get it fixed up. I've re-enabled fs testing after the discussion at LSF/MM (but mostly due to Michal's patch), and this issue came right back up. Any updates? Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] btrfs: ENOMEM bugfixes
On Tue, Feb 24, 2015 at 02:47:03AM -0800, Omar Sandoval wrote: Hi, everyone, This patch series fixes a few bugs that occur under low memory conditions. These were exposed by a change in behavior of GFP_NOFS allocations in 3.19-rc7, by commit 9879de7373fc (mm: page_alloc: embed OOM killing naturally into allocation slowpath). While the mm people sort that out, we can fix these issues, which are bugs no matter what the outcome there is. Here's a quick script which reproduces these bugs. With the patches applied, the filesystem will drop into read-only mode instead of blowing up. #!/bin/sh cgcreate -g memory:enomem MEM=$((64 * 1024 * 1024)) echo $MEM /sys/fs/cgroup/memory/enomem/memory.limit_in_bytes cgexec -g memory:enomem ~/xfstests/ltp/fsstress -p128 -n9 -d /mnt/test trap killall fsstress; exit 0 SIGINT SIGTERM while true; do cgexec -g memory:enomem python -c ' l = [] while True: l.append(0)' done Version 2 rebases on top of 4.0-rc1, has a simpler fix for the alloc_extent_buffer race, expands the commit messages to mention changed comments, and adds Liu Bo's Reviewed-by. Thanks! Omar Sandoval (3): btrfs: handle ENOMEM in btrfs_alloc_tree_block btrfs: fix race on ENOMEM in alloc_extent_buffer btrfs: check io_ctl_prepare_pages return in __btrfs_write_out_cache fs/btrfs/extent-tree.c | 41 - fs/btrfs/extent_io.c| 3 ++- fs/btrfs/free-space-cache.c | 10 ++ 3 files changed, 36 insertions(+), 18 deletions(-) -- 2.3.0 Ping. For anyone following along, it looks like commit cc87317726f8 (mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change) reverted the commit that exposed these bugs. Josef said he was okay with taking these, will they make it to an upcoming -rc soon? Thanks! -- Omar -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is cryptographically secure integrity checking possible with btrfs?
Hi, On Thu, Mar 12, 2015 at 04:35:19AM +0100, Christoph Anton Mitterer wrote: Hey. For encryption we have dm-crypt and in principle I'm happy with having that at the block device level below the filesystem - perhaps except for any possible performance issues, especially when used with software RAID (regardless of whether MD or btrfs')[0]. But obviously integrity protection is still missing... and I guess for many people this would actually be much more interesting than encryption. Now as far as I understand btrfs, everything, data and metadata is checksummed (right now only with CRC32, but enough space would be left for something better). And further, these checksums are verified on each read. Are these checksums chained? I.e. when a datablock is written/changed, not only its checksum is affected, but also those of all meta-data blocks up to the super blocks? checksum is updated along with the corresponding datablock's change, but updating the super block depends on when btrfs starts committing transaction. If so, one could perhaps use this like git for integrity protection. For example when unmounting a btrfs filesystem, it could print the final checksum of the superblock. The user could store this on some safe device (for the paranoid one e.g. on a USB stick that always travels along and that by coincidence also contains boot loader, kernel+initrd and the dm-crypt keys necessary to decrypt the fully encrypted system). On mount one could then specify the expected checksum for the superblock. If it differs already, then the mount should obviously fails right away (or try backup superblocks and that like, but again only use them if they match the sum). That's exactly what we have now in btrfs, but the superblock checksum is only to verify superblock itself, nothing more. Obviously one would also need an operation mode in which btrfs dies with bells and red signs as soon as something (data or metadata) is read afterwards, which doesn't match the expected checksums. again, RAID copies, etc. could of course be tried - but if no valid copy is found, then it should assume compromise and the read operation should error out and not deliver any data at all (it may be compromised and nothing should use it). Okay, if you kept using btrfs for a while, you can figure out the above is basically true, but there are some differences, a) if we find a metadata checksum mismatch, we do go to get another copy(we usually have two copies for metadata) for good copy if it is, and if no, we dont make btrfs die but throw a warning(actually it can refuse to mount if you got such errors during mount and couldnt find good copies). b) if we find a data checksum mismatch, we do the same thing, but throw bad news into dmesg logs and return EIO. Of course people might still want to read such compromised blocks (e.g. when they are sure that they've only suffered from accidental data corruption and try to rescue as much as possible), but that should then require a special mount option. So you're asking for a strict mode, but for datablock corruption, is it OK for you to just flip btrfs into readonly mode instead of making it die? Well I'm not that crypto expert,... and btrfs would probably at least need more than CRC32. Unfortunately the 512bit version of Keccak wouldn't fit in, would it? ;) IIRC, we have only 256bit space, so 512bit may need some other tricks. Thanks, -liubo Cheers, Chris. [0] Does anyone know the current status of this? When I have say a btrfs RAID6 with n disks, each actually being a dm-crypt device... will this run all in one IO thread killing the performance? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
