Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

Hi! > On 25.03.2021, at 06:26, Sumit Garg wrote: > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum wrote: >> >> Hello Sumit, >> >> On 24.03.21 11:47, Sumit Garg wrote: >>> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum wrote: Hello Mimi, On 23.03.21 19:07, Mimi Zohar wrote:

Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.

Hi! > On 03.08.2018, at 20:28, Mimi Zohar wrote: > > If they have symmetric key support, there would be no need for > the > symmetric key ever to leave the device in the clear. The device > would unseal/decrypt data, such as an encrypted key. > > The "symmetric" key

Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.

Hi! > On 03.08.2018, at 20:28, Mimi Zohar wrote: > > If they have symmetric key support, there would be no need for > the > symmetric key ever to leave the device in the clear. The device > would unseal/decrypt data, such as an encrypted key. > > The "symmetric" key

Re: [RFC] UBIFS authentication

Hi Sascha, > On 10.04.2018, at 09:02, Sascha Hauer <s.ha...@pengutronix.de> wrote: > > On Mon, Apr 09, 2018 at 05:23:05PM +0200, David Gstir wrote: >> Hi Sascha, >> >>> On 09.04.2018, at 11:59, Sascha Hauer <s.ha...@pengutronix.de> wrote: >>>

Re: [RFC] UBIFS authentication

Hi Sascha, > On 10.04.2018, at 09:02, Sascha Hauer wrote: > > On Mon, Apr 09, 2018 at 05:23:05PM +0200, David Gstir wrote: >> Hi Sascha, >> >>> On 09.04.2018, at 11:59, Sascha Hauer wrote: >>> >>> Hi David, >>> >>> On

Re: [RFC] UBIFS authentication

Hi Sascha, > On 09.04.2018, at 11:59, Sascha Hauer <s.ha...@pengutronix.de> wrote: > > Hi David, > > On Wed, Jan 17, 2018 at 04:19:14PM +0100, David Gstir wrote: >> Hi everybody! >> >> ### Index Authentication >> >> Through UBIFS' concept

Re: [RFC] UBIFS authentication

Hi Sascha, > On 09.04.2018, at 11:59, Sascha Hauer wrote: > > Hi David, > > On Wed, Jan 17, 2018 at 04:19:14PM +0100, David Gstir wrote: >> Hi everybody! >> >> ### Index Authentication >> >> Through UBIFS' concept of a wandering tree, it already

Re: [RFC] UBIFS authentication

Hi! > On 17.01.2018, at 16:19, David Gstir <da...@sigma-star.at> wrote: > > Hi everybody! > > Richard and I have been working on extending UBIFS' security features and came > up with the following concept to add full file contents and metadata > authentication.

Re: [RFC] UBIFS authentication

Hi! > On 17.01.2018, at 16:19, David Gstir wrote: > > Hi everybody! > > Richard and I have been working on extending UBIFS' security features and came > up with the following concept to add full file contents and metadata > authentication. > > For block devices

[RFC] UBIFS authentication

Hi everybody! Richard and I have been working on extending UBIFS' security features and came up with the following concept to add full file contents and metadata authentication. For block devices like eMMCs dm-crypt and dm-verity/dm-integrity can be used to get full data confidentiality and

[RFC] UBIFS authentication

Hi everybody! Richard and I have been working on extending UBIFS' security features and came up with the following concept to add full file contents and metadata authentication. For block devices like eMMCs dm-crypt and dm-verity/dm-integrity can be used to get full data confidentiality and

[PATCH] crypto: caam - properly set IV after {en,de}crypt

r.kernel.org> # 4.8+ Signed-off-by: David Gstir <da...@sigma-star.at> --- drivers/crypto/caam/caamalg.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index 398807d1b77e..c45b5bf65254

