Re: CFR: AES-GCM and OpenCrypto work review

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Fri, 14 Nov 2014 11:35:03 +0200
On Fri, Nov 14, 2014 at 03:52:39AM +0300, Andrey V. Elsukov wrote:
> On 08.11.2014 07:23, John-Mark Gurney wrote:
> > Hello,
> > 
> > Over the last few months, I've been working on a project to add support
> > for AES-GCM and AES-CTR modes to our OpenCrypto framework.  The work is
> > sponsored by The FreeBSD Foundation and Netgate.
> > 
> > I plan on committing these patches early next week.  If you need more
> > time for review, please email me privately and I will make delay.
> > 
> > The code has already been reviewed by Watson Ladd (the software crypto
> > implementations) and Trevor Perrin (the aesni module part) and I have
> > integrated these changes into the patch.
> > 
> > There are two patches, one is the changes for OpenCrypto and the test
> > framework.  The other is the data files used by the test framework.
> > The data is from NIST's CAVP program, and is about 20MB worth of test
> > vectors.  (I just realized, should we look at compressing these on
> > disk?)
> > 
> > Main patch (192KB):
> > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch
> > 
> > Data files (~20MB):
> > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch
> > 
> > A list of notable changes in the patch:
> > - Replacing crypto(4) w/ NetBSD's version + updates
> > - Lots of man page updates, including CIOCFINDDEV and crypto(7) which
> >   adds specifics about restrictions on the modes.
> > - Allow sane useage of both _HARDWARE and _SOFTWARE flags.
> > - Add a timing safe bcmp for MAC comparision.
> > - Add a software implementation of GCM that uses a four bit lookup
> >   table with parallelization.  This algorithm is possibly vulnerable to
> >   timing attacks, but best known mitigation methods are used.  Using
> >   a timing safe version is many times slower.
> > - Added a CRYPTDEB macro that defaults to off.
> > - Bring in some of OpenBSD's improvements to the OpenCrypto framework.
> > - If an mbuf passed to the aesni module is only one segment, don't do
> >   a copy.  This needs to be improved to support segmented buffers.
> > - Remove the CRYPTO_F_REL flag.  It was meaningless.  It was used but
> >   did not change any behavior.
> > - Add function crypto_mbuftoiov to convert an mbuf to an iov.  This
> >   also converts the software crypto to only use iov's even for a simple
> >   linear buffer, and so simplifies the processing.
> > - Add a dtrace probe for errors from the ioctl.
> > - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing)
> >   of AES-GCM and future AEAD modes.
> > 
> > Future improvements:
> > - Support IV's longer than 12 bytes for GCM.
> > - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented
> >   inputs don't have to be copied.
> > 
> > I know there are more fixes and future improvements, but can't think of
> > them now.
> 
> I tried your patch with my IPv4 forwarding test. When aesni module is
> loaded and aes-cbc is used I see growing of `invalid outbound packets`
> counter in `netstat -sp ipsec` output. And no packets are forwarded.
> Also while testing I got a panic in aesni_encrypt_cbc().
> 
> atal trap 9: general protection fault while in kernel mode
> cpuid = 4; apic id = 04
> instruction pointer	= 0x20:0xffffffff80d05c43
> stack pointer	        = 0x28:0xfffffe00003f7e70
> frame pointer	        = 0x28:0xfffffe00003f7eb0
> code segment		= base 0x0, limit 0xfffff, type 0x1b
> 			= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags	= interrupt enabled, resume, IOPL = 0
> current process		= 12 (irq286: ix0:que 4)
> 
> The backtrace:
> #0  doadump (textdump=276160512) at pcpu.h:219
> #1  0xffffffff80355525 in db_fncall (dummy1=<value optimized out>,
> dummy2=<value optimized out>, dummy3=<value optimized out>,
> dummy4=<value optimized out>)
>     at /usr/src/sys/ddb/db_command.c:568
> #2  0xffffffff8035520d in db_command (cmd_table=0x0) at
> /usr/src/sys/ddb/db_command.c:440
> #3  0xffffffff80354f84 in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:493
> #4  0xffffffff80357980 in db_trap (type=<value optimized out>, code=0)
> at /usr/src/sys/ddb/db_main.c:251
> #5  0xffffffff8095c641 in kdb_trap (type=9, code=0, tf=<value optimized
> out>) at /usr/src/sys/kern/subr_kdb.c:654
> #6  0xffffffff80d1edcc in trap_fatal (frame=0xfffffe00003f7dc0,
> eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861
> #7  0xffffffff80d1ea6e in trap (frame=<value optimized out>) at
> /usr/src/sys/amd64/amd64/trap.c:201
> #8  0xffffffff80d04092 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:231
> #9  0xffffffff80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85
> #10 0xffffffff80d1e7ae in trap (frame=<value optimized out>) at
> /usr/src/sys/amd64/amd64/trap.c:432
> #11 0xffffffff80d04092 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:231
> #12 0xffffffff8202f96e in aesni_encrypt_cbc (rounds=10,
> key_schedule=0xfffff8005603d400, len=3, from=0xfffff8013b0de65a "E",
> to=0xfffff8013b0de65a "E",
>     iv=0xfffff8005603d6d0 "???#??????8???:n???\r??????\f?????????\v") at
> /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63
> #13 0xffffffff820318d0 in aesni_process (dev=<value optimized out>,
> crp=0xfffff80109f7bc08, hint=<value optimized out>)
>     at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535
> #14 0xffffffff80b170e9 in crypto_dispatch (crp=0xfffff80109f7bc08) at
> /usr/src/sys/opencrypto/crypto.c:807
> #15 0xffffffff80b076d6 in esp_output (m=<value optimized out>,
> isr=<value optimized out>, mp=0x3, skip=<value optimized out>,
> protoff=<value optimized out>)
>     at /usr/src/sys/netipsec/xform_esp.c:905
> #16 0xffffffff80af7457 in ipsec4_process_packet (m=0xfffff8013b0de600,
> isr=<value optimized out>, flags=<value optimized out>,
> tunalready=<value optimized out>)
>     at /usr/src/sys/netipsec/ipsec_output.c:594
> #17 0xffffffff80a4a0db in ip_ipsec_output (m=<value optimized out>,
> inp=<value optimized out>, flags=0xfffffe00003f8494,
> error=0xfffffe00003f8490)
>     at /usr/src/sys/netinet/ip_ipsec.c:332
> #18 0xffffffff80a4b6b9 in ip_output (m=0xfffff8013b0de600, opt=<value
> optimized out>, flags=1, imo=<value optimized out>, inp=0x0)
>     at /usr/src/sys/netinet/ip_output.c:476
> #19 0xffffffff80a485eb in ip_forward (m=0xfffff8013b0de600, srcrt=<value
> optimized out>) at /usr/src/sys/netinet/ip_input.c:1571
> #20 0xffffffff80a4825e in ip_input (m=0xfffff8013b0de600) at
> /usr/src/sys/netinet/ip_input.c:754
> #21 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized
> out>, source=<value optimized out>, m=0xfffff8013b0de65a) at
> /usr/src/sys/net/netisr.c:968
> #22 0xffffffff809dfb53 in ether_demux (ifp=<value optimized out>,
> m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766
> #23 0xffffffff809e0758 in ether_nh_input (m=<value optimized out>) at
> /usr/src/sys/net/if_ethersubr.c:573
> #24 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized
> out>, source=<value optimized out>, m=0xfffff8013b0de65a) at
> /usr/src/sys/net/netisr.c:968
> #25 0xffffffff809dfdb6 in ether_input (ifp=<value optimized out>, m=0x0)
> at /usr/src/sys/net/if_ethersubr.c:674
> #26 0xffffffff809e55e5 in vlan_input (ifp=0xfffff8000ef3e800, m=<value
> optimized out>) at /usr/src/sys/net/if_vlan.c:1239
> #27 0xffffffff809dfac4 in ether_demux (ifp=0xfffff8000ef3e800,
> m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717
> #28 0xffffffff809e0758 in ether_nh_input (m=<value optimized out>) at
> /usr/src/sys/net/if_ethersubr.c:573
> #29 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized
> out>, source=<value optimized out>, m=0xfffff8013b0de65a) at
> /usr/src/sys/net/netisr.c:968
> #30 0xffffffff809dfdb6 in ether_input (ifp=<value optimized out>, m=0x0)
> at /usr/src/sys/net/if_ethersubr.c:674
> #31 0xffffffff8059f303 in ixgbe_rxeof (que=0xfffff8000ef5c1a0) at
> /usr/src/sys/dev/ixgbe/ixgbe.c:4530
> 
Is the backtrace above full ?  ixgbe_rxeof() cannot be the top frame,
there must be a caller above it.  Does this happen in interrupt thread ?

Out of curiosity, can you do
	p *td
and
	p *(td->td_pcb)
for the paniced thread ? 
Received on Fri Nov 14 2014 - 08:35:14 UTC

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