| Message ID | 20240730115838.3507302-1-quic_mdalam@quicinc.com |
|---|---|
| Headers | show |
| Series | Add Additional algo mode for inline encryption | expand |
On 7/30/24 1:58 PM, Md Sadre Alam wrote: > Set cc->iv_size to 4 bytes instead of 8 bytes, since > this cc->iv_size is passing as data unit bytes to > blk_crypto_init_key(). Since CQHCI driver having > limitation for data unit bytes to 32-bit only. In dm-crypt, plain64 IV is defined as "little-endian 64bit IV" and was introduced to fix security problem when 32bit "plain" IV overflows and IV is reused. In that case you can move ciphertext sector between places with the same IV (but different offsets) and these will be still correctly decrypted. If I understand it correctly, this reintroduces the same problem here. If you have 32bit only, just use "plain" and do not support plain64 here. (In general, I do not understand why you are sending patches for dm-crypt code that is clearly not upstream. I hope this code will never be accepted.) Milan > > Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com> > --- > drivers/md/dm-crypt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index 37add222b169..c0257d961968 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -2490,7 +2490,7 @@ static int crypt_select_inline_crypt_mode(struct dm_target *ti, char *cipher, > } > > if (ivmode == NULL || (strcmp(ivmode, "plain64") == 0)) { > - cc->iv_size = 8; > + cc->iv_size = 4; > } else { > ti->error = "Invalid IV mode for inline_crypt"; > return -EINVAL;
On Tue, 30 Jul 2024, Md Sadre Alam wrote: > This series of patches add additional modes for inline encryption > > This series of patches depends on [1] Add inline encryption support for dm-crypt > > [1]: https://lore.kernel.org/all/b45d3b40-2587-04dc-9601-a9251dacf806@opensource.wdc.com/T/#ma01f08a941107217c93680fa25e96e8d406df790 > > These patches tested on IPQ9574 with eMMC ICE for raw partition > encryption/decryption. Hi I discussed it with Milan Broz <gmazyland@gmail.com> and we concluded that there is no need to bloat dm-crypt with this logic. We believe that you should create your own target (like "dm-inline-crypt"), it would work like a linear target and it will attach encryption requests to the bios that it processes. Mikulas
This is not related to emulation, but was. upstream linux development Kamal On Wed, Jul 31, 2024 at 8:50 AM Mikulas Patocka <mpatocka@redhat.com> wrote: > > > > On Tue, 30 Jul 2024, Md Sadre Alam wrote: > > > This series of patches add additional modes for inline encryption > > > > This series of patches depends on [1] Add inline encryption support for dm-crypt > > > > [1]: https://lore.kernel.org/all/b45d3b40-2587-04dc-9601-a9251dacf806@opensource.wdc.com/T/#ma01f08a941107217c93680fa25e96e8d406df790 > > > > These patches tested on IPQ9574 with eMMC ICE for raw partition > > encryption/decryption. > > Hi > > I discussed it with Milan Broz <gmazyland@gmail.com> and we concluded that > there is no need to bloat dm-crypt with this logic. > > We believe that you should create your own target (like > "dm-inline-crypt"), it would work like a linear target and it will attach > encryption requests to the bios that it processes. > > Mikulas > >
On 7/31/2024 6:11 PM, Milan Broz wrote: > On 7/30/24 1:58 PM, Md Sadre Alam wrote: >> Set cc->iv_size to 4 bytes instead of 8 bytes, since >> this cc->iv_size is passing as data unit bytes to >> blk_crypto_init_key(). Since CQHCI driver having >> limitation for data unit bytes to 32-bit only. > > In dm-crypt, plain64 IV is defined as "little-endian 64bit IV" > and was introduced to fix security problem when 32bit "plain" IV > overflows and IV is reused. > > In that case you can move ciphertext sector between places with > the same IV (but different offsets) and these will be still > correctly decrypted. > > If I understand it correctly, this reintroduces the same problem here. > If you have 32bit only, just use "plain" and do not support plain64 here. > > (In general, I do not understand why you are sending patches > for dm-crypt code that is clearly not upstream. > I hope this code will never be accepted.) Thanks for reviewing. As Mikulas suggested for new target driver for "inline-crypt". Will create new target driver and post it. > > Milan > >> >> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com> >> --- >> drivers/md/dm-crypt.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c >> index 37add222b169..c0257d961968 100644 >> --- a/drivers/md/dm-crypt.c >> +++ b/drivers/md/dm-crypt.c >> @@ -2490,7 +2490,7 @@ static int crypt_select_inline_crypt_mode(struct dm_target *ti, char *cipher, >> } >> if (ivmode == NULL || (strcmp(ivmode, "plain64") == 0)) { >> - cc->iv_size = 8; >> + cc->iv_size = 4; >> } else { >> ti->error = "Invalid IV mode for inline_crypt"; >> return -EINVAL; >
On 7/31/2024 6:18 PM, Mikulas Patocka wrote: > > > On Tue, 30 Jul 2024, Md Sadre Alam wrote: > >> This series of patches add additional modes for inline encryption >> >> This series of patches depends on [1] Add inline encryption support for dm-crypt >> >> [1]: https://lore.kernel.org/all/b45d3b40-2587-04dc-9601-a9251dacf806@opensource.wdc.com/T/#ma01f08a941107217c93680fa25e96e8d406df790 >> >> These patches tested on IPQ9574 with eMMC ICE for raw partition >> encryption/decryption. > > Hi > > I discussed it with Milan Broz <gmazyland@gmail.com> and we concluded that > there is no need to bloat dm-crypt with this logic. > > We believe that you should create your own target (like > "dm-inline-crypt"), it would work like a linear target and it will attach > encryption requests to the bios that it processes. > Thanks for reviewing. Will create new target driver "dm-inline-crypt". > Mikulas >