Re: IFEF_MPSAFE

2017-11-14 Thread Ryota Ozaki 
On Fri, Nov 10, 2017 at 6:35 PM, Ryota Ozaki  wrote:
> Hi,
>
> http://www.netbsd.org/~ozaki-r/IFEF_MPSAFE.diff
>
> I'm going to commit the above change that integrates
> IFEF_OUTPUT_MPSAFE and IFEF_START_MPSAFE flags into
> IFEF_MPSAFE.
>
> The motivation is to not waste if_extflags bits. I'm now
> trying to make if_ioctl() hold KERNEL_LOCK selectively
> for some reasons as well as if_start() and if_output().

BTW this is a patch for this plan:
  http://www.netbsd.org/~ozaki-r/if_ioctl-no-KERNEL_LOCK.diff

It removes KERNEL_LOCK for if_ioctl from soo_ioctl and
selectively takes it in doifioctl. To this end, some fine-grain
KERNEL_LOCKs have to be added where calling components/functions
that aren't MP-safe.

  ozaki-r

> But adding one more flag for if_ioctl() is I think
> wasteful. Also there are other functions such as if_init()
> and if_slowtimo() that would also need a flag.
>
> So I propose to have just one flag for indications of
> MP-safe. If an interface have both MP-safe and non-MP-safe
> operations at a time, we have to set the IFEF_MPSAFE flag
> and let callees of non-MP-safe operations take KERNEL_LOCK.
>
> This change breaks ABI and need a kernel version bump,
> however, IFEF_*_MPSAFE flags are new to netbsd-8 so it
> doesn't break backward compatibility.
>
> Any comments or objections?
>
> Thanks,
>   ozaki-r

Re: Debugging function of localcount

2017-11-14 Thread Paul Goyette 

On Tue, 14 Nov 2017, Taylor R Campbell wrote:


Date: Mon, 13 Nov 2017 13:59:32 +0900
From: Ryota Ozaki 

I'm sorry for not replying this thread. I'm back.

I've revised the patch as your suggestions:
  http://www.netbsd.org/~ozaki-r/localcount_debug_atomic.revised.diff


Looks better, thanks!

Couple nits:

1. Still need to volatile-qualify lc_refcnt.
2. Either use unsigned and atomic_cas_uint, or uint32_t and
  atomic_cas_32, but not a mixture.

Random thought: What about a per-LWP counter for diagnostics, with
lwp_getspecific/setspecific?  No interprocessor overhead that way.
Could even assert when an lwp exits, or when a softint returns, that
no localcounts were leaked.

(This slightly changes the semantics of localcount so that it cannot
be passed from lwp to lwp (i.e., can't acquire in one and release in
the other; must acquire in both and release in both), but I don't
really see a problem with that.)


It seems to me that there's really no good reason to prohibit migration 
from one lwp to another;  the only apparent benefit of having such a 
restriction is the ability to verify that the restriction isn't being 
violated.


If we're changing the semantics to disallow this, we should be sure to 
update the man-page, too.  (Actually, we should update the man page in 
any case, to document whether such migration between lwp's is permitted 
or disallowed.)



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: kaslr: better rng

2017-11-14 Thread Thor Lancelot Simon 
On Tue, Nov 14, 2017 at 02:25:00PM +0100, Maxime Villard wrote:
> Le 11/11/2017 ?? 22:23, Taylor R Campbell a ??crit :
> > Can you just use the SHA1 in libkern (and the SHA3 that will with any
> > luck soon be in libkern), or are there constraints on the size of the
> > prekern that prevent you from doing so?
> 
> No, there are no constraints. I just didn't know we could use libkern. So you
> can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3.
> 
> 
> Le 12/11/2017 ?? 03:13, Thor Lancelot Simon a ??crit :
> > cpu_rng already has the code needed to do this -- best to use it, perhaps?
> 
> This would mean moving cpu_rng into libkern?

Maybe so.  I guess there is MD stuff in libkern already.  Only thing is,
looking at the code to remind myself what I did, it relies on our cpu_features
mechanism.  But if you look at the code, it's very, very simple, just a
few lines really to do the work -- in this very particular case perhaps you
would be justified to duplicate it.

Or -- it's tiny -- grab the Intel sample code examples from
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
which include a tiny CPU feature prober and a little bit of glue around
RDRAND and RDSEED.  You can discard almost all the glue, or even just use
the Intel code (3-clause BSD licensed) as an example of how to probe the
feature bits.

The right thing to do I would think is to is use RDSEED if you have it;
if you don't have it, or if it fails, use RDRAND.  If you don't have either,
I guess use the TSC to key your hash function.  If you don't have that,
the RTC clock... just a few inb()/outb() to read it, and it's better than
nothing.

Here is something else you can use with only a fairly small amount of
MD code -- the processor temperature sensor on most Intel CPUs made since
around 2009.  As you can see from x86/x86/coretemp.c, it's just a couple
of MSR reads - the probe may be the hard part.

-- 
  Thor Lancelot Simont...@panix.com
 "The two most common variations translate as follows:
illegitimi non carborundum = the unlawful are not silicon carbide
illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: amd64: kernel aslr support

2017-11-14 Thread Thor Lancelot Simon 
On Tue, Nov 14, 2017 at 04:04:39PM +, Christos Zoulas wrote:
> In article <5cee5471-dc6f-db16-8914-75ad5ad15...@m00nbsd.net>,
> Maxime Villard   wrote:
> >
> >All of that leaves us with about the most advanced KASLR implementation
> >available out there. There are ways to improve it even more, but you'll have
> >to wait a few weeks for that.
> >
> >If you want to try it out you need to make sure you have the latest versions
> >of GENERIC_KASLR / prekern / bootloader. The instructions are still here [2],
> >and haven't changed.
> 
> Very nicely done!

