Re: [RFC] Experimental btrfs encryption
On Thu, Mar 03, 2016 at 09:58:53AM +0800, Anand Jain wrote: > . (I received couple of private emails on this, so looks like > I confused you and I'm writing again to clear the air on this). > > > - Uses btrfs compression framework, so compression and then > >encryption is not possible. However yet evaluate if there > >are encryption algorithm which can compress as well. > > It should be compression and then encryption. I didn't mean to say > the other way around. However the btrfs encoding framework is > designed to handle any one of it in an elegant manner. So as of > user can configure either encryption OR compression by design. > > Further for users who are looking for both compression and encryption. > There are two ways that we could implement in future in the btrfs. > One enhance the btrfs encoding framework so that it can accommodate > two cascaded engines like compression and followed by encryption. > Or (mostly) a better approach would be to evaluate a single encoding > engine (algorithm) which can do both (compression and then encryption). > Which I think will be less invasive within btrfs, and probably be more > efficient. > > Hope I sound clearer now. Sorry if I wasn't before. > > . I have put up a doc here: > > https://docs.google.com/document/d/1fq9snDM_4ikn44UDNErjHqKXgZHukiJWS4Il3qVhm3M/edit?usp=sharing It's just text, you could also send it as part of the patchset. I'd very much like to see the crypto part covered in more detail, the threat model, what's the right cipher to use and why. You've chosen something that would demonstrate how it works, but eg. implementing the AEAD mode would not be straightforward to add, while it would be a significant difference against the current per-file encryption (we can store per-block associated data cheaply). And there are certainly other questions that I've missed. The per-file encryption is on the way to the VFS layer, so we can implement it in btrfs afterwards. Then the benefit of the proposed patchset would be encrypted data on subvolume with snapshotting enabled. That's probably something that people want and convers common usecases. But we can go further, like full subvolume metadata encryption. -- 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: [RFC] Experimental btrfs encryption
On Mittwoch, 2. März 2016 09:06:57 CET Qu Wenruo wrote: > And maybe I just missed something, but the filename seems not touched, > meaning it will leak a lot of information. > Just like default eCryptfs behavior. > > I understand that's an easy design and it's not a high priority thing, > but I hope we can encrypt the subvolume tree blocks too, if using > per-subvolume policy. > To provide a feature near block-level encryption. I´d really love an approach to at least optionally be able to hide the metadata structure completely except for which blocks on the block device are allocated. I.e. not just encrypting filenames, but encrypting the directory structure, amount of files, their dates, their sizes. I am not sure whether BTRFS can allow this and still be at least btrfs check´able without unlocking the encryption key. Ideally this could even be backuped by an btrfs send/ receive as a kind opaque stream. This would excel BTRFS encryption support over anything thats available with Ext4, F2FS, ecryptfs and encfs. It would ideal for having encryption on SSD, no need to encrypted unallocated blocks, but still most of the advantages of block level encryption, even of some would argue that you can find something out when you check which blocks are allocated or not, and of course the total size of the subvolume and which chunks it allocates are known. I would the this as requirement for any initial approach and be happy about anything that does file name encryption like ecryptfs or the Ext4/F2FS approach, but if the subvolume specifics of BTRFS can be used to encrypted more of the metadata then even better! Thanks, -- Martin -- 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: [RFC] Experimental btrfs encryption
On 2016-03-01 23:48, Anand Jain wrote: On 03/02/2016 02:23 AM, Chris Mason wrote: On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote: On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: We'll definitely move in line with the common API over time. Thanks Anand for starting this! I'd prefer that we keep it per-subvolume for now, just because subvolumes are so cheap and because it seems like a better collection point for general use. But as the other filesystems add features we'll make sure and keep parity with what users expect. We already have per-file encryption in f2fs and ext4, and both have a compatible userspace API and ABI. It would be a pitty to deviate from that intead of reusing it, and if needed extending it. I wasn't very clear here sorry. per-subvolume is my favorite way, but we'll go with the existing ABIs as well. There's no reason to be different. Thanks for commenting. btrfs encryption creates attributes per file its named btrfs.encrypt But when we have a standard attribute for file encryption this should be updated. I wrote a design approaches/principles on which btrfs encryption is based on.. and it here https://docs.google.com/document/d/1fq9snDM_4ikn44UDNErjHqKXgZHukiJWS4Il3qVhm3M/edit?usp=sharing FWIW, a new version of the patch series pushing the ext4/F2FS API up to the VFS layer got posted on LKML just the other day. Based on the level of review, it looks like it may end up in 4.6. -- 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: [RFC] Experimental btrfs encryption
The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. Yep. We would take considerable time to get the API frozen and integrated, as once its in, its there forever. So there are warnings as experimental / RFC. Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Qu Wenruo cn.fujitsu.com> writes: > > - As of now uses "user" keytype, I am still considering/ > >evaluating other key type such as logon. > > UI things can always be reconsidered later. > Never a big problem. This is not only a UI concern, but an API/ABI concern. To use eCryptFS as an example, on mount(2) you pass the information for it to look up the key in the kernel keyring, and it looks for a key of type "user" - I have personally written code that uses trusted and encrypted keys, and the raw mount(2) call (sans any of the eCryptFS userspace libraries) to mount eCryptFS filesystems sealed to the TPM. If eCryptFS switched to using another key type, my code would cease to work unless the filesystem jumped through hoops to do so in a backwards-compatible way. Similarly, while eCryptFS uses a "user" key, it requires that key have a specific structure - as a result, the encrypted keys support added a key type of "ecryptfs" to create random keys with the appropriate structure, meaning the key type for unencrypted keys and the encrypted key key type field differ. This is surprising and non-obvious, and took some time to figure out in my implementation. The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. -- 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: [RFC] Experimental btrfs encryption
. (I received couple of private emails on this, so looks like I confused you and I'm writing again to clear the air on this). - Uses btrfs compression framework, so compression and then encryption is not possible. However yet evaluate if there are encryption algorithm which can compress as well. It should be compression and then encryption. I didn't mean to say the other way around. However the btrfs encoding framework is designed to handle any one of it in an elegant manner. So as of user can configure either encryption OR compression by design. Further for users who are looking for both compression and encryption. There are two ways that we could implement in future in the btrfs. One enhance the btrfs encoding framework so that it can accommodate two cascaded engines like compression and followed by encryption. Or (mostly) a better approach would be to evaluate a single encoding engine (algorithm) which can do both (compression and then encryption). Which I think will be less invasive within btrfs, and probably be more efficient. Hope I sound clearer now. Sorry if I wasn't before. . I have put up a doc here: https://docs.google.com/document/d/1fq9snDM_4ikn44UDNErjHqKXgZHukiJWS4Il3qVhm3M/edit?usp=sharing For your kind review and suggestions. Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Anand Jain wrote on 2016/03/02 17:09 +0800: Hi Qu, Not only move, but also reflink/inband dedup. oh yes thanks. I shall add those. Yes, but in fact, you can use another method, just like in-band de-dup, by adding new hook into async_cow_start() and async_cow_end(), allowing compression and encryption can be done at the same time. (We are already testing the patch to allow dedup to cooperate with compression) So no need to find a encryption with can compress. (Never mix 2 different work together) I am not too sure about this. But logically if one encoding engine can do both that seems to be better than using two separate encoding engines. That's right, if can be done in one iteration, that's best. Maybe I'm ignorant about encryption, but it seems the design goal of current block encryption is safety (confusion and diffusion), and normally same plaintext and ciphertext size. So it may be a little difficult to find such encryption/compression algorithm. And even found, we may need to implement it in kernel, if we're the only user, Linus may not be happy with that though. Another concern is, if using that method, encryption and compression must be bond together, make things a little unflex, especially for subvolume level encryption. But that's all my assumption. Maybe current encryption and compression conflicts method is the best, as it's so easy for user to compression a file in user space. And maybe I just missed something, but the filename seems not touched, meaning it will leak a lot of information. Just like default eCryptfs behavior. > I understand that's an easy design and it's not a high priority thing, but I hope we can encrypt the subvolume tree blocks too, if using per-subvolume policy. To provide a feature near block-level encryption. No you didn't miss about filename, its not there yet. Will add more depth, as I obtain feedback/confirmed on the approach concerns if any. OK, I'll just forgot this corner and focus on current implement. Good job on bringing encryption to the view of most developers. Thanks, Qu Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Anand Jain wrote on 2016/03/02 16:50 +0800: Thanks! for commenting Qu. As you are working near these codes appreciate any code review comments. +1 here, but in fact, it's easy to deal with. As long as not implement encryption as a compression method. Just like inband dedup, we use the following method to support dedup and compression while still using most of CPU cores like compression: Old compression only implement: inode needs compress will go into async_cow_start() async_cow_start() |- compress_file_range() Compression with dedup implement: inode needs compress *OR* dedup will go into async_cow_start() async_cow_start() | |- if (!inode_need_dedup()) | |- compress_file_range() < Thanks for this. Right. Currently there is no elegant way of doing it. Tried a bit of juggles. Unless rework. But I am confused. Are you suggesting we should cascade compress engine and then an encryption engine ? Just a suggestion. As personally, I'd like to separate compression and encryption work. Although most of encryption is just like compression, it's still a little differnet, especially for the need of encryption/decryption key unlike compression. And in fact, compression then encrypt is quite common in this days, a lot of gzipped data is transmitted by TLS, so the need may exist though. Although it's also acceptable not to support compression with encryption, just for simple implementation in kernel. Austin said against such an approach. And I have included it under limitation section just to mention, and what's the idea if at all someone seeks such a configurations, which is to use engine which provides both instead. Another reason I mention this idea, is we're considering rework the current run_delalloc_range(), to provide a unified, re-entry friendly, and independent framework for the growing need of different data processing method. Including normal cow,no data cow, inline, compress, dedup, and hopefully encryption. But current one is good enough for the RFC usage. Thanks, Qu Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Hi Qu, Not only move, but also reflink/inband dedup. oh yes thanks. I shall add those. Yes, but in fact, you can use another method, just like in-band de-dup, by adding new hook into async_cow_start() and async_cow_end(), allowing compression and encryption can be done at the same time. (We are already testing the patch to allow dedup to cooperate with compression) So no need to find a encryption with can compress. (Never mix 2 different work together) I am not too sure about this. But logically if one encoding engine can do both that seems to be better than using two separate encoding engines. And maybe I just missed something, but the filename seems not touched, meaning it will leak a lot of information. Just like default eCryptfs behavior. > I understand that's an easy design and it's not a high priority thing, but I hope we can encrypt the subvolume tree blocks too, if using per-subvolume policy. To provide a feature near block-level encryption. No you didn't miss about filename, its not there yet. Will add more depth, as I obtain feedback/confirmed on the approach concerns if any. Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Thanks! for commenting Qu. As you are working near these codes appreciate any code review comments. +1 here, but in fact, it's easy to deal with. As long as not implement encryption as a compression method. Just like inband dedup, we use the following method to support dedup and compression while still using most of CPU cores like compression: Old compression only implement: inode needs compress will go into async_cow_start() async_cow_start() |- compress_file_range() Compression with dedup implement: inode needs compress *OR* dedup will go into async_cow_start() async_cow_start() | |- if (!inode_need_dedup()) | |- compress_file_range() < Thanks for this. Right. Currently there is no elegant way of doing it. Tried a bit of juggles. Unless rework. But I am confused. Are you suggesting we should cascade compress engine and then an encryption engine ? Austin said against such an approach. And I have included it under limitation section just to mention, and what's the idea if at all someone seeks such a configurations, which is to use engine which provides both instead. Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
Thanks Austin for commenting. Yes to most of it. And probably I should have titled known-issues to known-bugs, which I meant to fix before final integration. In general: Its good to explore options of both compression+encryption OR an algorithm engine which can automatically do both because whether data centers will look for it or not is a balance trade off between CPU load VS Storage space saved VS Network bandwidth needed Yes, network as well because of the remote replication and remote backup data center use cases. So its good to keep that option open. Thanks, Anand -- 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: [RFC] Experimental btrfs encryption
On 03/02/2016 02:23 AM, Chris Mason wrote: On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote: On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: We'll definitely move in line with the common API over time. Thanks Anand for starting this! I'd prefer that we keep it per-subvolume for now, just because subvolumes are so cheap and because it seems like a better collection point for general use. But as the other filesystems add features we'll make sure and keep parity with what users expect. We already have per-file encryption in f2fs and ext4, and both have a compatible userspace API and ABI. It would be a pitty to deviate from that intead of reusing it, and if needed extending it. I wasn't very clear here sorry. per-subvolume is my favorite way, but we'll go with the existing ABIs as well. There's no reason to be different. Thanks for commenting. btrfs encryption creates attributes per file its named btrfs.encrypt But when we have a standard attribute for file encryption this should be updated. I wrote a design approaches/principles on which btrfs encryption is based on.. and it here https://docs.google.com/document/d/1fq9snDM_4ikn44UDNErjHqKXgZHukiJWS4Il3qVhm3M/edit?usp=sharing for your kind review. Thanks! Anand -- 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: [RFC] Experimental btrfs encryption
Austin S. Hemmelgarn wrote on 2016/03/01 11:41 -0500: On 2016-03-01 11:08, Anand Jain wrote: This patchset adds btrfs encryption support. While I think this is a great feature to have, I personally think we're better off waiting for the ext4/F2FS encryption API's to get pushed up to the VFS layer in mainline, and then use those for the user facing API (or at least support them). That said, general comments below. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Example usage: Create an encrypted subvolume: btrfs subvol create -e /btrfs/sv1 Paraphrase: <- Is there any way to do encryption per file instead of per-subvolume? This is a useful feature for a lot of people, and would provide better consistency with how most other filesystem-level encryption designs work. That said, I do like the possibility of per-subvolume encryption, as it allows for things like per-user encrypted home directories without needing some extra layer like ecryptfs. Review encryption status btrfs subvol show /btrfs/sv1 btrfs/sv1 Name: sv1 UID: d8bf1718-56a7-da40-86d9-b8e87315f63f Parent UUID: - Received UUID: - Creation time: 2016-03-01 17:11:58 +0800 Subvolume ID: 257 Generation: 13 Gen at creation:7 Parent ID: 5 Top level ID: 5 Flags: - Encryption: aes@btrfs:d8bf1718 (188612608) ^ ^^ ^ || | Algorithm Key-Tag Key-serial-number keyctl show :: 188612608 --alswrv 0 0 \_ user: btrfs:d8bf1718 Logout/revoke: btrfs subvol encrypt -k out /btrfs/sv1 btrfs subvol show /btrfs/sv1 | egrep Encrypt Encryption: aes@btrfs:d8bf1718 (Required key not available) sign in: btrfs subvol encrypt -k in /btrfs/sv1 Known issues / limitation / for future expansion: - Need to set FS incompatible feature. - No password verification yet. These two are absolutely essential from a data safety POV. - Move of files across subvolume is not supported when both or either one has encryption set. - No way to change the password. - Does not drop the cached pages when key is revoked. This is essential from a security POV. - Need to get password twice from the user. - No user permeable subvol info ioctl. - Provide a method to pass key using the mount option. - Provide a method to read the key from the file. - Current encryption method is symmetric (same key for both encryption and decryption), however we could easily expand this to other potentially useful methods like asymmetric (private/public) encryption. - As of now uses "user" keytype, I am still considering/ evaluating other key type such as logon. - Evaluate other encryption algorithms, as of now it is using "cts(cbc(aes)". While this would be nice (I would love to see full CryptoAPI support), it probably shouldn't be considered a deal breaker for merging this or declaring it production ready. - Uses btrfs compression framework, so compression and then encryption is not possible. However yet evaluate if there are encryption algorithm which can compress as well. The utility of this is debatable. Most other filesystems that support both compression and encryption support only one or the other for a given file, encrypting compressed data is overall less secure than encrypting the data itself, and trying to compress encrypted data usually just wastes CPU time. +1 here, but in fact, it's easy to deal with. As long as not implement encryption as a compression method. Just like inband dedup, we use the following method to support dedup and compression while still using most of CPU cores like compression: Old compression only implement: inode needs compress will go into async_cow_start() async_cow_start() |- compress_file_range() Compression with dedup implement: inode needs compress *OR* dedup will go into async_cow_start() async_cow_start() | |- if (!inode_need_dedup()) | |- compress_file_range()
Re: [RFC] Experimental btrfs encryption
Anand Jain wrote on 2016/03/02 00:08 +0800: This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Example usage: Create an encrypted subvolume: btrfs subvol create -e /btrfs/sv1 Paraphrase: <- Review encryption status btrfs subvol show /btrfs/sv1 btrfs/sv1 Name: sv1 UID: d8bf1718-56a7-da40-86d9-b8e87315f63f Parent UUID: - Received UUID: - Creation time: 2016-03-01 17:11:58 +0800 Subvolume ID: 257 Generation: 13 Gen at creation:7 Parent ID: 5 Top level ID: 5 Flags: - Encryption: aes@btrfs:d8bf1718 (188612608) ^ ^^ ^ || | Algorithm Key-Tag Key-serial-number keyctl show :: 188612608 --alswrv 0 0 \_ user: btrfs:d8bf1718 Logout/revoke: btrfs subvol encrypt -k out /btrfs/sv1 btrfs subvol show /btrfs/sv1 | egrep Encrypt Encryption: aes@btrfs:d8bf1718 (Required key not available) sign in: btrfs subvol encrypt -k in /btrfs/sv1 Known issues / limitation / for future expansion: - Need to set FS incompatible feature. Not a limitation at all. - No password verification yet. - Move of files across subvolume is not supported when both or either one has encryption set. Not only move, but also reflink/inband dedup. - No way to change the password. - Does not drop the cached pages when key is revoked. - Need to get password twice from the user. - No user permeable subvol info ioctl. - Provide a method to pass key using the mount option. - Provide a method to read the key from the file. - Current encryption method is symmetric (same key for both encryption and decryption), however we could easily expand this to other potentially useful methods like asymmetric (private/public) encryption. - As of now uses "user" keytype, I am still considering/ evaluating other key type such as logon. UI things can always be reconsidered later. Never a big problem. - Evaluate other encryption algorithms, as of now it is using "cts(cbc(aes)". - Uses btrfs compression framework, so compression and then encryption is not possible. However yet evaluate if there are encryption algorithm which can compress as well. Yes, but in fact, you can use another method, just like in-band de-dup, by adding new hook into async_cow_start() and async_cow_end(), allowing compression and encryption can be done at the same time. (We are already testing the patch to allow dedup to cooperate with compression) So no need to find a encryption with can compress. (Never mix 2 different work together) And maybe I just missed something, but the filename seems not touched, meaning it will leak a lot of information. Just like default eCryptfs behavior. I understand that's an easy design and it's not a high priority thing, but I hope we can encrypt the subvolume tree blocks too, if using per-subvolume policy. To provide a feature near block-level encryption. Thanks, Qu Anand Jain (1): btrfs: encryption fs/btrfs/Makefile | 2 +- fs/btrfs/btrfs_inode.h | 2 + fs/btrfs/compression.c | 53 - fs/btrfs/compression.h | 1 + fs/btrfs/ctree.h | 11 +- fs/btrfs/encrypt.c | 544 + fs/btrfs/encrypt.h | 21 ++ fs/btrfs/inode.c | 37 +++- fs/btrfs/ioctl.c | 7 + fs/btrfs/props.c | 140 - fs/btrfs/super.c | 5 +- 11 files changed, 812 insertions(+), 11 deletions(-) create mode 100644 fs/btrfs/encrypt.c create mode 100644 fs/btrfs/encrypt.h Anand Jain (2): btrfs-progs: subvolume functions reorg btrfs-progs: add encrypt as subvol sub-command Makefile.in | 5 +- btrfs-list.c | 33 + cmds-qgroup.c| 1 + cmds-send.c | 12 +- cmds-subvolume.c | 209 +++-- commands.h | 1 + encrypt.c| 397 +++ encrypt.h| 33 + props.c | 3 + subvolume.c | 152 + subvolume.h | 22 +++ 11 files changed, 757 insertions(+), 111 deletions(-) create mode 100644 encrypt.c create mode 100644 encrypt.h create mode 100644 subvolume.c create mode 100644 subvolume.h -- 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: [RFC] Experimental btrfs encryption
On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote: > On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: > > We'll definitely move in line with the common API over time. Thanks > > Anand for starting this! > > > > I'd prefer that we keep it per-subvolume for now, just because > > subvolumes are so cheap and because it seems like a better collection > > point for general use. But as the other filesystems add features we'll > > make sure and keep parity with what users expect. > > We already have per-file encryption in f2fs and ext4, and both have > a compatible userspace API and ABI. It would be a pitty to deviate > from that intead of reusing it, and if needed extending it. I wasn't very clear here sorry. per-subvolume is my favorite way, but we'll go with the existing ABIs as well. There's no reason to be different. -chris -- 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: [RFC] Experimental btrfs encryption
On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: > We'll definitely move in line with the common API over time. Thanks > Anand for starting this! > > I'd prefer that we keep it per-subvolume for now, just because > subvolumes are so cheap and because it seems like a better collection > point for general use. But as the other filesystems add features we'll > make sure and keep parity with what users expect. We already have per-file encryption in f2fs and ext4, and both have a compatible userspace API and ABI. It would be a pitty to deviate from that intead of reusing it, and if needed extending it. -- 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: [RFC] Experimental btrfs encryption
On 2016-03-01 11:46, Chris Mason wrote: On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote: On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Can you share some design documents? Will it be compatible with existing encrypting filesystems: – ext4 ? – ZFS ? It would be nice to have common API for encryption, not a dozen of filesystem-specific interfaces. We'll definitely move in line with the common API over time. Thanks Anand for starting this! I'd prefer that we keep it per-subvolume for now, just because subvolumes are so cheap and because it seems like a better collection point for general use. But as the other filesystems add features we'll make sure and keep parity with what users expect. I hate to tell you, but if you want feature parity, it needs to have \ per-file functionality from the start. Both ext4 and F2FS do per-file, as does NTFS (not certain about ZFS, but people are not as likely to be coming to BTRFS from ZFS as they are from ext4 or F2FS from what I've seen). -- 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: [RFC] Experimental btrfs encryption
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote: > On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > > > Warning: > > The code is in prototype/experimental stage and is not suitable > > for the production data yet. > > Can you share some design documents? Will it be compatible > with existing encrypting filesystems: > – ext4 ? > – ZFS ? > > It would be nice to have common API for encryption, not a dozen > of filesystem-specific interfaces. We'll definitely move in line with the common API over time. Thanks Anand for starting this! I'd prefer that we keep it per-subvolume for now, just because subvolumes are so cheap and because it seems like a better collection point for general use. But as the other filesystems add features we'll make sure and keep parity with what users expect. -chris -- 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: [RFC] Experimental btrfs encryption
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > Warning: > The code is in prototype/experimental stage and is not suitable > for the production data yet. Can you share some design documents? Will it be compatible with existing encrypting filesystems: – ext4 ? – ZFS ? It would be nice to have common API for encryption, not a dozen of filesystem-specific interfaces. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| -- 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
[RFC] Experimental btrfs encryption
This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Example usage: Create an encrypted subvolume: btrfs subvol create -e /btrfs/sv1 Paraphrase: <- Review encryption status btrfs subvol show /btrfs/sv1 btrfs/sv1 Name: sv1 UID: d8bf1718-56a7-da40-86d9-b8e87315f63f Parent UUID: - Received UUID: - Creation time: 2016-03-01 17:11:58 +0800 Subvolume ID: 257 Generation: 13 Gen at creation:7 Parent ID: 5 Top level ID: 5 Flags: - Encryption: aes@btrfs:d8bf1718 (188612608) ^ ^^ ^ || | Algorithm Key-Tag Key-serial-number keyctl show :: 188612608 --alswrv 0 0 \_ user: btrfs:d8bf1718 Logout/revoke: btrfs subvol encrypt -k out /btrfs/sv1 btrfs subvol show /btrfs/sv1 | egrep Encrypt Encryption: aes@btrfs:d8bf1718 (Required key not available) sign in: btrfs subvol encrypt -k in /btrfs/sv1 Known issues / limitation / for future expansion: - Need to set FS incompatible feature. - No password verification yet. - Move of files across subvolume is not supported when both or either one has encryption set. - No way to change the password. - Does not drop the cached pages when key is revoked. - Need to get password twice from the user. - No user permeable subvol info ioctl. - Provide a method to pass key using the mount option. - Provide a method to read the key from the file. - Current encryption method is symmetric (same key for both encryption and decryption), however we could easily expand this to other potentially useful methods like asymmetric (private/public) encryption. - As of now uses "user" keytype, I am still considering/ evaluating other key type such as logon. - Evaluate other encryption algorithms, as of now it is using "cts(cbc(aes)". - Uses btrfs compression framework, so compression and then encryption is not possible. However yet evaluate if there are encryption algorithm which can compress as well. Anand Jain (1): btrfs: encryption fs/btrfs/Makefile | 2 +- fs/btrfs/btrfs_inode.h | 2 + fs/btrfs/compression.c | 53 - fs/btrfs/compression.h | 1 + fs/btrfs/ctree.h | 11 +- fs/btrfs/encrypt.c | 544 + fs/btrfs/encrypt.h | 21 ++ fs/btrfs/inode.c | 37 +++- fs/btrfs/ioctl.c | 7 + fs/btrfs/props.c | 140 - fs/btrfs/super.c | 5 +- 11 files changed, 812 insertions(+), 11 deletions(-) create mode 100644 fs/btrfs/encrypt.c create mode 100644 fs/btrfs/encrypt.h Anand Jain (2): btrfs-progs: subvolume functions reorg btrfs-progs: add encrypt as subvol sub-command Makefile.in | 5 +- btrfs-list.c | 33 + cmds-qgroup.c| 1 + cmds-send.c | 12 +- cmds-subvolume.c | 209 +++-- commands.h | 1 + encrypt.c| 397 +++ encrypt.h| 33 + props.c | 3 + subvolume.c | 152 + subvolume.h | 22 +++ 11 files changed, 757 insertions(+), 111 deletions(-) create mode 100644 encrypt.c create mode 100644 encrypt.h create mode 100644 subvolume.c create mode 100644 subvolume.h -- 2.7.0 -- 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
