Re: AES leaks, cgd ciphers, and vector units in the kernel

> 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

Re: [PATCH] Kernel entropy rework

> On Dec 21, 2019, at 5:08 PM, Taylor R Campbell wrote: > > > > The attached patch set reworks the kernel entropy subsystem. > > ... > - For (e.g.) keyboard interrupt and network packet timings, this >is zero, because an adversary can cause events to happen with >

Re: racy acccess in kern_runq.c

> On Dec 6, 2019, at 10:21 AM, Mouse wrote: > > > [EXTERNAL EMAIL] > >> Compilers have became much more aggressive over the years. But they >> are allowed to be so by the C standard. Specifically, in addition to >> code-level re-ordering, plain accesses (loads/stores) are subject to >>

Re: /dev/random is hot garbage

> On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote: > > > [EXTERNAL EMAIL] > > On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote: >> /dev/urandom is equivalent to /dev/random if there is adequate entropy, >> but it will also deliver random numbers not suitable for

Re: /dev/random is hot garbage

> On Jul 22, 2019, at 4:55 PM, Joerg Sonnenberger wrote: > > > [EXTERNAL EMAIL] > > On Mon, Jul 22, 2019 at 04:36:41PM +, paul.kon...@dell.com wrote: >> >> >>> On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote: >>> >>> >>> [EXTERNAL EMAIL] >>> >>> On Sun, Jul 21, 2019 at

Re: /dev/random is hot garbage

> On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote: > > > [EXTERNAL EMAIL] > > On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote: >> >> >>> On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote: >>> >>> >>> [EXTERNAL EMAIL] >>> >>> On Sun, Jul 21, 2019 at

Re: Plentiful unpredictable randomness

> On Jul 22, 2019, at 8:17 AM, Andreas Gustafsson wrote: > > > [EXTERNAL EMAIL] > > Taylor R Campbell wrote: >> It has become popular to redefine the traditional semantics of >> /dev/random or /dev/urandom so that one or both will block once at >> boot until the OS thinks the entropy pool

Re: /dev/random is hot garbage

> On Jul 21, 2019, at 4:55 PM, Edgar Fuß wrote: > > > [EXTERNAL EMAIL] > > TRC> There is no reason in modern cryptography to read more than one byte > TRC> from /dev/random ever in a single application; once you have done > TRC> that, or confirmed some other way that the the entropy pool is

Re: /dev/random is hot garbage

> On Jul 21, 2019, at 3:20 PM, Taylor R Campbell > wrote: > > > [EXTERNAL EMAIL] > >> Date: Sun, 21 Jul 2019 20:52:52 +0200 >> From: Manuel Bouyer >> >> /dev/randon actually works as documented and if rust wants /dev/urandom >> behavior it should use /dev/urandom. Also I'd like to get

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

> On Jun 28, 2019, at 4:44 PM, Christos Zoulas wrote: > > > [EXTERNAL EMAIL] > > > Background: > > Max disabled the 32 bit code paths in process_machdep.c and matchdep.c > so trying to debug 32 bit processes from a 64 bit debugger. From his commit > message I think this was not

Re: Importing libraries for the kernel

> On Dec 14, 2018, at 2:16 PM, Joerg Sonnenberger wrote: > > On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote: > ... >> I also disagree that asymmetric crypto is necessarily all that complex. >> Some asymmetric crypto algorithms require nothing more complex than >> large-number

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 14, 2018, at 9:30 AM, Joerg Sonnenberger wrote: > > > [EXTERNAL EMAIL] > > On Thu, Dec 13, 2018 at 02:37:06AM +0100, Kamil Rytarowski wrote: >> In real life it's often needed to store time_t pointing before the UNIX >> epoch. > > Again, I quite disagree and believe that you are

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 13, 2018, at 6:06 AM, Martin Husemann wrote: > > > [EXTERNAL EMAIL] > > On Thu, Dec 13, 2018 at 03:29:03AM +, David Holland wrote: >> On Wed, Dec 12, 2018 at 10:27:04PM +0100, Joerg Sonnenberger wrote: >>> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote:

Re: Spectre on non-amd64

> On Jan 19, 2018, at 4:47 PM, wrote: > > Hi folks. > > I think that the spectre variant 2 situation is a lot worse for: > - Speculative CPU > - Weak memory protection > > Then I don't need a JIT for gadgets. > > Architectures that fall into this: > -

Re: Spectre

> On Jan 18, 2018, at 10:31 AM, Mouse wrote: > >> ... > >> The Spectre fixes all amount to a speculative barrier, which will do >> the job just as well (though it requires code change). > > Yes...but it requires a code change in the wrong place. > > That "if

Re: Spectre

> On Jan 18, 2018, at 9:48 AM, Mouse wrote: > >> Since this involves a speculative load that is legal from the >> hardware definition point of view (the load is done by kernel code), >> this isn't a hardware bug the way Meltdown is. > > Well, I'd say it's the same

Re: Spectre

> On Jan 18, 2018, at 8:49 AM, Joerg Sonnenberger wrote: > > On Wed, Jan 17, 2018 at 09:38:27PM -0500, Mouse wrote: >> But, on the other hand, I can easily imagine a CPU designer looking at >> it and saying "What's the big deal if this code can read that location? >> It can get

Re: Spectre

> On Jan 17, 2018, at 8:08 PM, Mouse wrote: > > ... >> - Even speculative execution obeys access restrictions, > > In some respects. Meltdown is possible because Intel spec ex does not > obey access restrictions in one particular respect; I don't know what >

Re: meltdown

> On Jan 4, 2018, at 6:01 PM, Warner Losh wrote: > > > > On Thu, Jan 4, 2018 at 2:58 PM, Mouse wrote: > > As I understand it, on intel cpus and possibly more, we'll need to > > unmap the kernel on userret, or else userland can read arbitrary > >

Re: meltdown

> On Jan 4, 2018, at 4:58 PM, Mouse wrote: > >> As I understand it, on intel cpus and possibly more, we'll need to >> unmap the kernel on userret, or else userland can read arbitrary >> kernel memory. > > "Possibly more"? Anything that does speculative execution

Re: mount_apfs?

> On Nov 8, 2017, at 5:07 AM, Edgar Fuß wrote: > >> here's a description of the APFS (Apple File System) format: > So they didn't open-source the code? Apparently not. But an entry in "Hacker news" (on ycombinator) says: An open source implementation is not available

Re: kaslr: better rng

> On Nov 7, 2017, at 11:21 AM, Taylor R Campbell > wrote: > >> Date: Tue, 7 Nov 2017 09:16:25 +0100 >> From: Maxime Villard >> ... >> Well yes, my initial plan was two different files. > > What's the security goal you hope to achieve by

Re: kaslr: better rng

> On Nov 6, 2017, at 12:51 PM, Maxime Villard wrote: > > Le 06/11/2017 à 18:28, Thor Lancelot Simon a écrit : >> On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote: >>> I'm in a point where I need to have a better rng before continuing - and an >>> rng that can be

Re: Access to DMA memory while DMA in progress?

> On Oct 27, 2017, at 10:36 AM, Mouse wrote: > >>> I would like to read the DMA buffer while DMA is still going on. >>> [...] I'm fine if the CPU's view lags the hardware's view slightly, >>> but I do care about the CPU's view of the DMA write order matching >>> the

Re: Access to DMA memory while DMA in progress?

> On Oct 27, 2017, at 9:38 AM, Mouse wrote: > > ... > I would like to read the DMA buffer while DMA is still going on. That > is, I have a buffer of (say) 64K and the hardware is busily writing > into it; I want to read the buffer and see what the hardware has >

Re: how to tell if a process is 64-bit

> On Sep 10, 2017, at 10:31 AM, Thor Lancelot Simon wrote: > > On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: >>> In a cross-platform process utility tool the question came up how to >>> decide if a process is 64-bit. >> >> First, I have to ask: what does it mean to say

Re: how to tell if a process is 64-bit

> On Sep 8, 2017, at 4:00 PM, matthew green wrote: > >> Is the answer "it's using an ISA with 64-bit registers and addresses"? >> This actually can be broken down into the "registers" and "addresses" >> portion, but, in practice, the two tend to go together. (Always true >>

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

> On Mar 31, 2017, at 4:16 PM, Thor Lancelot Simon wrote: > > On Fri, Mar 31, 2017 at 07:16:25PM +0200, Jarom??r Dole??ek wrote: >>> The problem is that it does not always use SIMPLE and ORDERED tags in a >>> way that would facilitate the use of ORDERED tags to enforce barriers.

Re: Restricting rdtsc [was: kernel aslr]

> On Mar 28, 2017, at 2:37 PM, Taylor R Campbell > wrote: > > [EXTERNAL EMAIL] > >> Date: Tue, 28 Mar 2017 16:58:58 +0200 >> From: Maxime Villard >> >> Having read several papers on the exploitation of cache latency to defeat >> aslr

Re: "Wire" definitions and __packed

> On Oct 6, 2016, at 2:01 PM, Joerg Sonnenberger wrote: > > On Fri, Oct 07, 2016 at 04:59:30AM +1100, matthew green wrote: >> John Nemeth writes: >>> On Oct 6, 3:01pm, matthew green wrote: >>> } >>> } > X86 doesn't have alignment restrictions. The platform >>> } >

Re: Plan: journalling fixes for WAPBL

> On Sep 28, 2016, at 7:22 AM, Jaromír Doleček > wrote: > > I think it's far assesment to say that on SATA with NCQ/31 tags (max > is actually 31, not 32 tags), it's pretty much impossible to have > acceptable write performance without using write cache. We could

Re: Plan: journalling fixes for WAPBL

> On Sep 23, 2016, at 10:51 AM, Warner Losh wrote: > > On Fri, Sep 23, 2016 at 7:38 AM, Thor Lancelot Simon wrote: >> On Fri, Sep 23, 2016 at 11:47:24AM +0200, Manuel Bouyer wrote: >>> On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: >

Re: FUA and TCQ (was: Plan: journalling fixes for WAPBL)

> On Sep 23, 2016, at 5:49 AM, Edgar Fuß wrote: > >> The whole point of tagged queueing is to let you *not* set [the write >> cache] bit in the mode pages and still get good performance. > I don't get that. My understanding was that TCQ allowed the drive to re-order >