From owner-freebsd-security@FreeBSD.ORG Sun Nov 9 19:16:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8840B93F; Sun, 9 Nov 2014 19:16:18 +0000 (UTC) Received: from snorky.mixmin.net (snorky.mixmin.net [IPv6:2a01:4f8:100:5243::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 191D2C05; Sun, 9 Nov 2014 19:16:17 +0000 (UTC) Received: by snorky.mixmin.net (Postfix, from userid 1011) id 3BA2DEAB3B; Sun, 9 Nov 2014 19:15:42 +0000 (GMT) Authentication-Results: snorky.mixmin.net; dkim=fail reason="verification failed; unprotected key" header.d=gmail.com header.i=@gmail.com header.b=m/Qoe9HI; dkim-adsp=none (unprotected policy); dkim-atps=neutral X-Old-Original-To: nymserv@mixmin.net Delivered-To: nymserv@mixmin.net Received: by snorky.mixmin.net (Postfix, from userid 110) id 6ED13EADBA; Fri, 7 Nov 2014 21:07:04 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on snorky.mixmin.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=6.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from eugeni.torproject.org (eugeni.torproject.org [IPv6:2620:0:6b0:b:1a1a:0:26e5:480d]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by snorky.mixmin.net (Postfix) with ESMTPS id 149B3EAEEF for ; Fri, 7 Nov 2014 21:07:02 +0000 (GMT) Received: from eugeni.torproject.org (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id 4069431286; Fri, 7 Nov 2014 21:06:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeni.torproject.org (Postfix) with ESMTP id A46BE27DEB for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at Received: from eugeni.torproject.org ([127.0.0.1]) by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zKFqRiO0NOv for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not verified)) by eugeni.torproject.org (Postfix) with ESMTPS id 7C9BF2697B for ; Fri, 7 Nov 2014 21:06:52 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so2185863vcb.24 for ; Fri, 07 Nov 2014 13:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q8Bwf9rQwuFMx01aXD8aOzVraH2Q+lTxJLoP6htJ2dw=; b=m/Qoe9HIldtUqe1tl2UGTbANmZfpK9CC/Oa3Xz/9U9z78Y/oH/li1mrR/N7308HUlp Mj61xFBS6cpeQp2XxVg3Qo4bWok6upA93kzIPurOQ7A+xNQVhKR8XMwwoDds/nrw7TZ6 dcXL5B4qTV4z4mq7FeWYC8ZISwq3BQ8nPs+gFi7DK/2Ikgc7qD1aFKkAg9hcv0hZTgz6 r2dJr/TbPtocVfRKyUkYdS/2fv2BIOp1JFwlNgJhwjdYuCWvGtTW3SkYGM5u0VEEmqCp pTH6kuk4Z4oTwLIwh9nvUr8aR+q4J9tjWVqeFp97lAQUibpdQGQ6AOFarCc1/ucWG0Yw RQsg== MIME-Version: 1.0 X-Received: by 10.221.38.66 with SMTP id th2mr9320080vcb.21.1415394410134; Fri, 07 Nov 2014 13:06:50 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 13:06:50 -0800 (PST) In-Reply-To: References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 16:06:50 -0500 Message-ID: From: grarpamp To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) X-BeenThere: tor-relays@lists.torproject.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tor-relays@lists.torproject.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: tor-relays-bounces@lists.torproject.org Sender: "tor-relays" X-Mailman-Approved-At: Sun, 09 Nov 2014 20:32:36 +0000 Cc: FreeBSD Net , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:16:18 -0000 On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. > On 7 November 2014 00:20, grarpamp wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: >>> >>> FreeBSD still seems to use globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays From owner-freebsd-security@FreeBSD.ORG Wed Nov 12 19:41:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F5F8DE7; Wed, 12 Nov 2014 19:41:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF1D7DD7; Wed, 12 Nov 2014 19:41:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sACJfBxU032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 11:41:11 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sACJfA3w032148; Wed, 12 Nov 2014 11:41:10 -0800 (PST) (envelope-from jmg) Date: Wed, 12 Nov 2014 11:41:10 -0800 From: John-Mark Gurney To: Vsevolod Stakhov Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141112194110.GX24601@funkthat.com> Mail-Followup-To: Vsevolod Stakhov , freebsd-security@freebsd.org, FreeBSD-Current References: <20141108042300.GA24601@funkthat.com> <545E6712.5060305@highsecure.ru> <20141108204538.GI24601@funkthat.com> <545E8904.6070109@highsecure.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <545E8904.6070109@highsecure.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Nov 2014 11:41:11 -0800 (PST) Cc: freebsd-security@freebsd.org, FreeBSD-Current X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:41:13 -0000 Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +0000: > On 08/11/14 20:45, John-Mark Gurney wrote: > >Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000: > >>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 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). So, in bare metal userland testing, iirc, I was able to get around 1GByte/sec on a single core... That doesn't take into account kernel and framework overhead... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Fri Nov 14 00:53:16 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE83EA66; Fri, 14 Nov 2014 00:53:16 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6ACA4; Fri, 14 Nov 2014 00:53:16 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 190531440E8F; Fri, 14 Nov 2014 03:53:13 +0300 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 8D3E61703976; Fri, 14 Nov 2014 03:53:12 +0300 (MSK) Received: from 84.201.167.97-vpn.dhcp.yndx.net (84.201.167.97-vpn.dhcp.yndx.net [84.201.167.97]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id zanu1dxmSn-rBH0erNx; Fri, 14 Nov 2014 03:53:11 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 967a624c-2690-4607-8972-9aacbe2218b8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415926391; bh=XQOdl5wldJ2nq3H96DodnztqCCVBQTN99100DNGD9wQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=J8tn0e1By3UPIGCr7ckosi0NK5ojALvf3yrw4/z26BhqdzAjuhEOmoACS3cYX8+Bk CpATJmYuj/uiNXZ5HXhNXXdkgkJPwIIVlniaA5xdhAGG4lozL4TKIDmThmOC0zv8at DA+dgtctJCLBNOKWWmC0J+zTCew4A9czx5JFJ/eo= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54655257.8080705@yandex.ru> Date: Fri, 14 Nov 2014 03:52:39 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> In-Reply-To: <20141108042300.GA24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08.11.2014 07:23, John-Mark Gurney wrote: > Hello, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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?) >=20 > Main patch (192KB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch >=20 > Data files (~20MB): > https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch >=20 > 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. >=20 > 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. >=20 > 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 =3D 4; apic id =3D 04 instruction pointer =3D 0x20:0xffffffff80d05c43 stack pointer =3D 0x28:0xfffffe00003f7e70 frame pointer =3D 0x28:0xfffffe00003f7eb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq286: ix0:que 4) The backtrace: #0 doadump (textdump=3D276160512) at pcpu.h:219 #1 0xffffffff80355525 in db_fncall (dummy1=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff8035520d in db_command (cmd_table=3D0x0) 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=3D, code=3D0= ) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff8095c641 in kdb_trap (type=3D9, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d1edcc in trap_fatal (frame=3D0xfffffe00003f7dc0, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0xffffffff80d1ea6e in trap (frame=3D) 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=3D) 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=3D10, key_schedule=3D0xfffff8005603d400, len=3D3, from=3D0xfffff8013b0de65a "E"= , to=3D0xfffff8013b0de65a "E", iv=3D0xfffff8005603d6d0 "=EF=BF=BD#=EF=BF=BD=EF=BF=BD8=EF=BF=BD:n=EF=BF= =BD\r=EF=BF=BD=EF=BF=BD\f=EF=BF=BD=EF=BF=BD=EF=BF=BD\v") at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13 0xffffffff820318d0 in aesni_process (dev=3D, crp=3D0xfffff80109f7bc08, hint=3D) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 #14 0xffffffff80b170e9 in crypto_dispatch (crp=3D0xfffff80109f7bc08) at /usr/src/sys/opencrypto/crypto.c:807 #15 0xffffffff80b076d6 in esp_output (m=3D, isr=3D, mp=3D0x3, skip=3D, protoff=3D) at /usr/src/sys/netipsec/xform_esp.c:905 #16 0xffffffff80af7457 in ipsec4_process_packet (m=3D0xfffff8013b0de600, isr=3D, flags=3D, tunalready=3D) at /usr/src/sys/netipsec/ipsec_output.c:594 #17 0xffffffff80a4a0db in ip_ipsec_output (m=3D, inp=3D, flags=3D0xfffffe00003f8494, error=3D0xfffffe00003f8490) at /usr/src/sys/netinet/ip_ipsec.c:332 #18 0xffffffff80a4b6b9 in ip_output (m=3D0xfffff8013b0de600, opt=3D, flags=3D1, imo=3D, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:476 #19 0xffffffff80a485eb in ip_forward (m=3D0xfffff8013b0de600, srcrt=3D) at /usr/src/sys/netinet/ip_input.c:1571 #20 0xffffffff80a4825e in ip_input (m=3D0xfffff8013b0de600) at /usr/src/sys/netinet/ip_input.c:754 #21 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #22 0xffffffff809dfb53 in ether_demux (ifp=3D, m=3D0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 #23 0xffffffff809e0758 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:573 #24 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #25 0xffffffff809dfdb6 in ether_input (ifp=3D, m=3D0= x0) at /usr/src/sys/net/if_ethersubr.c:674 #26 0xffffffff809e55e5 in vlan_input (ifp=3D0xfffff8000ef3e800, m=3D) at /usr/src/sys/net/if_vlan.c:1239 #27 0xffffffff809dfac4 in ether_demux (ifp=3D0xfffff8000ef3e800, m=3D0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717 #28 0xffffffff809e0758 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:573 #29 0xffffffff809e7be1 in netisr_dispatch_src (proto=3D, source=3D, m=3D0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #30 0xffffffff809dfdb6 in ether_input (ifp=3D, m=3D0= x0) at /usr/src/sys/net/if_ethersubr.c:674 #31 0xffffffff8059f303 in ixgbe_rxeof (que=3D0xfffff8000ef5c1a0) at /usr/src/sys/dev/ixgbe/ixgbe.c:4530 > Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) > support for our IPsec. Once these patches have been committed, I'll > work with him to integrate his patch. --=20 WBR, Andrey V. Elsukov --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZVJoAAoJEAHF6gQQyKF6gQoH/3BABEMxojQOwmeVo+ZR4Kh1 w3pi23AcHhw4v7fn0H+h0KHwuo4ZfNOJe5KrSSJ9BEt8wEQZnGS2LSQT7FZKDr8b oxUOrt9L2oQmjVLuIBlqbfIyAKPsCPN/Mt86EvBYTKQymWxstfLAct4ogx16SnSc qNKlb7IFONqAWIDfFGkOjLcwJdEq9YHCkPX4/lEurgJ2+BV/ToSl9Veq90HZL7ty fQ5+GYSRmDSYsuDwZQjy0fYYVdELnXYNR3Pzcfd9rr0pMvOsIlP4M29Bi22xvmzY AJzjPilR6Naj6viYr/3gr3bg5SW/g7WUfKnm6XyNGoXTPhPfF+FiMUCi18jLcjs= =PVaI -----END PGP SIGNATURE----- --mIJ8gMC0hbLng2nPMX2ha3xC2gE3kxrGc-- From owner-freebsd-security@FreeBSD.ORG Fri Nov 14 09:35:14 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1001CB2B; Fri, 14 Nov 2014 09:35:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BDEAB04; Fri, 14 Nov 2014 09:35:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAE9Z4Ao025491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 11:35:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAE9Z4Ao025491 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAE9Z3cB025486; Fri, 14 Nov 2014 11:35:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Nov 2014 11:35:03 +0200 From: Konstantin Belousov To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141114093503.GC17068@kib.kiev.ua> References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54655257.8080705@yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:35:14 -0000 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=, > dummy2=, dummy3=, > dummy4=) > 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=, code=0) > at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff8095c641 in kdb_trap (type=9, code=0, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80d1edcc in trap_fatal (frame=0xfffffe00003f7dc0, > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > #7 0xffffffff80d1ea6e in trap (frame=) 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=) 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=, > crp=0xfffff80109f7bc08, hint=) > 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=, > isr=, mp=0x3, skip=, > protoff=) > at /usr/src/sys/netipsec/xform_esp.c:905 > #16 0xffffffff80af7457 in ipsec4_process_packet (m=0xfffff8013b0de600, > isr=, flags=, > tunalready=) > at /usr/src/sys/netipsec/ipsec_output.c:594 > #17 0xffffffff80a4a0db in ip_ipsec_output (m=, > inp=, flags=0xfffffe00003f8494, > error=0xfffffe00003f8490) > at /usr/src/sys/netinet/ip_ipsec.c:332 > #18 0xffffffff80a4b6b9 in ip_output (m=0xfffff8013b0de600, opt= optimized out>, flags=1, imo=, inp=0x0) > at /usr/src/sys/netinet/ip_output.c:476 > #19 0xffffffff80a485eb in ip_forward (m=0xfffff8013b0de600, srcrt= 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= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #22 0xffffffff809dfb53 in ether_demux (ifp=, > m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 > #23 0xffffffff809e0758 in ether_nh_input (m=) at > /usr/src/sys/net/if_ethersubr.c:573 > #24 0xffffffff809e7be1 in netisr_dispatch_src (proto= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #25 0xffffffff809dfdb6 in ether_input (ifp=, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:674 > #26 0xffffffff809e55e5 in vlan_input (ifp=0xfffff8000ef3e800, m= 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=) at > /usr/src/sys/net/if_ethersubr.c:573 > #29 0xffffffff809e7be1 in netisr_dispatch_src (proto= out>, source=, m=0xfffff8013b0de65a) at > /usr/src/sys/net/netisr.c:968 > #30 0xffffffff809dfdb6 in ether_input (ifp=, 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 ? From owner-freebsd-security@FreeBSD.ORG Fri Nov 14 13:29:07 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EBC4C35; Fri, 14 Nov 2014 13:29:07 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31508693; Fri, 14 Nov 2014 13:29:07 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 76CAF14E12B0; Fri, 14 Nov 2014 16:29:03 +0300 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id E1B8B7E0A61; Fri, 14 Nov 2014 16:29:02 +0300 (MSK) Received: from 84.201.167.97-vpn.dhcp.yndx.net (84.201.167.97-vpn.dhcp.yndx.net [84.201.167.97]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id J3REum5P3h-T2IuvCLl; Fri, 14 Nov 2014 16:29:02 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5b7dc64c-f415-4133-84fc-460847e6c6a6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415971742; bh=ggonNKHdkQhTMtFZBTq756Rut8VHredgrFzfnRVVeDg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=HUEZ7DCDYExpy7pT99vsise5MPdN2oAhO7xz7YQhjJIJcd0D2Al/Jm1QaOv3TEWWE opG011iWQFWqJ/5mm9kWzCuiQZs5vnLT21+Fa4zK1tmSvjNc57mEykawrI5a8LrKwX m4iL3N0Mo3/vK6renb+sD5GP4AHqR7w259JnBvNA= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54660389.9060409@yandex.ru> Date: Fri, 14 Nov 2014 16:28:41 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org, John-Mark Gurney Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> In-Reply-To: <54655257.8080705@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:29:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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(). >=20 > atal trap 9: general protection fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > instruction pointer =3D 0x20:0xffffffff80d05c43 > stack pointer =3D 0x28:0xfffffe00003f7e70 > frame pointer =3D 0x28:0xfffffe00003f7eb0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12 (irq286: ix0:que 4) >=20 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. --=20 WBR, Andrey V. Elsukov --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZgONAAoJEAHF6gQQyKF67yYIAISKqHBxmAfFipC3BBq97KkE hS+UanK9G9UTYh+4BOcxUs35eRV/gOtB1oVPe3OnlTHyvtLmDE0intWuDHLNQYlG fzhxPi3kREAE9K/EINBHguaWLq0PePtWj9HUyx4vhRcvEwjg1sBKgfdLGOILDDQY /1TyyMTa7B4Jnh6/8hfmjlRzbXGhAO2clhAA8S93oBSafyNsxs6hTn7M3UAzdrcp dcJbVjFMgmADwWLdHoIGDXz06fGN+BttdprTXKELg5iMsI8n5su2tipNfKpXUWF0 yYIWjw++MqjXCfURjTExdp6W8eDMgo9KWZKXWllVSciFQzc3erjRbVS/oieUzSE= =kMbH -----END PGP SIGNATURE----- --tfN0oppBAS2no0GJKJEj0DM2SNr8NICgn-- From owner-freebsd-security@FreeBSD.ORG Fri Nov 14 19:39:14 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07FE9B0D; Fri, 14 Nov 2014 19:39:14 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B298D7EB; Fri, 14 Nov 2014 19:39:13 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAEJdBMB063368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 11:39:12 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAEJdBD2063367; Fri, 14 Nov 2014 11:39:11 -0800 (PST) (envelope-from jmg) Date: Fri, 14 Nov 2014 11:39:11 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141114193911.GR24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54660389.9060409@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Nov 2014 11:39:12 -0800 (PST) Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:39:14 -0000 Andrey V. Elsukov wrote this message on Fri, Nov 14, 2014 at 16:28 +0300: > 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: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 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. 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sat Nov 15 02:42:04 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C77BF54E; Sat, 15 Nov 2014 02:42:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87B0B68E; Sat, 15 Nov 2014 02:42:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAF2g1p8068009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 18:42:02 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAF2g1FC068008; Fri, 14 Nov 2014 18:42:01 -0800 (PST) (envelope-from jmg) Date: Fri, 14 Nov 2014 18:42:01 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141115024201.GW24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@FreeBSD.org, current@FreeBSD.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141114193911.GR24601@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Nov 2014 18:42:02 -0800 (PST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 02:42:04 -0000 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 jmg@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 0xfffffe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- 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." From owner-freebsd-security@FreeBSD.ORG Sat Nov 15 08:48:42 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DDA22AD; Sat, 15 Nov 2014 08:48:42 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27591C06; Sat, 15 Nov 2014 08:48:41 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 5C3CF1A4113C; Sat, 15 Nov 2014 11:48:36 +0300 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id D7FC3BE00E1; Sat, 15 Nov 2014 11:48:35 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id JK53Lvrmrn-mZE4w57u; Sat, 15 Nov 2014 11:48:35 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fe6cbe72-41f4-4572-b52f-33c9ebf71ceb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416041315; bh=S4S9cyEHVMb8+LzhOce0ix6CTyH4Lljfye0DLgzA86k=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=QSiHCOUhgW3hRlEYi1juWO2Qa66zFw+2widFIoGI3+jLXOXR3mZ9fC7JTAS97dVFk 5xI1eEt2EvqV0TjZY8odY45TP4G6nUgwMIBQsSnJXUKxub9VyR+V4y9qkW/NtsVglL MsI9U7ItSpg6xGXOncqfXe/Nz9WZmKXk4if5AVVQ= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5467134A.70005@yandex.ru> Date: Sat, 15 Nov 2014 11:48:10 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> In-Reply-To: <20141115024201.GW24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 08:48:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=20 >> 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... >>=20 >> If you could provide me w/ a simple set of spdadd commands, or the=20 >> dumps from the machine, that'd be good... >>=20 >> Hmm.... I just ran ping -f so I could generate some traffic, and=20 >> managed to get a: panic: System call sendto returing with kernel >> FPU ctx leaked >>=20 >> I'll look into this... >=20 > 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=20 > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > amd64 >=20 > No modifications, nothing, and I got the same panic: panic: System > call sendto returing with kernel FPU ctx leaked cpuid =3D 0 KDB: stack > backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at > vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at > kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at > amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD > ELF64, nosys), rip =3D 0x8011975aa, rsp =3D 0x7ffffffee588, rbp =3D > 0x7ffffffee5c0 --- KDB: enter: panic >=20 > So, it's clearly not my patch that is causing the issue... >=20 > Andrey, can you verify that you do not receive the same panic w/o my=20 > 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 "1111111111111111" ; 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 =3D> 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_lowest cpu_search_lowest:2.6 sched_pickcpu:0.9 3.2 kernel bcopy m_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_arg m_freem:1.0 free:0.7 2.2 kernel bzero uma_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_output ipsec_process_done:1.1 ip_forward:0= =2E6 1.4 kernel critical_exit spinlock_exit 1.3 kernel spinlock_exit ether_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_cbc aesni_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 --=20 WBR, Andrey V. Elsukov --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZxNQAAoJEAHF6gQQyKF6fukIAJ35XlpYwXLQnEBxOGIJJtZa wW36xLPzUFEBmDjwJHgWyIUM0nYaKPJF97ehzJbQoI5XPo/iqPP27/YdcLKcVDmu hUGY/dAZwZKHw7LMa17yKw7MHQQ123wtZ/k8kWBjxXi5aqUuvOFOBzYWyOvqlPgk lB2aX9TZP+5lSgL9LSxef7LDYXvIm7Mr4UAOn1OAuTQm+NqvlpG9M/yH8LCB7jhV h/dEWjb5Xs+pQBxvK5Uhi/sn23+NeRlV5Az5wRyja6pobzPYBU5DWrI5LD3ZZyvd CpXojg+vzu8wKjyr8LcWGzwhx6kybfHObuFOtUYZlHGsXrIuk5VJ90Q2VnNs6tA= =Zivg -----END PGP SIGNATURE----- --JHJuh6QQcG1kKIRAJEMv6E6o8teNfe88x-- From owner-freebsd-security@FreeBSD.ORG Sat Nov 15 12:19:34 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9299F8F; Sat, 15 Nov 2014 12:19:33 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC6FE2; Sat, 15 Nov 2014 12:19:33 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 73D0CBC0E74; Sat, 15 Nov 2014 15:19:29 +0300 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id F16136A028D; Sat, 15 Nov 2014 15:19:28 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Ldq4u59ykF-JSUCPPZ3; Sat, 15 Nov 2014 15:19:28 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 35d83053-a040-4695-994f-748c4182bc4c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416053968; bh=1MI3JG/xqOIGlgHsDjjoP8YJrGsbxd7Dj18PCRjF2Zs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=izfyFY4BjJbN/QT38gSb6SANZZ11kA1/UwXhZLPrfNWBCozGq6rUSwebQAY13Ip8I Q4hEiLziXWrgD7Q+NSOv8mHvukYuhTE1PzLsgkOz2k+X8AKvPidKr+WGHf3Lu2jHga 6ADkwDDFaohsXtUEqCSalDA/k3ZK/QWsUzcB6B9o= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <546744B6.8040504@yandex.ru> Date: Sat, 15 Nov 2014 15:19:02 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, current@FreeBSD.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> In-Reply-To: <20141115024201.GW24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 12:19:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC = amd64 >=20 > No modifications, nothing, and I got the same panic: > panic: System call sendto returing with kernel FPU ctx leaked > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001= de7a800 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > --- syscall (64, FreeBSD ELF64, nosys), rip =3D 0x8011975aa, rsp =3D 0x= 7ffffffee588, rbp =3D 0x7ffffffee5c0 --- > KDB: enter: panic >=20 > So, it's clearly not my patch that is causing the issue... >=20 > 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. --=20 WBR, Andrey V. Elsukov --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUZ0S8AAoJEAHF6gQQyKF6OHUIALW2z/ZBDLu2SsT6bes+DVsb F/VPwmTMiu00j+Nm435eQDKoD5ciK3H+O3bAMg/5642SQCVlqbKSiJb5Oi9JvulB B8T1X0YXDRQeMFTRQgZPckONJBP0RjIbXnjUxnbLDDabcEl5s7u/jyciQKcXpiL8 uGp5te24ORE6kbj8Rh+eCUuLfJTpVhc+izrDQX+ipFLqP1zstq7ZsdAFJfkPpC1w rjSSdBXeoAwHIcuM6zK7jVPp98XvMz6ZdqRJ6tUpylKyw5chZKhHdOtlF7CBmGmg ZvBuA0t6AE2Bi++B3KrvmdPsNjidG4RYnNCsE6qKe2Bv4Wdu3HyRIfvMz/uTbQE= =MPL8 -----END PGP SIGNATURE----- --q1CohB3C3EibA2n1IwbbGWMNnaWPanSwD--