Re: geli AES-XTS provider attachment broken after r285336 (was: svn commit: r285336 - in head/sys: netipsec opencrypto)

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Sat, 11 Jul 2015 21:27:29 +0200
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. 

Received on Sat Jul 11 2015 - 17:27:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC