From: Greg KH <greg@kroah.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
Alasdair G Kergon <agk@redhat.com>, Milan Broz <mbroz@redhat.com>
Subject: Re: [stable] dm-crypt: plain64 IV support for -stable?
Date: Tue, 12 Oct 2010 23:40:05 -0700 [thread overview]
Message-ID: <20101013064005.GA4715@kroah.com> (raw)
In-Reply-To: <20101012190438.GB16717@khazad-dum.debian.net>
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
prev parent reply other threads:[~2010-10-13 6:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 13:25 dm-crypt: plain64 IV support for -stable? Henrique de Moraes Holschuh
2010-10-12 13:32 ` Alasdair G Kergon
2010-10-12 15:28 ` [stable] " Greg KH
2010-10-12 13:33 ` Milan Broz
2010-10-12 14:11 ` [stable] " Greg KH
2010-10-12 19:04 ` Henrique de Moraes Holschuh
2010-10-13 6:40 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101013064005.GA4715@kroah.com \
--to=greg@kroah.com \
--cc=agk@redhat.com \
--cc=hmh@hmh.eng.br \
--cc=linux-kernel@vger.kernel.org \
--cc=mbroz@redhat.com \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.