On Wed, Jun 17, 2020 at 11:36:11PM +, Taylor R Campbell wrote:
> Thoughts? Comments? Objections? Musical numbers by Groucho Marx on
> the nature of consensus?
I like all of it, especially the fpu kernel thread part you did leave
out for now, which I wanted since we started thinking about in
> Date: Thu, 18 Jun 2020 07:19:43 +0200
> From: Martin Husemann
>
> One minor nit: with the performance impact that high, and there being
> setups where runtime side channel attacks are totally not an issue,
> maybe we should leave the old code in place for now, #ifdef'd as
> default-off options
Taylor R Campbell writes:
>> Date: Thu, 18 Jun 2020 07:19:43 +0200
>> From: Martin Husemann
>>
>> One minor nit: with the performance impact that high, and there being
>> setups where runtime side channel attacks are totally not an issue,
>> maybe we should leave the old code in place for now,
hello. I have what may be a silly question. Does this change mean
that I386 users won't have AES capabilities in the kernel at all going
forward? (I gather that's true for architectures like Sparc, but I'm
assuming the AES code we did have didn't run very well on Sparc anyway.)
However,
> On Jun 17, 2020, at 7:36 PM, Taylor R Campbell wrote:
>
>
> [EXTERNAL EMAIL]
>
> ...
> 1. Replace the variable-time AES reference implementation we've been
> using by constant-time AES software from Thomas Pornin's
> high-quality BearSSL libary.
> ...
> Performance impact: The cos
> Date: Thu, 18 Jun 2020 07:06:16 -0400
> From: Greg Troxel
>
> For me, the main use of cgd is to encrypt backup drives. [...]
>
> I don't really see the new cipher as a reasonable option for removable
> disks that need to be accessed by older systems. I can see it for
> encrypted local disk. B
> Date: Thu, 18 Jun 2020 09:37:36 -0700
> From: Brian Buhrow
>
> hello. I have what may be a silly question. Does this change mean
> that I386 users won't have AES capabilities in the kernel at all going
> forward? (I gather that's true for architectures like Sparc, but I'm
> assuming th
> Date: Thu, 18 Jun 2020 13:18:13 +
> From:
>
> > On Jun 17, 2020, at 7:36 PM, Taylor R Campbell wrote:
> > Performance impact: The cost is that constant-time AES software is
> > much slower -- cgd AES-CBC encryption throughput is reduced to
> > about 1/3, and decryption to about
> Date: Thu, 18 Jun 2020 17:17:56 +
> From: Taylor R Campbell
>
> > Date: Thu, 18 Jun 2020 09:37:36 -0700
> > From: Brian Buhrow
> >
> > hello. I have what may be a silly question. Does this change mean
> > that I386 users won't have AES capabilities in the kernel at all going
> > for
hello. Another question.
Does xen advertise and allow the use of these instructions on PV and PVH
domu's?
-thanks
-Brian
> Date: Thu, 18 Jun 2020 11:37:36 -0700
> From: Brian Buhrow
>
> Does xen advertise and allow the use of these instructions on PV and PVH
> domu's?
Generally I would expect yes. You can test on a particular system
with `cpuctl identify'. For example:
# cpuctl identify 0 | grep -w AES
cpu0: fe
Taylor R Campbell writes:
>> I don't really see the new cipher as a reasonable option for removable
>> disks that need to be accessed by older systems. I can see it for
>> encrypted local disk. But given AES hardware speedup, I suspect most
>> people can just stay with AES.
>
> Can you be more
On Thu, Jun 18, 2020 at 10:26:10PM +, Taylor R Campbell wrote:
> # cpuctl identify 0 | grep -w AES
> cpu0: features1 0x7fbae3bf
> ^^^
> The highlighted part in `features1' is the important thing.
FWIW I did that on all amd64 machines I have in production and
On 19/06/2020 07:37, Martin Husemann wrote:
> the other two are quite old (probably on the border for your 10 years
> estimate, maybe even slightly older and I'm suprised too, usualy
> amd64 hardware is not that good long term and forces itself being
> replaced way earlier).
AES-NI came in with
On Fri, Jun 19, 2020 at 10:20:46AM +0100, Sevan Janiyan wrote:
>
>
> On 19/06/2020 07:37, Martin Husemann wrote:
> > the other two are quite old (probably on the border for your 10 years
> > estimate, maybe even slightly older and I'm suprised too, usualy
> > amd64 hardware is not that good long
On Fri, Jun 19, 2020 at 08:37:53AM +0200, Martin Husemann wrote:
> On Thu, Jun 18, 2020 at 10:26:10PM +, Taylor R Campbell wrote:
> > # cpuctl identify 0 | grep -w AES
> > cpu0: features1 0x7fbae3bf
> > ^^^
> > The highlighted part in `features1' is the impor
I'm really excited about this patch in general, especially getting
an alternative to AES for cgd that has similar security properties
but isn't terrible in software.
Just one comment that nobody has brought up yet..
On Wed, Jun 17, 2020 at 11:36:11PM +, Taylor R Campbell wrote:
> * Other exis
> Date: Thu, 18 Jun 2020 20:21:36 -0400
> From: Greg Troxel
>
> Taylor R Campbell writes:
>
> > Can you be more specific about the systems you're concerned about?
>
> What I meant is: consider an external USB disk of say 4T, which has a
> cgd partition within which is ffs.
>
> Someone attache
On Thu, Jun 18, 2020 at 08:21:36PM -0400, Greg Troxel wrote:
> So it remains to make userland AES use also constant time, as a separate
> step?
For userland AES, we are mostly using OpenSSL.
There was a bug recently in the in-src copy of OpenSSL that prevented it
from detecting the CPU type prope
Taylor R Campbell writes:
>> What I meant is: consider an external USB disk of say 4T, which has a
>> cgd partition within which is ffs.
>>
>> Someone attaches it to several systems in turn, doing cgd_attach, mount,
>> and then runs bup with /mnt/bup as the target, getting deduplication
>> acros
a data point on a machine from 2014:
$ ./aestest -l
BearSSL aes_ct
Intel SSE2 bitsliced
$ progress -f /dev/zero sh -c 'exec ./aestest -e -b 256 -c aes-xts -i "Intel
SSE2 bitsliced" > /dev/null'
399 MiB 56.98 MiB/s ^C
$ progress -f /dev/zero sh -c 'exec ./aestest -e -b 256 -c aes-xts -i "Bea
> Date: Mon, 22 Jun 2020 23:43:20 +
> From: Taylor R Campbell
>
> There is some more room for improvement -- SSSE3 provides PSHUFB which
> can sequentially speed up parts of AES, and is supported by a good
> number of amd64 CPUs starting around 14 years ago that lack AES-NI --
> but there are
This is a *huge* effort. Thank you.
On Sun, Jun 28, 2020 at 03:27:56AM +, Taylor R Campbell wrote:
> > Date: Mon, 22 Jun 2020 23:43:20 +
> > From: Taylor R Campbell
> >
> > There is some more room for improvement -- SSSE3 provides PSHUFB which
> > can sequentially speed up parts of AES,
> Date: Wed, 17 Jun 2020 23:36:11 +
> From: Taylor R Campbell
>
> [bcc tech-crypto, tech-security; followups to tech-kern]
>
> It's been well-known since 2005[1] that naive AES software, like we
> use today in the NetBSD kernel, is vulnerable to cache-timing attacks
> (CVE-2005-1797). These
> Date: Tue, 30 Jun 2020 00:43:15 +
> From: Taylor R Campbell
>
> - bitsliced AES four blocks at a time with SSE2 on all x86
Correction: all amd64, but not all x86 -- there are i386 CPUs without
SSE2, of course, but they are mostly >=20 years old at this point.
25 matches
Mail list logo
