geli AES-XTS provider attachment broken after r285336 (was: svn commit: r285336 - in head/sys: netipsec opencrypto)
O. Hartmann
ohartman at zedat.fu-berlin.de
Sat Jul 11 19:27:45 UTC 2015
Am Sat, 11 Jul 2015 19:04:07 +0200
Fabian Keil <freebsd-listen at fabiankeil.de> schrieb:
> "Matthew D. Fuller" <fullermd at over-yonder.net> wrote:
>
> > On Thu, Jul 09, 2015 at 06:16:36PM +0000 I heard the voice of
> > George V. Neville-Neil, and lo! it spake thus:
> > > New Revision: 285336
> > > URL: https://svnweb.freebsd.org/changeset/base/285336
> > >
> > > Log:
> > > Add support for AES modes to IPSec. These modes work both in software only
> > > mode and with hardware support on systems that have AESNI instructions.
> >
> > With (apparently) this change, I can trigger a panic at will by
> > running
> >
> > % geli onetime -e AES-XTS -d /dev/ada0s1
>
> Thanks for the heads-up.
>
> As it wasn't obvious to me: the commit broke attachment
> of AES-XTS providers in general.
>
> Reverting it lets my test system boot again.
>
> Fabian
Running CURRENT on several Intel platforms, using swap.eli on all systems is usual to my
setups. On modern hardware, say >= Intel i7 architectures (with or without AES-NI), I
didn't recognize a panic at all but in one case a core i3 starts swapping dies
immediately. Another box, a dual core XEON Core2 Duo based architecture without AES-NI
fails booting immediately after I see the mounting and initialising of swap.eli. Maybe
this observation is of use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20150711/6a7d4c5c/attachment.bin>
More information about the freebsd-current
mailing list