dm-crypt: plain64 IV support for -stable?

dm-crypt: plain64 IV support for -stable?

[Henrique de Moraes Holschuh]

Would it be possible to add commit 61afef614b013ee1b767cdd10325acae1db1f4d2
"dm crypt: add plain64 iv" to -stable?

Without it, users of LTS kernels like 2.6.32 are missing important
functionality (as in: might not be able to mount some LUKS volumes
created on newer kernels).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: dm-crypt: plain64 IV support for -stable?

[Alasdair G Kergon]

On Tue, Oct 12, 2010 at 10:25:11AM -0300, Henrique de Moraes Holschuh wrote:
> Would it be possible to add commit 61afef614b013ee1b767cdd10325acae1db1f4d2
> "dm crypt: add plain64 iv" to -stable?
 
I've no objections - it's a simple and safe patch - but technically it's
an enhancement: it's up to the stable maintainers to decide.

Alasdair

Re: [stable] dm-crypt: plain64 IV support for -stable?

[Greg KH]

On Tue, Oct 12, 2010 at 02:32:26PM +0100, Alasdair G Kergon wrote:
> On Tue, Oct 12, 2010 at 10:25:11AM -0300, Henrique de Moraes Holschuh wrote:
> > Would it be possible to add commit 61afef614b013ee1b767cdd10325acae1db1f4d2
> > "dm crypt: add plain64 iv" to -stable?
>  
> I've no objections - it's a simple and safe patch - but technically it's
> an enhancement: it's up to the stable maintainers to decide.

Yeah, I don't think it falls under the -stable rules, so sorry, I will
not take it.

thanks,

greg k-h

Re: dm-crypt: plain64 IV support for -stable?

[Milan Broz]

On 10/12/2010 03:25 PM, Henrique de Moraes Holschuh wrote:
> Would it be possible to add commit 61afef614b013ee1b767cdd10325acae1db1f4d2
> "dm crypt: add plain64 iv" to -stable?
> 
> Without it, users of LTS kernels like 2.6.32 are missing important
> functionality (as in: might not be able to mount some LUKS volumes
> created on newer kernels).
 
Yes, that should not cause any problems, it should be plain cherry-pick...

(plain64 is just 64bit version of "plain" IV generator, so for <2TB devices are these equivalents)

Milan

Re: [stable] dm-crypt: plain64 IV support for -stable?

[Greg KH]

On Tue, Oct 12, 2010 at 10:25:11AM -0300, Henrique de Moraes Holschuh wrote:
> Would it be possible to add commit 61afef614b013ee1b767cdd10325acae1db1f4d2
> "dm crypt: add plain64 iv" to -stable?

Which -stable tree?  .27, .32, .35, or any/all of them?  Please be more
specific when asking for this in the future.

> Without it, users of LTS kernels like 2.6.32 are missing important
> functionality (as in: might not be able to mount some LUKS volumes
> created on newer kernels).

Also note that this patch really looks like a "new feature", not a
bugfix or anything that matches up with what
Documentation/stable_kernel_rules.txt defines.  So I don't think that it
really is something to add to a stable kernel.

thanks,

greg k-h

Re: [stable] dm-crypt: plain64 IV support for -stable?

[Henrique de Moraes Holschuh]

On Tue, 12 Oct 2010, Greg KH wrote:
> Which -stable tree?  .27, .32, .35, or any/all of them?  Please be more
> specific when asking for this in the future.

Just 2.6.32.  It is already in 2.6.35, and 2.6.27 is too old for it to
matter.

> > Without it, users of LTS kernels like 2.6.32 are missing important
> > functionality (as in: might not be able to mount some LUKS volumes
> > created on newer kernels).
> 
> Also note that this patch really looks like a "new feature", not a
> bugfix or anything that matches up with what
> Documentation/stable_kernel_rules.txt defines.  So I don't think that it
> really is something to add to a stable kernel.

Using "plain" for IVs on block devices with more than 2^32 blocks will cause
the same IV to be used twice due to roll-over.  This is not a good thing,
although it might be not bad enough to matter much (or it could be a
terrible problem.  Someone who groks crypto for real would have to answer
that).

One cannot fix "plain", or data after the roll-over point becomes unreadable
on any already-existing devices.  Thus, a new IV was added with the fix,
"plain64".

Distros will probably need to backport this, as userspace and docs are
already starting to tell users to use aes-xts-plain64 and not aes-xts-plain.
They will use them in their portable HDs, and then will not be able to read
them back in various stable distros.   Might as well do it upstream where it
will benefit everybody...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [stable] dm-crypt: plain64 IV support for -stable?

[Greg KH]

On Tue, Oct 12, 2010 at 04:04:38PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 12 Oct 2010, Greg KH wrote:
> > Which -stable tree?  .27, .32, .35, or any/all of them?  Please be more
> > specific when asking for this in the future.
> 
> Just 2.6.32.  It is already in 2.6.35, and 2.6.27 is too old for it to
> matter.

Ok.

> > > Without it, users of LTS kernels like 2.6.32 are missing important
> > > functionality (as in: might not be able to mount some LUKS volumes
> > > created on newer kernels).
> > 
> > Also note that this patch really looks like a "new feature", not a
> > bugfix or anything that matches up with what
> > Documentation/stable_kernel_rules.txt defines.  So I don't think that it
> > really is something to add to a stable kernel.
> 
> Using "plain" for IVs on block devices with more than 2^32 blocks will cause
> the same IV to be used twice due to roll-over.  This is not a good thing,
> although it might be not bad enough to matter much (or it could be a
> terrible problem.  Someone who groks crypto for real would have to answer
> that).
> 
> One cannot fix "plain", or data after the roll-over point becomes unreadable
> on any already-existing devices.  Thus, a new IV was added with the fix,
> "plain64".
> 
> Distros will probably need to backport this, as userspace and docs are
> already starting to tell users to use aes-xts-plain64 and not aes-xts-plain.
> They will use them in their portable HDs, and then will not be able to read
> them back in various stable distros.   Might as well do it upstream where it
> will benefit everybody...

If they create them in a newer kernel, and then try to use an older
kernel, how would they normally expect them to work?

Yes, I understand your point, but please note that this is a new feature
being added, which is not what the stable tree is for at all.  If it's a
real issue, let the distros know about it, but even then, I doubt they
will care as they don't support such a "use on new, then on old" type
model either.

thanks,

greg k-h