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
> 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:
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 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
> >
delay((ms+1) * 1000);
else
tsleep(, PRIBIO, "usbdly", (ms*hz+999)/1000 + 1);
}
-
If it's not required to add extra 1 tick on kpause(), usb_delay_ms_locked()
can be simplified.
[*1] http://www.netbsd.or
> 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 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
> 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.
> 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
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,
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,
> 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
12 matches
Mail list logo
