,7 @@ struct mtd_blktrans_dev {
> struct blk_mq_tag_set *tag_set;
> spinlock_t queue_lock;
> void *priv;
> - fmode_t file_mode;
> + bool writable;
> };
Acked-by: Richard Weinberger
Thanks,
//richard
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
flags.w){
> - if(--ubd_dev->count == 0) ubd_close_dev(ubd_dev);
> - err = -EROFS;
> - }*/
Acked-by: Richard Weinberger
Thanks,
//richard
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
f2fs, ceph).
> To fix that, introduce a new page_mkwrite_check_truncate helper that
> checks for truncate and computes the bytes in the page up to EOF, and
> use that helper in the above mentioned filesystems and in btrfs.
>
> Signed-off-by: Andreas Gruenbacher
Thank you for fixing UBIFS!
Acked-by: Richard Weinberger
Thanks,
//richard
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Hi!
I consider adding file encryption to UBIFS.
While looking into ext4 and f2fs I realized that both
use the same data structures/concepts.
f2fs copy&pasted a lot from ext4.
Before I do the next copy&paste, I'd to ask whether it would make sense
to more parts of the ioctl() interface out to VFS?
On Fri, Dec 21, 2018 at 9:58 AM Christoph Hellwig wrote:
>
> On Thu, Dec 20, 2018 at 05:01:58PM -0500, Theodore Y. Ts'o wrote:
> > That's simply not true. Number one, fsverity is not mandatory for all
> > file systems to implement. If XFS doesn't want to implement fscrypt
> > or fsverity, it doe
On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
>
> From: Eric Biggers
>
> Add an ->s_master_keys keyring to 'struct super_block'. New fscrypt
> ioctls will allow adding and removing encryption keys from this keyring.
> This will enable solving multiple interrelated problems with how fscrypt
On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
> +#define FSCRYPT_FS_KEYRING_DESCRIPTION_SIZE\
> + (CONST_STRLEN("fscrypt-") + FIELD_SIZEOF(struct super_block, s_id))
> +
> +#define FSCRYPT_MK_DESCRIPTION_SIZE(2 * FSCRYPT_KEY_DESCRIPTOR_SIZE + 1)
> +
> +static void format_fs_key
Eric,
Am Donnerstag, 21. Februar 2019, 06:49:39 CET schrieb Eric Biggers:
> Hi Richard,
>
> On Thu, Feb 21, 2019 at 12:52:38AM +0100, Richard Weinberger wrote:
> > On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
> > > +#define FSCRYPT_FS_
Ericm
Am Dienstag, 19. März 2019, 00:08:31 CET schrieb Eric Biggers:
> I tried using sb->s_bdi->name, but it's still "ubifs" for all UBIFS
> filesystems.
hmpf.
> Perhaps there's a way you can make ->s_id for UBIFS unique? There are already
> existing places that log ->s_id, so perhaps you sho
Am Montag, 1. April 2019, 19:11:21 CEST schrieb Eric Biggers:
> Any more comments on these patches? I'd like to apply them to the fscrypt
> tree
> for 5.2. Richard, can you check whether these solve your overlayfs use case?
> Also, patch 5 could use Acks from ext4, f2fs, and ubifs people.
Wil
Hi!
While reading the fscrypt code I noticed that some functions use the bounce
pages
and some not.
fscrypt_decrypt_page() and fscrypt_decrypt_bio_pages() work in-place while
fscrypt_encrypt_page() and fscrypt_zeroout_range() use a bounce page.
So, both ext4 and f2fs encrypt data using an extra
Hi!
Both ext4 and f2fs check in the file open code the context of the parent
directory too:
ext4:
if (ext4_encrypted_inode(d_inode(dir)) &&
!fscrypt_has_permitted_context(d_inode(dir), inode)) {
ext4_warning(inode->i_sb,
Ted,
On 22.09.2016 15:14, Theodore Ts'o wrote:
> On Thu, Sep 22, 2016 at 10:49:41AM +0200, Richard Weinberger wrote:
>>
>> While reading the fscrypt code I noticed that some functions use the bounce
>> pages
>> and some not.
>> fscrypt_decrypt_page() and fsc
Ted,
On 22.09.2016 15:44, Theodore Ts'o wrote:
> On Thu, Sep 22, 2016 at 02:24:35PM +0200, Richard Weinberger wrote:
>> Why do we need this check? AFAIK this situation can never happen unless due
>> to
>> a bug in the filesystem code.
>
> Or in the case of a mal
be created in the directory during or after the
> ->empty_dir() check.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Richard Weinberger
Thanks,
//richard
--
___
Eric,
On Fri, Sep 30, 2016 at 7:58 PM, Eric Biggers wrote:
> The XTS tweak (or IV) was initialized differently on little endian and
> big endian systems. Because the ciphertext depends on the XTS tweak, it
> was not possible to use an encrypted filesystem created by a little
> endian system on a
Eric,
On 03.10.2016 20:03, Eric Biggers wrote:
>>> {
>>> - u8 xts_tweak[FS_XTS_TWEAK_SIZE];
>>> + struct {
>>> + __le64 index;
>>> + u8 padding[FS_XTS_TWEAK_SIZE - sizeof(__le64)];
>>> + } xts_tweak;
>>
>> While we are here, wouldn't it make sense to
Michael,
On 05.10.2016 20:23, Michael Halcrow wrote:
>> Eric,
>>
>>> On 04.10.2016, at 18:38, Eric Biggers wrote:
>>>
>>> On Tue, Oct 04, 2016 at 10:46:54AM +0200, Richard Weinberger wrote:
>>>>> Also, currently this code *is* only su
Michael,
On 05.10.2016 20:44, Richard Weinberger wrote:
> Well, let's focus first on file contents.
> We have already the fscrypo framework.
>
> What you suggest is completely different from what we have now.
To clarify that, I'm not saying that meta-data or block level a
Michael,
On 05.10.2016 23:11, Michael Halcrow wrote:
>>> In the meantime, to address the CBC thing, I'd want to understand what
>>> the hardware is doing exactly. I wouldn't want the existence of code
>>> that supports CBC in fs/crypto to be interpreted as some sort of
>>> endorsement for using i
Eric,
On Mon, Oct 17, 2016 at 6:54 PM, Eric Biggers wrote:
> Multiple bugs were recently fixed in the "set encryption policy" ioctl.
> To make it clear that fscrypt_process_policy() and fscrypt_get_policy()
> implement ioctls and therefore their implementations must take standard
> security and c
Hi!
Since file level encryption has more than one user, currently ext4, f2fs and
soon ubifs
it would be nice to have a single tool to control fscrypto from userspace.
For ext4 we have already at least two tools, one as part of e2fsprogs and
another
one on github[0]. IMHO the latter one is much
Michael,
On 19.10.2016 19:36, Michael Halcrow wrote:
> On Wed, Oct 19, 2016 at 4:35 AM, Richard Weinberger wrote:
>> Hi!
>>
>> Since file level encryption has more than one user, currently ext4, f2fs and
>> soon ubifs
>> it would be nice to have a single tool t
"). So it sounds like there may be a dependency
> problem elsewhere, which I have not been able to identify specifically,
> that must be solved before CTR can be removed.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Richard Weinberger
FWIW, Strictly speaking we could also get ri
On 24.10.2016 22:29, Eric Biggers wrote:
> The filesystem level encryption support, currently used by ext4 and f2fs
> and proposed for ubifs, does not yet have a dedicated mailing list.
> Since no mailing lists were specified in MAINTAINERS, get_maintainer.pl
> only recommended to send patches dire
tion */
> res = crypto_skcipher_encrypt(req);
> if (res == -EINPROGRESS || res == -EBUSY) {
> + /* Request is being completed asynchronously; wait for it */
> wait_for_com
, NULL, crypt_info) != NULL) {
> put_crypt_info(crypt_info);
> goto retry;
> @@ -287,7 +297,7 @@ int get_crypt_info(struct inode *inode)
> if (res == -ENOKEY)
> res = 0;
> p
Michael,
On 19.10.2016 19:36, Michael Halcrow wrote:
>> That said, what about implementing such a tool as part of util-linux to
>> control
>> fscrypto? We (David and I) would volunteer.
>
> While discussing several changes we have staged for release (we're
> trying to minimize churn by batching
Joe,
On 29.11.2016 22:42, Joe Richey wrote:
> Hi Richard,
>
> I'm Joe Richey, and I work on Mike's team. We've been playing around
> with a few design
> ideas regarding a tool for managing filesystem encryption. After going
> though some iterations
> with Ted, we have a fairly good idea about whe
Eric,
On 30.11.2016 01:04, Eric Biggers wrote:
> On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote:
>>
>> Do you also plan to address d/page cache related issues?
>> i.e. when two users are logged into the system user rw
>> is able to see decrypted
rypt_info structs because the
> key is unavailable, compare the fscrypt_context structs instead.
>
> This will be covered by a test in my encryption xfstests patchset.
>
> Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
> Signed-off-by:
On 15.12.2016 20:19, Eric Biggers wrote:
> From: Eric Biggers
>
> Now that fscrypt_has_permitted_context() compares the fscrypt_context
> rather than the fscrypt_info when needed, it is no longer necessary to
> delay fscrypt_has_permitted_context() from ->lookup() to ->open() for
> regular files,
s.
>
> This will be covered by a test in my encryption xfstests patchset.
>
> Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt
> support")
> Signed-off-by: Eric
Eric,
On Wed, Apr 19, 2017 at 1:01 AM, Eric Biggers wrote:
> +Cc linux-f2fs-devel@lists.sourceforge.net
> +Cc linux-...@lists.infradead.org (for ubifs)
>
> Hi Gwendal,
>
> On Tue, Apr 18, 2017 at 02:06:42PM -0700, Gwendal Grignou wrote:
>> If we use only 16 bytes, due to how CBC works, if the nam
Am 19.04.2017 um 19:16 schrieb Eric Biggers:
> On Wed, Apr 19, 2017 at 03:40:13PM +0200, Richard Weinberger wrote:
>>> Strangely, f2fs and ubifs do not use the bytes from the filename at all when
>>> trying to find a specific directory entry in this case. So this patch
&
Eric,
On Wed, Apr 19, 2017 at 7:21 PM, Richard Weinberger wrote:
>> Well, like I said to Jaegeuk for F2FS, that's what the code does, but _why_?
>> Like F2FS, it's probably not the case that the hash is sufficient to reliably
>> identify a directory entry. Granted
Eric, Jaegeuk,
On Mon, Apr 24, 2017 at 7:00 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> Switch f2fs directory searches to use the fscrypt_match_name() helper
> function. There should be no functional change.
> -#ifdef CONFIG_F2FS_FS_ENCRYPTION
> - if (unlikely(!name->name))
Eric,
Am 25.04.2017 um 19:46 schrieb Eric Biggers:
>> Sorry if this is a stupid question, but why do you have to compare hashes
>> _and_
>> the last few bytes of the bigname?
>> A lookup via bigname gives you two 32bits hash values, and there I'd assume
>> that
>> this is sufficient for a collis
Eric,
Am 25.04.2017 um 22:58 schrieb Eric Biggers:
> On Tue, Apr 25, 2017 at 09:22:16PM +0200, Richard Weinberger wrote:
>> Eric,
>>
>> Am 25.04.2017 um 19:46 schrieb Eric Biggers:
>>>> Sorry if this is a stupid question, but why do you have to compare hashes
&
Eric,
On Thu, Apr 27, 2017 at 1:43 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Now that there has been a dedicated mailing list, patchwork project, and
> git repository set up for filesystem encryption, update the MAINTAINERS
> file accordingly.
>
> Signed-off-by: Eric Biggers
> ---
> MAI
Eric,
Am 27.04.2017 um 19:45 schrieb Eric Biggers:
> On Thu, Apr 27, 2017 at 09:37:18AM +0200, Richard Weinberger wrote:
>>> +FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
>>> M: Theodore Y. Ts'o
>>> M: Jaegeuk Kim
>>
>> IMHO we should al
;
> Signed-off-by: Eric Biggers
Acked-by: Richard Weinberger
--
Thanks,
//richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdo
Ted, Eric,
Am 23.06.2017 um 19:18 schrieb Eric Biggers:
> Ted + Richard,
>
> On Fri, Jun 23, 2017 at 12:09:07PM -0400, Theodore Ts'o wrote:
>> On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote:
>>> On Tue, May 23, 2017 at 2:39 AM, Eric Biggers w
43 matches
Mail list logo
