Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Fri, May 15, 2015 at 09:47:05PM -0700, Tom Marshall wrote:
> On Fri, May 15, 2015 at 06:14:24PM -0700, Jaegeuk Kim wrote:
> > On Thu, May 14, 2015 at 09:50:44AM -0700, Tom Marshall wrote:
> > > Please keep in mind that I'm also working on transparent
> > > compression. I'm watching this thread closely so that I can
> > > implement a compression library alongside the crypto library. If
> > > there is any interest or benefit, I would be glad to work together
> > > so that the two can be done cooperatively at the same time.
> >
> > I can't imagine quickly how compression code can be shared with crypto.
> > The basic approach for compression would be that X pages can be compressed
> > into
> > small number of pages, Y, which can be a X to Y mapping.
> > But, this per-file encryption supports only 1 to 1 4KB mapping, so that it
> > could
> > be quite a simple implementation.
>
> No, I don't intend to share actual code with crypto -- at least not much.
> I'm more interested in looking at how the crypto layer is implemented to
> give me clues about how to implement a compression layer.
Ok, I see.
Currently, I've been writing up fs/crypto having shared crypto codes between
ext4 and f2fs; I refactored existing codes a little bit though.
I'm approaching to introduce a fscypt_operations for each filesystems like this.
struct fscrypt_operations {
int (*get_context)(struct inode *, void *, size_t, void *);
int (*set_context)(struct inode *, const void *, size_t, int, void *);
int (*prepare_new_context)(struct inode *);
bool (*is_encrypted)(struct inode *);
bool (*empty_dir)(struct inode *);
unsigned (*max_namelen)(struct inode *);
};
And, the following two basic functions will be used by filesystems:
fscrypt_encrypt_page() and fscrypt_decrypt_page().
>
> > Could you elaborate on your approach or design? Or, codes?
> > Whatever, IMO, it needs to implement it by any filesystem first.
>
> I don't really have any working code yet. I will probably get to that in
> the coming few weeks. Right now I'm still working with the ugly VFS
> stacking implementation that I posted initially.
>
> The thing that I have done is dismissed the standard compression framing
> formats.
>
> zlib (and gzip) are designed for streaming and it is quite difficult to
> implement random access on it. See the example code in the zlib source,
> zran.c. It's not really tenable because 32kb of prior data is required to
> be kept as priming information. Even doing fully encapsulated blocks with
> Z_FINISH, there is still no way to skip over data without decompressing it
> first to build an index.
>
> lz4 is somewhat better in that blocks are self contained. But block lengths
> must be read sequentially. This means that reading an arbitrary position in
> a file requires a proportional number of reads to find the desired block.
>
> So, I am working with a simple framing format that I threw together. The
> header has a compression method (zlib or lz4), block size, original input
> size, and a block map.
Thank you for sharing the approach, and it makes sense to improve random
read performance.
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Sat, May 16, 2015 at 09:24:03AM -0400, Theodore Ts'o wrote: > [...] What's going to be more difficult in the long run is > when we want to support per-block data integrity, using (for example) > AES/GCM, which will require 32 bytes of per-block "authentication tag" > (think Message Authentication Code) that have to be committed > atomically with the data block write. > > Quite frankly, this is going to be much easier for COW file systems > like f2fs and btrfs. I have some ideas about how to do this for > update-in-place file systems (using either a compression hack and/or > storing two generations worth of authentication tag per block), but > it's not pretty. (Or in the case of ext4 we could use > data=journalling mode, but that's even less pretty from a performance > standpoint.) It seems to me that compression has a similar issue with framing metadata. The block map can be stored upfront, which then would require two writes to update a data block. Or it can be stored inline, which then would require scanning through the file sequentially for random access. The big difference, of course, is that in the case of compression, we have the luxury of assuming or mandating read-only/read-mostly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote:
> >
> > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so
> > I believe most part of crypto codes are common.
>
> Can I suggest fs/crypto/ if there are going to be multiple files?
Yes, I think we definitely want to do this as fs/crypto; it makes
things a bit more straightforward on a number of fronts; not just from
a Makefile point of view, but also in setting up a separate tree to
push into linux-next.
> > But, in order to realize that quickly, Ted implemented the feature to
> > finalize
> > on-disk and in-memory design in EXT4 as a first step.
> > Then, I've been catching up and validating its design by implementing it in
> > F2FS, which also intends to figure out what crypto codes can be exactly
> > common.
>
> Excellent. That will make it easier and less error prone for other
> filesystems to implement it, too!
Yeah, that's why I figured it would be easier to get it into ext4 and
f2fs first. We can keep the functions in sync for a release or so,
and then we can start creating patches that gradually move each of
fs/{ext4,f2fs}/{crypto,crypo_fname,crypto_policy}.c, etc. into a
common fs/crypto directory. I'm sure there will be a bit of
refactoring that will be necessary as we go along, but it will be a
lot easier to validate that we've gotten things once we have to file
systems both depending on the common code.
If Michael and I had tried to create fs/cryto up-front, I'm *sure* we
would have gotten a number of things wrong. :-)
> > Meanwhile, surely I've been working on writing patches to push them into
> > fs/;
> > currenlty, I did for cryto.c and will do for crypto_key.c and
> > crypto_fname.c.
> > But, it needs to think about crypto_policy.c differently, since it may
> > depend
> > on how each filesystem stores the policy information respectively; we cannot
> > push all the filesystems should use xattrs, right?
>
> All filesystems likely to implement per-file crypto support xattrs,
> and this is exactly what xattrs are designed for. e.g. we already
> require xattrs for generic security labels, ACLs, etc. Hence
> per-file crypto information should also use a common, shared xattr
> format. That way it only needs to be implemented once in the generic
> code and there's very little (hopefully nothing!) each filesystem
> has to customise to store the crypto information for each file.
Yes, absolutely. What's going to be more difficult in the long run is
when we want to support per-block data integrity, using (for example)
AES/GCM, which will require 32 bytes of per-block "authentication tag"
(think Message Authentication Code) that have to be committed
atomically with the data block write.
Quite frankly, this is going to be much easier for COW file systems
like f2fs and btrfs. I have some ideas about how to do this for
update-in-place file systems (using either a compression hack and/or
storing two generations worth of authentication tag per block), but
it's not pretty. (Or in the case of ext4 we could use
data=journalling mode, but that's even less pretty from a performance
standpoint.)
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Fri, May 15, 2015 at 06:14:24PM -0700, Jaegeuk Kim wrote: > On Thu, May 14, 2015 at 09:50:44AM -0700, Tom Marshall wrote: > > Please keep in mind that I'm also working on transparent > > compression. I'm watching this thread closely so that I can > > implement a compression library alongside the crypto library. If > > there is any interest or benefit, I would be glad to work together > > so that the two can be done cooperatively at the same time. > > I can't imagine quickly how compression code can be shared with crypto. > The basic approach for compression would be that X pages can be compressed > into > small number of pages, Y, which can be a X to Y mapping. > But, this per-file encryption supports only 1 to 1 4KB mapping, so that it > could > be quite a simple implementation. No, I don't intend to share actual code with crypto -- at least not much. I'm more interested in looking at how the crypto layer is implemented to give me clues about how to implement a compression layer. > Could you elaborate on your approach or design? Or, codes? > Whatever, IMO, it needs to implement it by any filesystem first. I don't really have any working code yet. I will probably get to that in the coming few weeks. Right now I'm still working with the ugly VFS stacking implementation that I posted initially. The thing that I have done is dismissed the standard compression framing formats. zlib (and gzip) are designed for streaming and it is quite difficult to implement random access on it. See the example code in the zlib source, zran.c. It's not really tenable because 32kb of prior data is required to be kept as priming information. Even doing fully encapsulated blocks with Z_FINISH, there is still no way to skip over data without decompressing it first to build an index. lz4 is somewhat better in that blocks are self contained. But block lengths must be read sequentially. This means that reading an arbitrary position in a file requires a proportional number of reads to find the desired block. So, I am working with a simple framing format that I threw together. The header has a compression method (zlib or lz4), block size, original input size, and a block map. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Thu, May 14, 2015 at 09:50:44AM -0700, Tom Marshall wrote: > Please keep in mind that I'm also working on transparent > compression. I'm watching this thread closely so that I can > implement a compression library alongside the crypto library. If > there is any interest or benefit, I would be glad to work together > so that the two can be done cooperatively at the same time. I can't imagine quickly how compression code can be shared with crypto. The basic approach for compression would be that X pages can be compressed into small number of pages, Y, which can be a X to Y mapping. But, this per-file encryption supports only 1 to 1 4KB mapping, so that it could be quite a simple implementation. Could you elaborate on your approach or design? Or, codes? Whatever, IMO, it needs to implement it by any filesystem first. Thanks, > > On 05/13/2015 06:56 PM, Jaegeuk Kim wrote: > >On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote: > >>On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: > >>>On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > >This definitions will be used by inode and superblock for encyption. > How much of this crypto stuff is common with or only slightly > modified from the ext4 code? Is the behaviour and features the > same? Is the user API and management tools the same? > > IMO, if there is any amount of overlap, then we should be > implementing this stuff as generic code, not propagating the same > code through multiple filesystems via copy-n-paste-n-modify. This > will simply end up with diverging code, different bugs and feature > sets, and none of the implementations will get the review and > maintenance they really require... > > And, FWIW, this is the reason why I originally asked for the ext4 > encryption code to be pulled up to the VFS: precisely so we didn't > end up with a rapid proliferation of individual in-filesystem > encryption implementations that are all slightly different... > >>>Totally agreed! > >>> > >>>AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so > >>>I believe most part of crypto codes are common. > >>Can I suggest fs/crypto/ if there are going to be multiple files? > >No problem at all. I'll do. > > > >>>But, in order to realize that quickly, Ted implemented the feature to > >>>finalize > >>>on-disk and in-memory design in EXT4 as a first step. > >>>Then, I've been catching up and validating its design by implementing it in > >>>F2FS, which also intends to figure out what crypto codes can be exactly > >>>common. > >>Excellent. That will make it easier and less error prone for other > >>filesystems to implement it, too! > >> > >>>As Ted mentioned before, since next android version tries to use per-file > >>>encryption, F2FS also needs to support it as quick as possible likewise > >>>EXT4. > >>Fair enough. > >> > >>>Meanwhile, surely I've been working on writing patches to push them into > >>>fs/; > >>>currenlty, I did for cryto.c and will do for crypto_key.c and > >>>crypto_fname.c. > >>>But, it needs to think about crypto_policy.c differently, since it may > >>>depend > >>>on how each filesystem stores the policy information respectively; we > >>>cannot > >>>push all the filesystems should use xattrs, right? > >>All filesystems likely to implement per-file crypto support xattrs, > >>and this is exactly what xattrs are designed for. e.g. we already > >>require xattrs for generic security labels, ACLs, etc. Hence > >>per-file crypto information should also use a common, shared xattr > >>format. That way it only needs to be implemented once in the generic > >>code and there's very little (hopefully nothing!) each filesystem > >>has to customise to store the crypto information for each file. > >Ok, I see. Let me take a look at that too. > >Thank you for sharing your thoughts. :) > > > >>Cheers, > >> > >>Dave. > >>-- > >>Dave Chinner > >>da...@fromorbit.com > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > >the body of a message to majord...@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
Please keep in mind that I'm also working on transparent compression. I'm watching this thread closely so that I can implement a compression library alongside the crypto library. If there is any interest or benefit, I would be glad to work together so that the two can be done cooperatively at the same time. On 05/13/2015 06:56 PM, Jaegeuk Kim wrote: On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote: On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: This definitions will be used by inode and superblock for encyption. How much of this crypto stuff is common with or only slightly modified from the ext4 code? Is the behaviour and features the same? Is the user API and management tools the same? IMO, if there is any amount of overlap, then we should be implementing this stuff as generic code, not propagating the same code through multiple filesystems via copy-n-paste-n-modify. This will simply end up with diverging code, different bugs and feature sets, and none of the implementations will get the review and maintenance they really require... And, FWIW, this is the reason why I originally asked for the ext4 encryption code to be pulled up to the VFS: precisely so we didn't end up with a rapid proliferation of individual in-filesystem encryption implementations that are all slightly different... Totally agreed! AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so I believe most part of crypto codes are common. Can I suggest fs/crypto/ if there are going to be multiple files? No problem at all. I'll do. But, in order to realize that quickly, Ted implemented the feature to finalize on-disk and in-memory design in EXT4 as a first step. Then, I've been catching up and validating its design by implementing it in F2FS, which also intends to figure out what crypto codes can be exactly common. Excellent. That will make it easier and less error prone for other filesystems to implement it, too! As Ted mentioned before, since next android version tries to use per-file encryption, F2FS also needs to support it as quick as possible likewise EXT4. Fair enough. Meanwhile, surely I've been working on writing patches to push them into fs/; currenlty, I did for cryto.c and will do for crypto_key.c and crypto_fname.c. But, it needs to think about crypto_policy.c differently, since it may depend on how each filesystem stores the policy information respectively; we cannot push all the filesystems should use xattrs, right? All filesystems likely to implement per-file crypto support xattrs, and this is exactly what xattrs are designed for. e.g. we already require xattrs for generic security labels, ACLs, etc. Hence per-file crypto information should also use a common, shared xattr format. That way it only needs to be implemented once in the generic code and there's very little (hopefully nothing!) each filesystem has to customise to store the crypto information for each file. Ok, I see. Let me take a look at that too. Thank you for sharing your thoughts. :) Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote: > On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: > > On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > > > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > > > > This definitions will be used by inode and superblock for encyption. > > > > > > How much of this crypto stuff is common with or only slightly > > > modified from the ext4 code? Is the behaviour and features the > > > same? Is the user API and management tools the same? > > > > > > IMO, if there is any amount of overlap, then we should be > > > implementing this stuff as generic code, not propagating the same > > > code through multiple filesystems via copy-n-paste-n-modify. This > > > will simply end up with diverging code, different bugs and feature > > > sets, and none of the implementations will get the review and > > > maintenance they really require... > > > > > > And, FWIW, this is the reason why I originally asked for the ext4 > > > encryption code to be pulled up to the VFS: precisely so we didn't > > > end up with a rapid proliferation of individual in-filesystem > > > encryption implementations that are all slightly different... > > > > Totally agreed! > > > > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so > > I believe most part of crypto codes are common. > > Can I suggest fs/crypto/ if there are going to be multiple files? No problem at all. I'll do. > > > But, in order to realize that quickly, Ted implemented the feature to > > finalize > > on-disk and in-memory design in EXT4 as a first step. > > Then, I've been catching up and validating its design by implementing it in > > F2FS, which also intends to figure out what crypto codes can be exactly > > common. > > Excellent. That will make it easier and less error prone for other > filesystems to implement it, too! > > > As Ted mentioned before, since next android version tries to use per-file > > encryption, F2FS also needs to support it as quick as possible likewise > > EXT4. > > Fair enough. > > > Meanwhile, surely I've been working on writing patches to push them into > > fs/; > > currenlty, I did for cryto.c and will do for crypto_key.c and > > crypto_fname.c. > > But, it needs to think about crypto_policy.c differently, since it may > > depend > > on how each filesystem stores the policy information respectively; we cannot > > push all the filesystems should use xattrs, right? > > All filesystems likely to implement per-file crypto support xattrs, > and this is exactly what xattrs are designed for. e.g. we already > require xattrs for generic security labels, ACLs, etc. Hence > per-file crypto information should also use a common, shared xattr > format. That way it only needs to be implemented once in the generic > code and there's very little (hopefully nothing!) each filesystem > has to customise to store the crypto information for each file. Ok, I see. Let me take a look at that too. Thank you for sharing your thoughts. :) > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: > On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > > > This definitions will be used by inode and superblock for encyption. > > > > How much of this crypto stuff is common with or only slightly > > modified from the ext4 code? Is the behaviour and features the > > same? Is the user API and management tools the same? > > > > IMO, if there is any amount of overlap, then we should be > > implementing this stuff as generic code, not propagating the same > > code through multiple filesystems via copy-n-paste-n-modify. This > > will simply end up with diverging code, different bugs and feature > > sets, and none of the implementations will get the review and > > maintenance they really require... > > > > And, FWIW, this is the reason why I originally asked for the ext4 > > encryption code to be pulled up to the VFS: precisely so we didn't > > end up with a rapid proliferation of individual in-filesystem > > encryption implementations that are all slightly different... > > Totally agreed! > > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so > I believe most part of crypto codes are common. Can I suggest fs/crypto/ if there are going to be multiple files? > But, in order to realize that quickly, Ted implemented the feature to finalize > on-disk and in-memory design in EXT4 as a first step. > Then, I've been catching up and validating its design by implementing it in > F2FS, which also intends to figure out what crypto codes can be exactly > common. Excellent. That will make it easier and less error prone for other filesystems to implement it, too! > As Ted mentioned before, since next android version tries to use per-file > encryption, F2FS also needs to support it as quick as possible likewise EXT4. Fair enough. > Meanwhile, surely I've been working on writing patches to push them into fs/; > currenlty, I did for cryto.c and will do for crypto_key.c and crypto_fname.c. > But, it needs to think about crypto_policy.c differently, since it may depend > on how each filesystem stores the policy information respectively; we cannot > push all the filesystems should use xattrs, right? All filesystems likely to implement per-file crypto support xattrs, and this is exactly what xattrs are designed for. e.g. we already require xattrs for generic security labels, ACLs, etc. Hence per-file crypto information should also use a common, shared xattr format. That way it only needs to be implemented once in the generic code and there's very little (hopefully nothing!) each filesystem has to customise to store the crypto information for each file. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > > This definitions will be used by inode and superblock for encyption. > > How much of this crypto stuff is common with or only slightly > modified from the ext4 code? Is the behaviour and features the > same? Is the user API and management tools the same? > > IMO, if there is any amount of overlap, then we should be > implementing this stuff as generic code, not propagating the same > code through multiple filesystems via copy-n-paste-n-modify. This > will simply end up with diverging code, different bugs and feature > sets, and none of the implementations will get the review and > maintenance they really require... > > And, FWIW, this is the reason why I originally asked for the ext4 > encryption code to be pulled up to the VFS: precisely so we didn't > end up with a rapid proliferation of individual in-filesystem > encryption implementations that are all slightly different... Totally agreed! AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so I believe most part of crypto codes are common. But, in order to realize that quickly, Ted implemented the feature to finalize on-disk and in-memory design in EXT4 as a first step. Then, I've been catching up and validating its design by implementing it in F2FS, which also intends to figure out what crypto codes can be exactly common. As Ted mentioned before, since next android version tries to use per-file encryption, F2FS also needs to support it as quick as possible likewise EXT4. Meanwhile, surely I've been working on writing patches to push them into fs/; currenlty, I did for cryto.c and will do for crypto_key.c and crypto_fname.c. But, it needs to think about crypto_policy.c differently, since it may depend on how each filesystem stores the policy information respectively; we cannot push all the filesystems should use xattrs, right? Anyway, let me take a time to work on this and submit RFC patches. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > This definitions will be used by inode and superblock for encyption. How much of this crypto stuff is common with or only slightly modified from the ext4 code? Is the behaviour and features the same? Is the user API and management tools the same? IMO, if there is any amount of overlap, then we should be implementing this stuff as generic code, not propagating the same code through multiple filesystems via copy-n-paste-n-modify. This will simply end up with diverging code, different bugs and feature sets, and none of the implementations will get the review and maintenance they really require... And, FWIW, this is the reason why I originally asked for the ext4 encryption code to be pulled up to the VFS: precisely so we didn't end up with a rapid proliferation of individual in-filesystem encryption implementations that are all slightly different... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
This definitions will be used by inode and superblock for encyption.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 54 ++
fs/f2fs/f2fs_crypto.h | 149
include/linux/f2fs_fs.h | 4 +-
3 files changed, 206 insertions(+), 1 deletion(-)
create mode 100644 fs/f2fs/f2fs_crypto.h
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 477e65f..c3c4deb 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -70,6 +70,8 @@ struct f2fs_mount_info {
unsigned intopt;
};
+#define F2FS_FEATURE_ENCRYPT 0x0001
+
#define F2FS_HAS_FEATURE(sb, mask) \
((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
#define F2FS_SET_FEATURE(sb, mask) \
@@ -346,6 +348,7 @@ struct f2fs_map_blocks {
*/
#define FADVISE_COLD_BIT 0x01
#define FADVISE_LOST_PINO_BIT 0x02
+#define FADVISE_ENCRYPT_BIT0x04
#define file_is_cold(inode)is_file(inode, FADVISE_COLD_BIT)
#define file_wrong_pino(inode) is_file(inode, FADVISE_LOST_PINO_BIT)
@@ -353,6 +356,16 @@ struct f2fs_map_blocks {
#define file_lost_pino(inode) set_file(inode, FADVISE_LOST_PINO_BIT)
#define file_clear_cold(inode) clear_file(inode, FADVISE_COLD_BIT)
#define file_got_pino(inode) clear_file(inode, FADVISE_LOST_PINO_BIT)
+#define file_is_encrypt(inode) is_file(inode, FADVISE_ENCRYPT_BIT)
+#define file_set_encrypt(inode)set_file(inode, FADVISE_ENCRYPT_BIT)
+#define file_clear_encrypt(inode) clear_file(inode, FADVISE_ENCRYPT_BIT)
+
+/* Encryption algorithms */
+#define F2FS_ENCRYPTION_MODE_INVALID 0
+#define F2FS_ENCRYPTION_MODE_AES_256_XTS 1
+#define F2FS_ENCRYPTION_MODE_AES_256_GCM 2
+#define F2FS_ENCRYPTION_MODE_AES_256_CBC 3
+#define F2FS_ENCRYPTION_MODE_AES_256_CTS 4
#define DEF_DIR_LEVEL 0
@@ -380,6 +393,11 @@ struct f2fs_inode_info {
struct radix_tree_root inmem_root; /* radix tree for inmem pages */
struct list_head inmem_pages; /* inmemory pages managed by f2fs */
struct mutex inmem_lock;/* lock for inmemory pages */
+
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ /* Encryption params */
+ struct f2fs_crypt_info *i_crypt_info;
+#endif
};
static inline void get_extent_info(struct extent_info *ext,
@@ -1891,4 +1909,40 @@ void f2fs_delete_inline_entry(struct f2fs_dir_entry *,
struct page *,
struct inode *, struct inode *);
bool f2fs_empty_inline_dir(struct inode *);
int f2fs_read_inline_dir(struct file *, struct dir_context *);
+
+/*
+ * crypto support
+ */
+static inline int f2fs_encrypted_inode(struct inode *inode)
+{
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ return file_is_encrypt(inode);
+#else
+ return 0;
+#endif
+}
+
+static inline void f2fs_set_encrypted_inode(struct inode *inode)
+{
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ file_set_encrypt(inode);
+#endif
+}
+
+static inline bool f2fs_bio_encrypted(struct bio *bio)
+{
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ return unlikely(bio->bi_private != NULL);
+#else
+ return false;
+#endif
+}
+
+static inline int f2fs_sb_has_crypto(struct super_block *sb)
+{
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ return F2FS_HAS_FEATURE(sb, F2FS_FEATURE_ENCRYPT);
+#else
+ return 0;
+#endif
#endif
diff --git a/fs/f2fs/f2fs_crypto.h b/fs/f2fs/f2fs_crypto.h
new file mode 100644
index 000..cfc37c1
--- /dev/null
+++ b/fs/f2fs/f2fs_crypto.h
@@ -0,0 +1,149 @@
+/*
+ * linux/fs/f2fs/f2fs_crypto.h
+ *
+ * Copied from linux/fs/ext4/ext4_crypto.h
+ *
+ * Copyright (C) 2015, Google, Inc.
+ *
+ * This contains encryption header content for f2fs
+ *
+ * Written by Michael Halcrow, 2015.
+ * Modified by Jaegeuk Kim, 2015.
+ */
+#ifndef _F2FS_CRYPTO_H
+#define _F2FS_CRYPTO_H
+
+#include
+
+#define F2FS_KEY_DESCRIPTOR_SIZE 8
+
+/* Policy provided via an ioctl on the topmost directory */
+struct f2fs_encryption_policy {
+ char version;
+ char contents_encryption_mode;
+ char filenames_encryption_mode;
+ char flags;
+ char master_key_descriptor[F2FS_KEY_DESCRIPTOR_SIZE];
+} __attribute__((__packed__));
+
+#define F2FS_ENCRYPTION_CONTEXT_FORMAT_V1 1
+#define F2FS_KEY_DERIVATION_NONCE_SIZE 16
+
+#define F2FS_POLICY_FLAGS_PAD_40x00
+#define F2FS_POLICY_FLAGS_PAD_80x01
+#define F2FS_POLICY_FLAGS_PAD_16 0x02
+#define F2FS_POLICY_FLAGS_PAD_32 0x03
+#define F2FS_POLICY_FLAGS_PAD_MASK 0x03
+#define F2FS_POLICY_FLAGS_VALID0x03
+
+/**
+ * Encryption context for inode
+ *
+ * Protector format:
+ * 1 byte: Protector format (1 = this version)
+ * 1 byte: File contents encryption mode
+ * 1 byte: File names encryption mode
+ * 1 byte: Flags
+ * 8 bytes: Master Key descriptor
+ * 16 bytes: Encryption Key derivation nonce
+ */
+struct f2fs_encryption_context {
+ char format;
+