Seriously!  Nice work!

-- 
  Thor Lancelot Simont...@panix.com
 "The two most common variations translate as follows:
illegitimi non carborundum = the unlawful are not silicon carbide
illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: Debugging function of localcount

2017-11-14 Thread Taylor R Campbell 
> Date: Mon, 13 Nov 2017 13:59:32 +0900
> From: Ryota Ozaki 
> 
> I'm sorry for not replying this thread. I'm back.
> 
> I've revised the patch as your suggestions:
>   http://www.netbsd.org/~ozaki-r/localcount_debug_atomic.revised.diff

Looks better, thanks!

Couple nits:

1. Still need to volatile-qualify lc_refcnt.
2. Either use unsigned and atomic_cas_uint, or uint32_t and
   atomic_cas_32, but not a mixture.

Random thought: What about a per-LWP counter for diagnostics, with
lwp_getspecific/setspecific?  No interprocessor overhead that way.
Could even assert when an lwp exits, or when a softint returns, that
no localcounts were leaked.

(This slightly changes the semantics of localcount so that it cannot
be passed from lwp to lwp (i.e., can't acquire in one and release in
the other; must acquire in both and release in both), but I don't
really see a problem with that.)

Re: amd64: kernel aslr support

2017-11-14 Thread Christos Zoulas 
In article <5cee5471-dc6f-db16-8914-75ad5ad15...@m00nbsd.net>,
Maxime Villard   wrote:
>Le 04/10/2017 à 21:00, Maxime Villard a écrit :
>> Here is a Kernel ASLR implementation for NetBSD-amd64.
>> [...]
>> Known issues:
>>  * Right now, the kernel segments are contiguous. Starting from this
>>implementation, it wouldn't be really difficult to randomize the segments
>>independently - adding gaps between them and changing their order too.
>>Then, we could split the segments themselves in sub-blocks and intertwine
>>them.
>> [...]
>
>So, I did it. Now the kernel sections are split in sub-blocks, and are all
>randomized independently. See my drawing [1].
>
>What it means in practice, is that Kernel ASLR is much more difficult to
>defeat: a cache attack will at most allow you to know that a given range is
>mapped as executable for example, but you don't know which sub-block of .text
>it is; a kernel pointer leak will at most allow you to reconstruct the layout
>of one sub-block, but you don't know the layout and address of the remaining
>blocks, and there can be many.
>
>The size and number of these blocks is controlled by the split-by-file
>parameter in Makefile.amd64. Right now it is set to 2MB, which produces a
>kernel with ~23 allocatable (ie useful at runtime) sections, which is a third
>of the total number supported (BTSPACE_NSEGS = 64). I will probably reduce
>this parameter a bit in the future, to 1.5MB, or even 1MB.
>
>All of that leaves us with about the most advanced KASLR implementation
>available out there. There are ways to improve it even more, but you'll have
>to wait a few weeks for that.
>
>If you want to try it out you need to make sure you have the latest versions
>of GENERIC_KASLR / prekern / bootloader. The instructions are still here [2],
>and haven't changed.

Very nicely done!

christos

Re: amd64: kernel aslr support

2017-11-14 Thread Maxime Villard 

Le 04/10/2017 à 21:00, Maxime Villard a écrit :

Here is a Kernel ASLR implementation for NetBSD-amd64.
[...]
Known issues:
 * Right now, the kernel segments are contiguous. Starting from this
   implementation, it wouldn't be really difficult to randomize the segments
   independently - adding gaps between them and changing their order too.
   Then, we could split the segments themselves in sub-blocks and intertwine
   them.
[...]


So, I did it. Now the kernel sections are split in sub-blocks, and are all
randomized independently. See my drawing [1].

What it means in practice, is that Kernel ASLR is much more difficult to
defeat: a cache attack will at most allow you to know that a given range is
mapped as executable for example, but you don't know which sub-block of .text
it is; a kernel pointer leak will at most allow you to reconstruct the layout
of one sub-block, but you don't know the layout and address of the remaining
blocks, and there can be many.

The size and number of these blocks is controlled by the split-by-file
parameter in Makefile.amd64. Right now it is set to 2MB, which produces a
kernel with ~23 allocatable (ie useful at runtime) sections, which is a third
of the total number supported (BTSPACE_NSEGS = 64). I will probably reduce
this parameter a bit in the future, to 1.5MB, or even 1MB.

All of that leaves us with about the most advanced KASLR implementation
available out there. There are ways to improve it even more, but you'll have
to wait a few weeks for that.

If you want to try it out you need to make sure you have the latest versions
of GENERIC_KASLR / prekern / bootloader. The instructions are still here [2],
and haven't changed.

Maxime

[1] http://mail-index.netbsd.org/source-changes/2017/11/14/msg089697.html
[2] http://m00nbsd.net/542a5cfd448aaf7db7adcadce74123d2.html

Re: kaslr: better rng

2017-11-14 Thread Maxime Villard 

Le 11/11/2017 à 22:23, Taylor R Campbell a écrit :

Can you just use the SHA1 in libkern (and the SHA3 that will with any
luck soon be in libkern), or are there constraints on the size of the
prekern that prevent you from doing so?


No, there are no constraints. I just didn't know we could use libkern. So you
can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3.


Le 12/11/2017 à 03:13, Thor Lancelot Simon a écrit :

cpu_rng already has the code needed to do this -- best to use it, perhaps?


This would mean moving cpu_rng into libkern?