)`` and ``pr_warn*()``
> +issue warnings but do **not** cause the kernel to crash. Use these if you
> +want to prevent such panics.
>
Nacked-by: Eric Biggers
WARN*() are for recoverable assertions, i.e. situations where the condition
being true can only happen due to a kernel bug but whe
Hi Gilad,
On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote:
> Invoking a possibly async. crypto op and waiting for completion
> while correctly handling backlog processing is a common task
> in the crypto API implementation and outside users of it.
>
> This patch re-factors one of
Hi Gilad,
On Sat, May 06, 2017 at 03:59:56PM +0300, Gilad Ben-Yossef wrote:
> int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw,
> u64 lblk_num, struct page *src_page,
> struct page *dest_page, unsigned int len,
> @@ -15
On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote:
> > With regards to the wait being uninterruptible, I agree that this should be
> > the
> > default behavior, because I think users waiting for specific crypto
> > requests are
> > generally not prepared to handle the wait actually
rrupting the output buffer.
>
> Resolve this by using wait_for_completion() instead.
>
> Reported-by: Eric Biggers
> Signed-off-by: Gilad Ben-Yossef
> CC: sta...@vger.kernel.org
> ---
> crypto/drbg.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
&g
MA from/into the buffers.
>
> Resolve this by using wait_for_completion() instead.
>
> Reported-by: Eric Biggers
> Signed-off-by: Gilad Ben-Yossef
> ---
> Documentation/crypto/api-samples.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
Hi André,
On Wed, Jan 10, 2018 at 12:44:18PM +, André Draszik wrote:
> diff --git a/Documentation/security/keys/fscrypt.rst
> b/Documentation/security/keys/fscrypt.rst
> new file mode 100644
> index ..e4a29592513e
> --- /dev/null
> +++ b/Documentation/security/keys/fscrypt.rst
> @
On Thu, Nov 02, 2017 at 11:06:05AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When keyctl_read() is passed a buffer that is too small, the behavior is
> inconsistent. Some key types will fill as much of the buffer as
> possible, while others won't copy anythin
On Tue, Dec 04, 2018 at 03:26:44PM +0530, Chandan Rajendra wrote:
> This commit removes the ext4 specific ext4_encrypted_inode() and makes
> use of the generic IS_ENCRYPTED() macro to check for the encryption
> status of an inode.
>
> Signed-off-by: Chandan Rajendra
Reviewed-b
On Tue, Dec 04, 2018 at 03:26:45PM +0530, Chandan Rajendra wrote:
> This commit removes the f2fs specific f2fs_encrypted_inode() and makes
> use of the generic IS_ENCRYPTED() macro to check for the encryption
> status of an inode.
>
> Acked-by: Chao Yu
> Signed-off-by: Chandan Rajendra
This com
Hi Chandan,
On Tue, Dec 04, 2018 at 03:26:46PM +0530, Chandan Rajendra wrote:
> In order to have a common code base for fscrypt "post read" processing
> for all filesystems which support encryption, this commit removes
> filesystem specific build config option (e.g. CONFIG_EXT4_FS_ENCRYPTION)
> an
> #define IS_ENCRYPTED(inode) ((inode)->i_flags & S_ENCRYPTED)
> +#define IS_VERITY(inode) ((inode)->i_flags & S_VERITY)
>
> #define IS_WHITEOUT(inode) (S_ISCHR(inode->i_mode) && \
>(inode)->i_rdev == WHITEOUT_DEV)
> --
> 2.19.1
>
Reviewed-by: Eric Biggers
100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1344,6 +1344,7 @@ static int ext4_set_verity(struct inode *inode, loff_t
> data_i_size)
> err = ext4_reserve_inode_write(handle, inode, &iloc);
> if (err == 0) {
> ext4_set_inode_flag(ino
Hi Chandan,
On Tue, Dec 04, 2018 at 03:26:49PM +0530, Chandan Rajendra wrote:
> This commit now uses IS_VERITY() macro to check if fsverity is
> enabled on an inode.
>
> Acked-by: Chao Yu
> Signed-off-by: Chandan Rajendra
> ---
> fs/f2fs/file.c | 6 +++---
> fs/f2fs/inode.c | 4 +++-
> 2 file
On Tue, Dec 04, 2018 at 03:26:46PM +0530, Chandan Rajendra wrote:
> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> index 952ab97af325..6ba193c23f37 100644
> --- a/include/linux/fscrypt.h
> +++ b/include/linux/fscrypt.h
> @@ -2,9 +2,8 @@
> /*
> * fscrypt.h: declarations for per-
Hi Chandan,
On Tue, Dec 04, 2018 at 03:26:50PM +0530, Chandan Rajendra wrote:
> In order to have a common code base for fsverity "post read" processing
> for all filesystems which support fsverity, this commit removes
> filesystem specific build config option (e.g. CONFIG_EXT4_FS_VERITY)
> and rep
Hi Chandan,
On Sat, Dec 08, 2018 at 12:21:43PM +0530, Chandan Rajendra wrote:
> Instead of conditionally checking for verity status of an inode before
> invoking fsverity_file_open(), this commit moves the check inside the
> definition of fsverity_file_open().
>
> Signed-off-by: Chandan Rajendra
On Sat, Dec 08, 2018 at 12:37:20PM +0530, Chandan Rajendra wrote:
> On Wednesday, December 5, 2018 5:13:21 AM IST Eric Biggers wrote:
> > Hi Chandan,
> >
> > On Tue, Dec 04, 2018 at 03:26:46PM +0530, Chandan Rajendra wrote:
> > > In order to have a common co
: Chandan Rajendra
Reviewed-by: Eric Biggers
> ---
> fs/f2fs/data.c | 4 ++--
> fs/f2fs/dir.c | 10 +-
> fs/f2fs/f2fs.h | 7 +--
> fs/f2fs/file.c | 10 +-
> fs/f2fs/inode.c | 4 ++--
> fs/f2fs/namei.c | 6 +++---
> 6 files changed, 18 insertions(+),
ION)
> and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
> value affects all the filesystems making use of fscrypt.
>
> Signed-off-by: Chandan Rajendra
Reviewed-by: Eric Biggers
> ---
> Documentation/filesystems/fscrypt.rst | 4 +-
> arch/mips/config
On Sat, Dec 08, 2018 at 12:21:41PM +0530, Chandan Rajendra wrote:
> This commit removes the f2fs specific f2fs_verity_file() and makes use
> of the generic IS_VERITY() macro or file_is_verity() to check for the
> verity status of an inode.
>
> Signed-off-by: Chandan Rajendra
Re
)
> and replaces it with a build option (i.e. CONFIG_FS_VERITY) whose
> value affects all the filesystems making use of fsverity.
>
> Signed-off-by: Chandan Rajendra
Reviewed-by: Eric Biggers
> ---
> Documentation/filesystems/fsverity.rst | 4 ++--
> fs/
On Tue, Dec 11, 2018 at 05:52:11PM -0800, Guenter Roeck wrote:
> Hi,
>
> On Tue, Dec 04, 2018 at 03:26:46PM +0530, Chandan Rajendra wrote:
> > In order to have a common code base for fscrypt "post read" processing
> > for all filesystems which support encryption, this commit removes
> > filesystem
From: Eric Biggers
Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory. The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc
On Sat, Aug 19, 2017 at 10:32:27PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> > On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote:
> > > +Key hierarchy
> > > +=
> > > +
> > > +Maste
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote:
>
>
> >+fscrypt is not guaranteed to protect confidentiality or authenticity
> >+if an attacker is able to manipulate the filesystem offline prior to
> >+an authorized user later accessing the filesystem.
>
> How does fscrypt / Android
On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
>
> Hi Eric,
>
> How about a section on the threat model specific to the file-name ?
>
> (Sorry if I am missing something).
>
> Thanks, Anand
It's already mentioned that filenames are encrypted: "fscrypt protects the
confidentiali
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote:
>
>
>
> > > > +fscrypt is not guaranteed to protect confidentiality or authenticity
> > > > +if an attacker is able to manipulate the filesystem offline prior to
> > > > +an authorized user later accessing the filesystem.
> > >
> > >
On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
>
>
> On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> >>
> >>Hi Eric,
> >>
> >> How about a section on the threat model
On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
> >>
> >> I think AE is the only good solution for this, File-name encryption at
> >>this stage won't solve any kind of Evil Maid attack, (as it was quoted
> >>somewhere else in ML).
> >>
> >>
> >> Further, below, is define but not use
Hi Anand,
On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
>
>
> On 08/23/2017 01:07 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
> >>
> >>
> >>On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >&
Hi Anand,
On Tue, Aug 29, 2017 at 11:54:47AM +0800, Anand Jain wrote:
>
> BTRFS has an experimental fscrypt implementation[1] which does not
> include the file-name encryption part it should be included but as
> an optional since not all uses cases saves sensitive information in
> the file-name.
On Mon, Aug 28, 2017 at 08:18:55PM +0800, Anand Jain wrote:
>
>
> On 08/23/2017 01:36 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
> >>>>
> >>>> I think AE is the only good solution for this, File-name e
From: Eric Biggers
Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory. The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc
Hi Michael,
On Fri, Sep 01, 2017 at 05:12:28PM -0700, Michael Halcrow wrote:
> > +fscrypt is only resistant to side-channel attacks, such as timing or
> > +electromagnetic attacks, to the extent that the underlying Linux
> > +Cryptographic API algorithms are. If a vulnerable algorithm is used,
>
From: Eric Biggers
Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory. The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc
On Fri, Sep 08, 2017 at 05:15:12PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Perhaps long overdue, add a documentation file for filesystem-level
> encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
> directory. The new file is based loosely on the latest
From: Eric Biggers
When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent. Some key types will fill as much of the buffer as
possible, while others won't copy anything. Moreover, the in-kernel
documentation contradicted the man page on this point.
Update t
On Wed, Nov 01, 2017 at 01:57:18PM +, David Howells wrote:
> Eric Biggers wrote:
>
> > - As much of the data as can be fitted into the buffer will be copied to
> > - userspace if the buffer pointer is not NULL.
> > -
> > - On a successful return, t
From: Eric Biggers
When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent. Some key types will fill as much of the buffer as
possible, while others won't copy anything. Moreover, the in-kernel
documentation contradicted the man page on this point.
Update t
From: Eric Biggers
When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent. Some key types will fill as much of the buffer as
possible, while others won't copy anything. Moreover, the in-kernel
documentation contradicted the man page on this point.
Update th
Update the documentation for crypto_register_algs() and
crypto_unregister_algs() to match the actual behavior.
Signed-off-by: Eric Biggers
---
Documentation/DocBook/crypto-API.tmpl | 38 ---
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a
On Tue, Feb 20, 2018 at 11:42:34AM -0800, Eric Biggers wrote:
> On Thu, Nov 02, 2017 at 11:06:05AM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > When keyctl_read() is passed a buffer that is too small, the behavior is
> > inconsistent. Some key types will
Signed-off-by: Eric Biggers
---
Documentation/DocBook/crypto-API.tmpl | 6 +++---
include/crypto/aead.h | 3 +--
include/crypto/hash.h | 3 +--
include/crypto/skcipher.h | 3 +--
include/linux/crypto.h| 3 +--
5 files changed, 7
Update the documentation for crypto_register_algs() and
crypto_unregister_algs() to match the actual behavior.
Signed-off-by: Eric Biggers
---
Documentation/DocBook/crypto-API.tmpl | 38 ---
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a
45 matches
Mail list logo
