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