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 type

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 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 alr

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 de

[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 auth

[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 needed in this patch (appl

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

: 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 to the original crypto r

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 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 implemen

[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 --- 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 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 >> are s

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

: 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 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 --- 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

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 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

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

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:40P

[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 hwrng and AES drivers which b

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 [1.2

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

s Salomon Cc: Viresh Kumar 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/

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 > Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto") > Signed-off-

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

pt_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 - 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 --- 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/crypt

[PATCH v2 0/6] UBIFS related fscrypt updates

xt4.git 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 b

[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 --- 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 the same *inode*, excep

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 >> all filesyst

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. >> + * @pa

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] 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 Gstir

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

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 reg