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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101012190438.GB16717@khazad-dum.debian.net>
Date:	Tue, 12 Oct 2010 16:04:38 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, stable@...nel.org,
	Alasdair G Kergon <agk@...hat.com>,
	Milan Broz <mbroz@...hat.com>
Subject: Re: [stable] dm-crypt: plain64 IV support for -stable?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/