Re: CFR: AES-GCM and OpenCrypto work review
Andrey V. Elsukov wrote this message on Mon, Nov 17, 2014 at 21:34 +0300: > On 16.11.2014 09:15, John-Mark Gurney wrote: > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > with this patch all works as expected. Just so you know, even tunnel mode w/ aesni on a clean HEAD can panic.. I just got a: panic: dummy ctx from the tunnel mode by having two machines ping -f'ing each other... This is a different form of the same panic I posted about earlier w/ the fpu context being reused for different threads... I plan on committing the patch w/o the mtx_lock as including the lock will significantly impact people who use geli... I am working on a fix for this w/ kib that will allow us to not allocate an fpu context and get things a little more stable, but there are other bugs that also need to be addressed before aesni is safe to use w/ IPsec... Thanks for testing! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
On 16.11.2014 09:15, John-Mark Gurney wrote: > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... > > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... > > Let me know how things are w/ this new patch. Hi, with this patch all works as expected. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
Adrian Chadd wrote this message on Sat, Nov 15, 2014 at 22:18 -0800: > ... no attachment? Thanks, I put it on the website since I realized it was 155k and a bit large to attach... it's at: https://www.funkthat.com/~jmg/patches/aes.ipsec.6.patch > On 15 November 2014 22:15, John-Mark Gurney wrote: > > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > >> On 15.11.2014 05:42, John-Mark Gurney wrote: > >> > I just verified that this happens on a clean HEAD @ r274534: > >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > >> > j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > >> > amd64 > >> > > >> > No modifications, nothing, and I got the same panic: > >> > panic: System call sendto returing with kernel FPU ctx leaked > >> > cpuid = 0 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> > 0xfe001de7a800 > >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 > >> > vpanic() at vpanic+0x189/frame 0xfe001de7a930 > >> > kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 > >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 > >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 > >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = > >> > 0x7ffee588, rbp = 0x7ffee5c0 --- > >> > KDB: enter: panic > >> > > >> > So, it's clearly not my patch that is causing the issue... > >> > > >> > Andrey, can you verify that you do not receive the same panic w/o my > >> > patches? > >> > >> I tried 11.0-CURRENT r274549 with and without patches. > >> Without patches all works as expected. System encrypts and forwards > >> traffic with and without aesni module. > >> > >> With patches software rijndaelEncrypt also works. But when I load > >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > >> counter starts grow. And I see messages about wrong source route > >> attempts from random addresses. > > > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > > > Thanks. > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
... no attachment? -adrian On 15 November 2014 22:15, John-Mark Gurney wrote: > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: >> On 15.11.2014 05:42, John-Mark Gurney wrote: >> > I just verified that this happens on a clean HEAD @ r274534: >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 >> > j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC >> > amd64 >> > >> > No modifications, nothing, and I got the same panic: >> > panic: System call sendto returing with kernel FPU ctx leaked >> > cpuid = 0 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> > 0xfe001de7a800 >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 >> > vpanic() at vpanic+0x189/frame 0xfe001de7a930 >> > kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = >> > 0x7ffee588, rbp = 0x7ffee5c0 --- >> > KDB: enter: panic >> > >> > So, it's clearly not my patch that is causing the issue... >> > >> > Andrey, can you verify that you do not receive the same panic w/o my >> > patches? >> >> I tried 11.0-CURRENT r274549 with and without patches. >> Without patches all works as expected. System encrypts and forwards >> traffic with and without aesni module. >> >> With patches software rijndaelEncrypt also works. But when I load >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors >> counter starts grow. And I see messages about wrong source route >> attempts from random addresses. > > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... > > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... > > Let me know how things are w/ this new patch. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > On 15.11.2014 05:42, John-Mark Gurney wrote: > > I just verified that this happens on a clean HEAD @ r274534: > > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > > j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > > amd64 > > > > No modifications, nothing, and I got the same panic: > > panic: System call sendto returing with kernel FPU ctx leaked > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe001de7a800 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 > > vpanic() at vpanic+0x189/frame 0xfe001de7a930 > > kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 > > amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 > > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = > > 0x7ffee588, rbp = 0x7ffee5c0 --- > > KDB: enter: panic > > > > So, it's clearly not my patch that is causing the issue... > > > > Andrey, can you verify that you do not receive the same panic w/o my > > patches? > > I tried 11.0-CURRENT r274549 with and without patches. > Without patches all works as expected. System encrypts and forwards > traffic with and without aesni module. > > With patches software rijndaelEncrypt also works. But when I load > aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > counter starts grow. And I see messages about wrong source route > attempts from random addresses. Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
On 15.11.2014 05:42, John-Mark Gurney wrote: > I just verified that this happens on a clean HEAD @ r274534: > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 > > No modifications, nothing, and I got the same panic: > panic: System call sendto returing with kernel FPU ctx leaked > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 > vpanic() at vpanic+0x189/frame 0xfe001de7a930 > kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 > amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = > 0x7ffee588, rbp = 0x7ffee5c0 --- > KDB: enter: panic > > So, it's clearly not my patch that is causing the issue... > > Andrey, can you verify that you do not receive the same panic w/o my > patches? I tried 11.0-CURRENT r274549 with and without patches. Without patches all works as expected. System encrypts and forwards traffic with and without aesni module. With patches software rijndaelEncrypt also works. But when I load aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors counter starts grow. And I see messages about wrong source route attempts from random addresses. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On 15.11.2014 05:42, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 > -0800: >> Well.. It looks like IPSEC is still broken in head... I can get >> pings to pass, but now on IPv4 transport mode, I can't get syn's >> to be sent out... I see the output packet in the protocol stats, >> but no packets go out the interface... >> >> If you could provide me w/ a simple set of spdadd commands, or the >> dumps from the machine, that'd be good... >> >> Hmm I just ran ping -f so I could generate some traffic, and >> managed to get a: panic: System call sendto returing with kernel >> FPU ctx leaked >> >> I'll look into this... > > I just verified that this happens on a clean HEAD @ r274534: FreeBSD > 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > amd64 > > No modifications, nothing, and I got the same panic: panic: System > call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack > backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfe001de7a8b0 vpanic() at > vpanic+0x189/frame 0xfe001de7a930 kassert_panic() at > kassert_panic+0x139/frame 0xfe001de7a9a0 amd64_syscall() at > amd64_syscall+0x616/frame 0xfe001de7aab0 Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfe001de7aab0 --- syscall (64, FreeBSD > ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffee588, rbp = > 0x7ffee5c0 --- KDB: enter: panic > > So, it's clearly not my patch that is causing the issue... > > Andrey, can you verify that you do not receive the same panic w/o my > patches? 11.0-CURRENT r274469 after 20 minutes and # netstat -sp esp | grep out 424360710 packets out 17823149820 bytes out can't reproduce the panic. I'll update and retry on fresh CURRENT. My ipsec.conf: add 10.9.12.25 10.9.12.15 esp 15701 -E rijndael-cbc "" ; spdadd 192.168.0.0/16 192.168.0.0/16 any -P out ipsec esp/tunnel/10.9.12.25-10.9.12.15/default; aesni.ko is loaded and pmcstat shows that it is in use: PMC: [INSTR_RETIRED_ANY] Samples: 128994 (100.0%) , 7506 unresolved Key: q => exiting... %SAMP IMAGE FUNCTION CALLERS 13.5 kernel cpu_search_highest cpu_search_highest:11.3 sched_idletd:2.2 4.6 kernel __mtx_unlock_flags ip_output:0.8 key_checkrequest:0.6 ip_rtaddr:0.6 key_allocsp:0.5 4.0 kernel __mtx_lock_flags _key_freesp:0.8 rtalloc1_fib:0.8 key_checkrequest:0.6 3.5 kernel cpu_search_lowestcpu_search_lowest:2.6 sched_pickcpu:0.9 3.2 kernel bcopym_copydata:1.7 m_copyback:0.7 3.2 libc.so.7 bsearch 3.0 kernel __rw_rlock rtalloc1_fib 2.5 kernel uma_zalloc_arg malloc:0.8 crypto_getreq:0.6 2.4 kernel uma_zfree_argm_freem:1.0 free:0.7 2.2 kernel bzerouma_zalloc_arg 2.1 kernel _rw_runlock_cookie rtalloc1_fib:0.7 arpresolve:0.5 2.0 kernel rn_match rtalloc1_fib 1.7 kernel __mtx_lock_sleep __mtx_lock_flags 1.7 kernel ip_outputipsec_process_done:1.1 ip_forward:0.6 1.4 kernel critical_exitspinlock_exit 1.3 kernel spinlock_exitether_nh_input 1.3 kernel ixgbe_rxeof ixgbe_msix_que 1.2 kernel malloc 1.2 kernel critical_enter 1.2 kernel ixgbe_xmit ixgbe_mq_start_locked 1.1 aesni.ko aesni_encrypt_cbcaesni_process 1.1 kernel esp_output ipsec4_process_packet 1.1 kernel key_allocsp ipsec_getpolicybyaddr 1.0 kernel __mtx_lock_spin_flag 1.0 kernel in_cksumdata in_cksum_skip 1.0 kernel free 1.0 kernel ip_input netisr_dispatch_src 1.0 kernel ether_nh_input netisr_dispatch_src 1.0 kernel bounce_bus_dmamap_lo bus_dmamap_load_mbuf_sg 0.9 kernel _mtx_lock_spin_cooki pmclog_reserve 0.8 kernel m_copydata 0.8 kernel ipsec4_process_packe ip_ipsec_output -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800: > Well.. It looks like IPSEC is still broken in head... I can get > pings to pass, but now on IPv4 transport mode, I can't get syn's to > be sent out... I see the output packet in the protocol stats, but > no packets go out the interface... > > If you could provide me w/ a simple set of spdadd commands, or the > dumps from the machine, that'd be good... > > Hmm I just ran ping -f so I could generate some traffic, and > managed to get a: > panic: System call sendto returing with kernel FPU ctx leaked > > I'll look into this... I just verified that this happens on a clean HEAD @ r274534: FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 No modifications, nothing, and I got the same panic: panic: System call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffee588, rbp = 0x7ffee5c0 --- KDB: enter: panic So, it's clearly not my patch that is causing the issue... Andrey, can you verify that you do not receive the same panic w/o my patches? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
On 14.11.2014 03:52, Andrey V. Elsukov wrote: > 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:0x80d05c43 > stack pointer = 0x28:0xfe3f7e70 > frame pointer = 0x28:0xfe3f7eb0 > code segment = base 0x0, limit 0xf, 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 full backtrace is here: http://paste.org.ru/?a3f8pw Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1 Also I noticed that on higher packet rate sometimes kernel reports about wrong source route attempts: kernel: attempted source route from 244.116.138.102 to 225.51.107.139 kernel: attempted source route from 19.120.181.94 to 238.17.74.139 kernel: attempted source route from 186.217.142.184 to 233.165.4.102 kernel: attempted source route from 134.41.78.248 to 231.122.242.144 probably there is mbuf's memory corruption somewhere. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
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:0x80d05c43 > stack pointer = 0x28:0xfe3f7e70 > frame pointer = 0x28:0xfe3f7eb0 > code segment = base 0x0, limit 0xf, 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 0x80355525 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) > at /usr/src/sys/ddb/db_command.c:568 > #2 0x8035520d in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:440 > #3 0x80354f84 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:493 > #4 0x80357980 in db_trap (type=, code=0) > at /usr/src/sys/ddb/db_main.c:251 > #5 0x8095c641 in kdb_trap (type=9, code=0, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0x80d1edcc in trap_fatal (frame=0xfe3f7dc0, > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > #7 0x80d1ea6e in trap (frame=) at > /usr/src/sys/amd64/amd64/trap.c:201 > #8 0x80d04092 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:231 > #9 0x80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 > #10 0x80d1e7ae in trap (frame=) at > /usr/src/sys/amd64/amd64/trap.c:432 > #11 0x80d04092 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:231 > #12 0x8202f96e in aesni_encrypt_cbc (rounds=10, > key_schedule=0xf8005603d400, len=3, from=0xf8013b0de65a "E", > to=0xf8013b0de65a "E", > iv=0xf8005603d6d0 "???#??8???:n???\r??\f?\v") at > /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 > #13 0x820318d
Re: CFR: AES-GCM and OpenCrypto work review
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:0x80d05c43 stack pointer = 0x28:0xfe3f7e70 frame pointer = 0x28:0xfe3f7eb0 code segment= base 0x0, limit 0xf, 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 0x80355525 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:568 #2 0x8035520d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0x80354f84 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0x80357980 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0x8095c641 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x80d1edcc in trap_fatal (frame=0xfe3f7dc0, eva=) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0x80d1ea6e in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:201 #8 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0x80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 #10 0x80d1e7ae in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:432 #11 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0x8202f96e in aesni_encrypt_cbc (rounds=10, key_schedule=0xf8005603d400, len=3, from=0xf8013b0de65a "E", to=0xf8013b0de65a "E", iv=0xf8005603d6d0 "�#��8�:n�\r��\f���\v") at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13 0x820318d0 in aesni_process (dev=, crp=0xf80109f7bc08, hint=) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 #14 0x80b170e9 in crypto_dispatch (crp=0xf80109f7bc08) at /usr/src/sys/opencrypto/crypto.c:807 #15 0x80b076d6 in esp_output (m=, isr=, mp=0x3, skip=
Re: CFR: AES-GCM and OpenCrypto work review
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +: > On 08/11/14 20:45, John-Mark Gurney wrote: > >Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +: > >>On 08/11/14 04: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 have the question regarding to the algorithm of GF field calculations > >>used in the proposed implementation: why not use the recent researches > >>in GCM calculations, e.g. described in [1], for further speed > >>optimizations? > >> > >>[1] - https://eprint.iacr.org/2013/157.pdf > > > >The paper you linked to does not describe a new way of calculating > >GHASH, but evalutation of a bug in their implementation using the > >PCLMULQDQ instruction... > > > >If you mean, why don't I use OpenSSL's code? The reason is that their > >code is a perl script that generates assmebly... We don't have > >perl in base.. and I didn't want more assembly in our tree (see below).. > > > >Instead, I decided to use code from Intel's whitepaper: > >Intel® Carry-Less Multiplication Instruction and its Usage for > >Computing the GCM Mode > > > >I didn't use their assembly version because I wanted to have > >maintainable code, and also the same code can be used on both i386 > >and amd64 arches.. This turns out to also be a good thing, as when > >I add segmented buffer support, it'll be much easier to add to the C > >version, and I only have to do the work once for two arches... > > > >Also, the software GF library that I wrote is using state of the art > >algorithms... An OpenBSD developer has tested my code and has seen > >a significant performance improvement over their old code, and are > >evaluating if they want to/can include it in their tree... > > > >Hope this answers your question. If not, please be more specific so > >I can answer it. > > I'm sorry, I thought that is the paper that is a transcript of the > following presentation: > > http://2013.diac.cr.yp.to/slides/gueron.pdf > > made by the same authors. The transcript is not available so far it seems. > > And regarding assembler/C maintainability I would argue that the current > intrinsics based implementation is more readable than the pure assembler > solution (and it is still machine dependent). Of course, I'm not the > expert in such optimizations, so that is just my own
Re: CFR: AES-GCM and OpenCrypto work review
On 08/11/14 20:45, John-Mark Gurney wrote: Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +: On 08/11/14 04: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 have the question regarding to the algorithm of GF field calculations used in the proposed implementation: why not use the recent researches in GCM calculations, e.g. described in [1], for further speed optimizations? [1] - https://eprint.iacr.org/2013/157.pdf The paper you linked to does not describe a new way of calculating GHASH, but evalutation of a bug in their implementation using the PCLMULQDQ instruction... If you mean, why don't I use OpenSSL's code? The reason is that their code is a perl script that generates assmebly... We don't have perl in base.. and I didn't want more assembly in our tree (see below).. Instead, I decided to use code from Intel's whitepaper: Intel® Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode I didn't use their assembly version because I wanted to have maintainable code, and also the same code can be used on both i386 and amd64 arches.. This turns out to also be a good thing, as when I add segmented buffer support, it'll be much easier to add to the C version, and I only have to do the work once for two arches... Also, the software GF library that I wrote is using state of the art algorithms... An OpenBSD developer has tested my code and has seen a significant performance improvement over their old code, and are evaluating if they want to/can include it in their tree... Hope this answers your question. If not, please be more specific so I can answer it. Thanks. I'm sorry, I thought that is the paper that is a transcript of the following presentation: http://2013.diac.cr.yp.to/slides/gueron.pdf made by the same authors. The transcript is not available so far it seems. And regarding assembler/C maintainability I would argue that the current intrinsics based implementation is more readable than the pure assembler solution (and it is still machine dependent). Of course, I'm not the expert in such optimizations, so that is just my own feeling. By the way, do you have some concrete numbers about the performance of your aes-gcm? (I recently could do aes-128-gcm at about 32 gigabits/sec that is not a limit of the modern hardware for sure). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +: > On 08/11/14 04: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 have the question regarding to the algorithm of GF field calculations > used in the proposed implementation: why not use the recent researches > in GCM calculations, e.g. described in [1], for further speed optimizations? > > [1] - https://eprint.iacr.org/2013/157.pdf The paper you linked to does not describe a new way of calculating GHASH, but evalutation of a bug in their implementation using the PCLMULQDQ instruction... If you mean, why don't I use OpenSSL's code? The reason is that their code is a perl script that generates assmebly... We don't have perl in base.. and I didn't want more assembly in our tree (see below).. Instead, I decided to use code from Intel's whitepaper: Intel® Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode I didn't use their assembly version because I wanted to have maintainable code, and also the same code can be used on both i386 and amd64 arches.. This turns out to also be a good thing, as when I add segmented buffer support, it'll be much easier to add to the C version, and I only have to do the work once for two arches... Also, the software GF library that I wrote is using state of the art algorithms... An OpenBSD developer has tested my code and has seen a significant performance improvement over their old code, and are evaluating if they want to/can include it in their tree... Hope this answers your question. If not, please be more specific so I can answer it. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
On 08/11/14 04: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 have the question regarding to the algorithm of GF field calculations used in the proposed implementation: why not use the recent researches in GCM calculations, e.g. described in [1], for further speed optimizations? [1] - https://eprint.iacr.org/2013/157.pdf -- Vsevolod Stakhov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: AES-GCM and OpenCrypto work review
John-Mark Gurney writes: > 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. Please remember to bump __FreeBSD_version. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