[PATCH] crypto: caam - properly set IV after {en,de}crypt

) when the CAAM driver is enabled. This patch fixes the CAAM driver to properly set the IV after the {en,de}crypt operation of ablkcipher finishes. This issue was revealed by the changes in the SW CTS mode in commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") Cc: # 4.8+ Sign

Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

Horia, > On 28 Jun 2017, at 10:32, Horia Geantă wrote: > >>> + sg_pcopy_to_buffer(req->dst, nents, req->info, ivsize, >>> + req->nbytes - ivsize); >> >> scatterwalk_map_and_copy() should be used instead. >> > David, IIUC this is the only change

Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

Horia, > On 28 Jun 2017, at 10:32, Horia Geantă wrote: > >>> + sg_pcopy_to_buffer(req->dst, nents, req->info, ivsize, >>> + req->nbytes - ivsize); >> >> scatterwalk_map_and_copy() should be used instead. >> > David, IIUC this is the only change needed in this patch

Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

Herbert, > On 20 Jun 2017, at 03:28, Herbert Xu wrote: > > On Mon, Jun 19, 2017 at 10:31:27AM +, Horia Geantă wrote: >> >> IIUC, IV update is required only in case of CBC. >> Since this callback is used also for CTR, we should avoid the copy: >> if

Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

Herbert, > On 20 Jun 2017, at 03:28, Herbert Xu wrote: > > On Mon, Jun 19, 2017 at 10:31:27AM +, Horia Geantă wrote: >> >> IIUC, IV update is required only in case of CBC. >> Since this callback is used also for CTR, we should avoid the copy: >> if ((ctx->cdata.algtype & OP_ALG_AAI_MASK)

[PATCH v5] fscrypt: Add support for AES-128-CBC

a few kB. Signed-off-by: Daniel Walter <dwal...@sigma-star.at> [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir <da...@sigma-star.at> Reviewed-by: Eric Biggers <ebigg...@google.com> --- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c

[PATCH v5] fscrypt: Add support for AES-128-CBC

-by: Daniel Walter [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir Reviewed-by: Eric Biggers --- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 23 -- fs/crypto/fscrypt_private.h| 9 ++- fs/crypto/keyinfo.c| 173

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Horia, > On 16 Jun 2017, at 23:01, Horia Geantă wrote: > > On 6/16/2017 11:00 AM, Herbert Xu wrote: >> On Fri, Jun 16, 2017 at 07:57:00AM +, Horia Geantă wrote: >>> >>> Commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") appends >>> CRYPTO_TFM_REQ_MAY_BACKLOG

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Horia, > On 16 Jun 2017, at 23:01, Horia Geantă wrote: > > On 6/16/2017 11:00 AM, Herbert Xu wrote: >> On Fri, Jun 16, 2017 at 07:57:00AM +, Horia Geantă wrote: >>> >>> Commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") appends >>> CRYPTO_TFM_REQ_MAY_BACKLOG to the original crypto

Re: [PATCH v4] fscrypt: Add support for AES-128-CBC

> On 15 Jun 2017, at 22:48, Eric Biggers wrote: > > On Thu, Jun 15, 2017 at 01:41:29PM -0700, Michael Halcrow wrote: >>> static int validate_user_key(struct fscrypt_info *crypt_info, >>> struct fscrypt_context *ctx, u8 *raw_key, >>> -

Re: [PATCH v4] fscrypt: Add support for AES-128-CBC

> On 15 Jun 2017, at 22:48, Eric Biggers wrote: > > On Thu, Jun 15, 2017 at 01:41:29PM -0700, Michael Halcrow wrote: >>> static int validate_user_key(struct fscrypt_info *crypt_info, >>> struct fscrypt_context *ctx, u8 *raw_key, >>> - const char *prefix)

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Friendly ping. Any feedback on that? Thanks, David > On 2 Jun 2017, at 14:24, David Gstir <da...@sigma-star.at> wrote: > > Hi! > > While testing fscrypt's filename encryption, I noticed that the implementation > of cts(cbc(aes)) is broken when the CAAM hardware crypto d

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Friendly ping. Any feedback on that? Thanks, David > On 2 Jun 2017, at 14:24, David Gstir wrote: > > Hi! > > While testing fscrypt's filename encryption, I noticed that the implementation > of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled. >

[RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Hi! While testing fscrypt's filename encryption, I noticed that the implementation of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled. Some digging showed that the refactoring of crypto/cts.c in v4.8 (commit 0605c41cc53ca) exposed some problems with CAAM's aes-cbc

[RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Hi! While testing fscrypt's filename encryption, I noticed that the implementation of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled. Some digging showed that the refactoring of crypto/cts.c in v4.8 (commit 0605c41cc53ca) exposed some problems with CAAM's aes-cbc

[RFC PATCH 2/2] crypto: caam - fix k*alloc if called from own cipher callback

flags. In most cases we will still use GFP_KERNEL if the flags CRYPTO_TFM_REQ_MAY_SLEEP or CRYPTO_TFM_REQ_MAY_BACKLOG are set for the cipher request. Signed-off-by: David Gstir <da...@sigma-star.at> --- drivers/crypto/caam/caamalg.c | 29 + 1 file changed, 21 inse

[RFC PATCH 2/2] crypto: caam - fix k*alloc if called from own cipher callback

flags. In most cases we will still use GFP_KERNEL if the flags CRYPTO_TFM_REQ_MAY_SLEEP or CRYPTO_TFM_REQ_MAY_BACKLOG are set for the cipher request. Signed-off-by: David Gstir --- drivers/crypto/caam/caamalg.c | 29 + 1 file changed, 21 insertions(+), 8 deletions

[RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

) when the CAAM driver is enabled. This patch fixes the CAAM driver to properly set the IV after the {en,de}crypt operation of ablkcipher finishes. Signed-off-by: David Gstir <da...@sigma-star.at> --- drivers/crypto/caam/caamalg.c | 26 -- 1 file changed, 24 inse

[RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

) when the CAAM driver is enabled. This patch fixes the CAAM driver to properly set the IV after the {en,de}crypt operation of ablkcipher finishes. Signed-off-by: David Gstir --- drivers/crypto/caam/caamalg.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff

Re: [PATCH v4] fscrypt: Add support for AES-128-CBC

Hi Eric, > On 23 May 2017, at 21:00, Eric Biggers <ebigge...@gmail.com> wrote: > > Hi David, > > On Tue, May 23, 2017 at 07:11:20AM +0200, David Gstir wrote: >> From: Daniel Walter <dwal...@sigma-star.at> >> >> fscrypt provides facilities

Re: [PATCH v4] fscrypt: Add support for AES-128-CBC

Hi Eric, > On 23 May 2017, at 21:00, Eric Biggers wrote: > > Hi David, > > On Tue, May 23, 2017 at 07:11:20AM +0200, David Gstir wrote: >> From: Daniel Walter >> >> fscrypt provides facilities to use different encryption algorithms which >> a

[PATCH v4] fscrypt: Add support for AES-128-CBC

a few kB. Signed-off-by: Daniel Walter <dwal...@sigma-star.at> [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 23 -- fs/crypto/fscrypt_private.h|

[PATCH v4] fscrypt: Add support for AES-128-CBC

-by: Daniel Walter [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir --- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 23 -- fs/crypto/fscrypt_private.h| 9 ++- fs/crypto/keyinfo.c| 171

Re: [PATCH v3] fscrypt: Add support for AES-128-CBC

[resend without the HTML crap - sorry about that!] Hi Eric! Thanks for the thorough review! :) > On 17 May 2017, at 20:08, Eric Biggers <ebigge...@gmail.com> wrote: > > Hi David, thanks for the update! > > On Wed, May 17, 2017 at 01:21:04PM +0200, David Gstir wrote: &

Re: [PATCH v3] fscrypt: Add support for AES-128-CBC

[resend without the HTML crap - sorry about that!] Hi Eric! Thanks for the thorough review! :) > On 17 May 2017, at 20:08, Eric Biggers wrote: > > Hi David, thanks for the update! > > On Wed, May 17, 2017 at 01:21:04PM +0200, David Gstir wrote: >> From: Daniel Walter &g

[PATCH] ubifs: Don't encrypt special files on creation

kernel.org Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/ubifs/dir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 566079d9b402..c67f6a3a606c 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -143,6 +143,7 @@ struct inode *ubifs_

[PATCH] ubifs: Don't encrypt special files on creation

kernel.org Signed-off-by: David Gstir --- fs/ubifs/dir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 566079d9b402..c67f6a3a606c 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -143,6 +143,7 @@ struct inode *ubifs_new_inode(struct ubifs_info *c, str

[PATCH v3] fscrypt: Add support for AES-128-CBC

ves us the acceptable performance while still providing a moderate level of security for persistent storage. Signed-off-by: Daniel Walter <dwal...@sigma-star.at> [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/Kconfig

[PATCH v3] fscrypt: Add support for AES-128-CBC

while still providing a moderate level of security for persistent storage. Signed-off-by: Daniel Walter [da...@sigma-star.at: addressed review comments] Signed-off-by: David Gstir --- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 23 +-- fs/crypto/fscrypt_private.h

Re: [PATCH v2] fscrypt: Add support for AES-128-CBC

Hi Eric! Thanks for the feedback! > On 25 Apr 2017, at 22:10, Eric Biggers <ebigge...@gmail.com> wrote: > > Hi Daniel and David, > > On Tue, Apr 25, 2017 at 04:41:00PM +0200, David Gstir wrote: >> @@ -147,17 +148,28 @@ int fscrypt_do_page_crypt

Re: [PATCH v2] fscrypt: Add support for AES-128-CBC

Hi Eric! Thanks for the feedback! > On 25 Apr 2017, at 22:10, Eric Biggers wrote: > > Hi Daniel and David, > > On Tue, Apr 25, 2017 at 04:41:00PM +0200, David Gstir wrote: >> @@ -147,17 +148,28 @@ int fscrypt_do_page_crypto(const struct inode *inode, >

[PATCH v2] fscrypt: Add support for AES-128-CBC

ves us the acceptable performance while still providing a moderate level of security for persistent storage. Signed-off-by: Daniel Walter <dwal...@sigma-star.at> [da...@sigma-star.at: massaged commit message] Signed-off-by: David Gstir <da...@sigma-star.at> --- v2: Compute ESSIV salt us

[PATCH v2] fscrypt: Add support for AES-128-CBC

while still providing a moderate level of security for persistent storage. Signed-off-by: Daniel Walter [da...@sigma-star.at: massaged commit message] Signed-off-by: David Gstir --- v2: Compute ESSIV salt using SHA256 instead of SHA1 and improve style as pointed out by Eric Biggers [1]. [1

Re: [PATCH] fscrypt: Add support for AES-128-CBC

0, 2017 at 07:38:40PM +0200, David Gstir wrote: >> From: Daniel Walter <dwal...@sigma-star.at> >> >> fscrypt provides facilities to use different encryption algorithms which are >> selectable by userspace when setting the encryption policy. Currently, only >> A

Re: [PATCH] fscrypt: Add support for AES-128-CBC

Hi Eric, thanks for the feedback! > On 31.03.2017, at 08:21, Eric Biggers wrote: > > [+Cc linux-fscrypt] Oh, I didn't know about that list. I think MAINTAINERS should be updated to reflect that. :) > > Hi David and Daniel, > > On Thu, Mar 30, 2017 at 07:38:40PM +02

[PATCH] fscrypt: Add support for AES-128-CBC

ves us the acceptable performance while still providing a moderate level of security for persistent storage. [david: massaged commit message] Signed-off-by: Daniel Walter <dwal...@sigma-star.at> Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/crypto.c | 25 +

[PATCH] fscrypt: Add support for AES-128-CBC

still providing a moderate level of security for persistent storage. [david: massaged commit message] Signed-off-by: Daniel Walter Signed-off-by: David Gstir --- fs/crypto/crypto.c | 25 fs/crypto/fscrypt_private.h| 5 ++- fs/crypto/keyinfo.c| 87

Re: Geode LX AES/RNG driver triggers warning

PrasannaKumar, > On 06.01.2017, at 10:40, PrasannaKumar Muralidharan > wrote: > >>> I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to >>> managed API") which seems to introduce this. It looks to me like some issue >>> between devres, the Geode

Re: Geode LX AES/RNG driver triggers warning

PrasannaKumar, > On 06.01.2017, at 10:40, PrasannaKumar Muralidharan > wrote: > >>> I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to >>> managed API") which seems to introduce this. It looks to me like some issue >>> between devres, the Geode hwrng and AES drivers which

Re: [PATCH] clockevents/drivers/cs5535: Un-break driver with 'set-state' interface

Hi Daniel, > On 04.01.2017, at 15:19, Daniel Lezcano wrote: > > On 02/01/2017 10:34, Viresh Kumar wrote: > > [ ... ] > >>> --- a/drivers/clocksource/cs5535-clockevt.c >>> +++ b/drivers/clocksource/cs5535-clockevt.c >>> @@ -117,7 +117,8 @@ static irqreturn_t

Re: [PATCH] clockevents/drivers/cs5535: Un-break driver with 'set-state' interface

Hi Daniel, > On 04.01.2017, at 15:19, Daniel Lezcano wrote: > > On 02/01/2017 10:34, Viresh Kumar wrote: > > [ ... ] > >>> --- a/drivers/clocksource/cs5535-clockevt.c >>> +++ b/drivers/clocksource/cs5535-clockevt.c >>> @@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)

Geode LX AES/RNG driver triggers warning

Hi! I recently tested kernel v4.9 on my AMD Geode platform and noticed that its AES hardware driver triggers this warning on initialization: [1.265708] [ cut here ] [1.267932] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 driver_probe_device+0x5d/0x1ad [

Geode LX AES/RNG driver triggers warning

Hi! I recently tested kernel v4.9 on my AMD Geode platform and noticed that its AES hardware driver triggers this warning on initialization: [1.265708] [ cut here ] [1.267932] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 driver_probe_device+0x5d/0x1ad [

[PATCH] clockevents/drivers/cs5535: Un-break driver with 'set-state' interface

ueued.net> Cc: Viresh Kumar <viresh.ku...@linaro.org> Signed-off-by: David Gstir <da...@sigma-star.at> --- drivers/clocksource/cs5535-clockevt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clocksource/cs5535-clockevt.c b/drivers/clocksource/cs5535-c

[PATCH] clockevents/drivers/cs5535: Un-break driver with 'set-state' interface

ar Signed-off-by: David Gstir --- drivers/clocksource/cs5535-clockevt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clocksource/cs5535-clockevt.c b/drivers/clocksource/cs5535-clockevt.c index 9a7e37cf56b0..649e0cd90805 100644 --- a/drivers/clocksource/cs5535-clocke

Re: [PATCH v2] fscrypt: Factor out bio specific functions

> Suggested-by: Christoph Hellwig <h...@infradead.org> > Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto") > Signed-off-by: Richard Weinberger <rich...@nod.at> > --- > Changes since v1: > - Moved fscrypt_zeroout_range() also to bio.c Looks good to me. Reviewed-by: David Gstir <da...@sigma-star.at> - David

Re: [PATCH v2] fscrypt: Factor out bio specific functions

n for fscrypto") > Signed-off-by: Richard Weinberger > --- > Changes since v1: > - Moved fscrypt_zeroout_range() also to bio.c Looks good to me. Reviewed-by: David Gstir - David

Re: [PATCH] fscrypt: Factor out bio specific functions

Hi, > On 16.12.2016, at 11:50, Richard Weinberger wrote: > > That way we can get rid of the direct dependency on CONFIG_BLOCK. > > Reported-by: Arnd Bergmann > Reported-by: Randy Dunlap > Suggested-by: Christoph Hellwig

Re: [PATCH] fscrypt: Factor out bio specific functions

Hi, > On 16.12.2016, at 11:50, Richard Weinberger wrote: > > That way we can get rid of the direct dependency on CONFIG_BLOCK. > > Reported-by: Arnd Bergmann > Reported-by: Randy Dunlap > Suggested-by: Christoph Hellwig > Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto") >

Re: [PATCH 2/2] ubifs: Use fscrypt ioctl() helpers

licy > +#define fscrypt_ioctl_get_policy fscrypt_notsupp_ioctl_get_policy > #define fscrypt_has_permitted_context fscrypt_notsupp_has_permitted_context > #define fscrypt_inherit_context fscrypt_notsupp_inherit_context > #define fscrypt_get_encryption_info fscrypt_notsupp_get_encryption_info > -- > 2.10.2 Looks good to me. Reviewed-by: David Gstir <da...@sigma-star.at> - David

Re: [PATCH 2/2] ubifs: Use fscrypt ioctl() helpers

icy fscrypt_notsupp_ioctl_get_policy > #define fscrypt_has_permitted_context fscrypt_notsupp_has_permitted_context > #define fscrypt_inherit_context fscrypt_notsupp_inherit_context > #define fscrypt_get_encryption_info fscrypt_notsupp_get_encryption_info > -- > 2.10.2 Looks good to me. Reviewed-by: David Gstir - David

[PATCH v2 5/6] fscrypt: Delay bounce page pool allocation until needed

Since fscrypt users can now indicated if fscrypt_encrypt_page() should use a bounce page, we can delay the bounce page pool initialization util it is really needed. That is until fscrypt_operations has no FS_CFLG_OWN_PAGES flag set. Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/

[PATCH v2 2/6] fscrypt: Never allocate fscrypt_ctx on in-place encryption

In case of in-place encryption fscrypt_ctx was allocated but never released. Since we don't need it for in-place encryption, we skip allocating it. Fixes: 1c7dcf69eea3 ("fscrypt: Add in-place encryption mode") Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/cryp

[PATCH v2 5/6] fscrypt: Delay bounce page pool allocation until needed

Since fscrypt users can now indicated if fscrypt_encrypt_page() should use a bounce page, we can delay the bounce page pool initialization util it is really needed. That is until fscrypt_operations has no FS_CFLG_OWN_PAGES flag set. Signed-off-by: David Gstir --- fs/crypto/crypto.c | 9

[PATCH v2 2/6] fscrypt: Never allocate fscrypt_ctx on in-place encryption

In case of in-place encryption fscrypt_ctx was allocated but never released. Since we don't need it for in-place encryption, we skip allocating it. Fixes: 1c7dcf69eea3 ("fscrypt: Add in-place encryption mode") Signed-off-by: David Gstir --- fs/crypto/cry

[PATCH v2 4/6] fscrypt: Cleanup page locking requirements for fscrypt_{decrypt,encrypt}_page()

Rename the FS_CFLG_INPLACE_ENCRYPTION flag to FS_CFLG_OWN_PAGES which, when set, indicates that the fs uses pages under its own control as opposed to writeback pages which require locking and a bounce buffer for encryption. Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/cr

[PATCH v2 0/6] UBIFS related fscrypt updates

it fscrypt David Gstir (6): fscrypt: Use correct index in decrypt path. fscrypt: Never allocate fscrypt_ctx on in-place encryption fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page() fscrypt: Cleanup page locking requirements for fscrypt_{decrypt,encrypt}_page() fscrypt: Delay bounce

[PATCH v2 3/6] fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page()

- Improve documentation - Add BUG_ON(len == 0) to avoid accidental switch of offs and len parameters - Improve variable names for readability Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/crypto.c | 93 +++- include

[PATCH v2 0/6] UBIFS related fscrypt updates

it fscrypt David Gstir (6): fscrypt: Use correct index in decrypt path. fscrypt: Never allocate fscrypt_ctx on in-place encryption fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page() fscrypt: Cleanup page locking requirements for fscrypt_{decrypt,encrypt}_page() fscrypt: Delay bounce

[PATCH v2 3/6] fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page()

- Improve documentation - Add BUG_ON(len == 0) to avoid accidental switch of offs and len parameters - Improve variable names for readability Signed-off-by: David Gstir --- fs/crypto/crypto.c | 93 +++- include/linux/fscrypto.h | 8 ++--- 2

[PATCH v2 4/6] fscrypt: Cleanup page locking requirements for fscrypt_{decrypt,encrypt}_page()

Rename the FS_CFLG_INPLACE_ENCRYPTION flag to FS_CFLG_OWN_PAGES which, when set, indicates that the fs uses pages under its own control as opposed to writeback pages which require locking and a bounce buffer for encryption. Signed-off-by: David Gstir --- fs/crypto/crypto.c | 11

[PATCH v2 1/6] fscrypt: Use correct index in decrypt path.

Actually use the fs-provided index instead of always using page->index which is only set for page-cache pages. Fixes: 9c4bb8a3a9b4 ("fscrypt: Let fs select encryption index/tweak") Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/crypto.c | 2 +- 1 file changed

[PATCH v2 6/6] fscrypt: Rename FS_WRITE_PATH_FL to FS_CTX_HAS_BOUNCE_BUFFER_FL

... to better explain its purpose after introducing in-place encryption without bounce buffer. Signed-off-by: David Gstir <da...@sigma-star.at> --- fs/crypto/crypto.c | 6 +++--- include/linux/fscrypto.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/

[PATCH v2 1/6] fscrypt: Use correct index in decrypt path.

Actually use the fs-provided index instead of always using page->index which is only set for page-cache pages. Fixes: 9c4bb8a3a9b4 ("fscrypt: Let fs select encryption index/tweak") Signed-off-by: David Gstir --- fs/crypto/crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 dele

[PATCH v2 6/6] fscrypt: Rename FS_WRITE_PATH_FL to FS_CTX_HAS_BOUNCE_BUFFER_FL

... to better explain its purpose after introducing in-place encryption without bounce buffer. Signed-off-by: David Gstir --- fs/crypto/crypto.c | 6 +++--- include/linux/fscrypto.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto

Re: [PATCH 3/6] fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page()

> On 02.12.2016, at 09:19, Eric Biggers wrote: > > On Thu, Dec 01, 2016 at 11:14:55PM +0100, Richard Weinberger wrote: >> + * @lblk_num: Logical block number. This must be unique for multiple >> + * calls with same page. > > Must be unique for all calls with

Re: [PATCH 3/6] fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page()

> On 02.12.2016, at 09:19, Eric Biggers wrote: > > On Thu, Dec 01, 2016 at 11:14:55PM +0100, Richard Weinberger wrote: >> + * @lblk_num: Logical block number. This must be unique for multiple >> + * calls with same page. > > Must be unique for all calls with the same *inode*,

Re: [PATCH 01/29] fscrypt: Add in-place encryption mode

Eric, > On 15.11.2016, at 19:14, Eric Biggers <ebigg...@google.com> wrote: > > Hi, > > On Sun, Nov 13, 2016 at 10:20:44PM +0100, Richard Weinberger wrote: >> From: David Gstir <da...@sigma-star.at> >> >> ext4 and f2fs require a bounce page when encr

Re: [PATCH 01/29] fscrypt: Add in-place encryption mode

Eric, > On 15.11.2016, at 19:14, Eric Biggers wrote: > > Hi, > > On Sun, Nov 13, 2016 at 10:20:44PM +0100, Richard Weinberger wrote: >> From: David Gstir >> >> ext4 and f2fs require a bounce page when encrypting pages. However, not >> al

Re: [PATCH 02/29] fscrypt: Allow fscrypt_decrypt_page() to function with non-writeback pages

Eric, > On 15.11.2016, at 19:19, Eric Biggers wrote: > > On Sun, Nov 13, 2016 at 10:20:45PM +0100, Richard Weinberger wrote: >> /** >> * f2crypt_decrypt_page() - Decrypts a page in-place >> - * @page: The page to decrypt. Must be locked. >> + * @inode: The encrypted inode

Re: [PATCH 02/29] fscrypt: Allow fscrypt_decrypt_page() to function with non-writeback pages

Eric, > On 15.11.2016, at 19:19, Eric Biggers wrote: > > On Sun, Nov 13, 2016 at 10:20:45PM +0100, Richard Weinberger wrote: >> /** >> * f2crypt_decrypt_page() - Decrypts a page in-place >> - * @page: The page to decrypt. Must be locked. >> + * @inode: The encrypted inode to decrypt. >> + *

Re: [PATCH] UBIFS: Fix possible memory leak in ubifs_readdir()

private_data = NULL; > /* 2 is a special value indicating that there are no more direntries */ > ctx->pos = 2; > return 0; > -- > 2.5.0 Looks good to me. Reviewed-by: David Gstir Thanks, David-- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] UBIFS: Fix possible memory leak in ubifs_readdir()

> - kfree(file->private_data); > - file->private_data = NULL; > /* 2 is a special value indicating that there are no more direntries */ > ctx->pos = 2; > return 0; > -- > 2.5.0 Looks good to me. Reviewed-by: David Gstir <da...@sigma-star.at> Thanks,

Re: [PATCH] UBI: Validate data_size

c int validate_vid_hdr(const struct ubi_device *ubi, > goto bad; > } > > + if (data_size > ubi->leb_size) { > + ubi_err(ubi, "bad data_size"); > + goto bad; > + } > + Nice catch! Reviewed-by: David G

Re: [PATCH] UBI: Validate data_size

/ubi/io.c > @@ -926,6 +926,11 @@ static int validate_vid_hdr(const struct ubi_device *ubi, > goto bad; > } > > + if (data_size > ubi->leb_size) { > + ubi_err(ubi, "bad data_size"); > + goto bad; > + } &g

Re: DMAR faults from unrelated device when vfio is used

Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson: > Can you clarify what you mean by assign? Are you actually assigning the > root ports to the qemu guest (1c.0 & 1c.6)? vfio will require they be > owned by vfio-pci to make use of 3:00.0, but assigning them to the guest > is not

Re: DMAR faults from unrelated device when vfio is used

Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson: Can you clarify what you mean by assign? Are you actually assigning the root ports to the qemu guest (1c.0 1c.6)? vfio will require they be owned by vfio-pci to make use of 3:00.0, but assigning them to the guest is not

DMAR faults from unrelated device when vfio is used

Hi! I get the following error messages over and over again when using vfio in qemu-kvm: [ 1692.021403] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr 1a45aa9000 [ 1692.021403] DMAR:[fault reason 12] non-zero reserved fields in PTE [ 1692.021416] dmar: DRHD: handling fault status

DMAR faults from unrelated device when vfio is used

Hi! I get the following error messages over and over again when using vfio in qemu-kvm: [ 1692.021403] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr 1a45aa9000 [ 1692.021403] DMAR:[fault reason 12] non-zero reserved fields in PTE [ 1692.021416] dmar: DRHD: handling fault status