Re: Missing compat_43 stuff for netbsd32?

2018-09-11 Thread Maxime Villard
Le 11/09/2018 à 10:07, Paul Goyette a écrit : On Tue, 11 Sep 2018, Maxime Villard wrote: Le 11/09/2018 à 09:46, Paul Goyette a écrit : While working on the compat code, I noticed that there are a few old syscalls which are defined in syc/compat/netbsd323/syscalls.master with a type

Re: Missing compat_43 stuff for netbsd32?

2018-09-11 Thread Maxime Villard
Le 11/09/2018 à 09:46, Paul Goyette a écrit : While working on the compat code, I noticed that there are a few old syscalls which are defined in syc/compat/netbsd323/syscalls.master with a type of COMPAT_43, yet there does not exist any compat_netbsd32 implementation as far as I can see...

Re: Too many PMC implementations

2018-08-23 Thread Maxime Villard
Le 23/08/2018 à 17:47, Anders Magnusson a écrit : Den 2018-08-23 kl. 17:03, skrev Maxime Villard: Le 23/08/2018 à 16:28, Anders Magnusson a écrit : Den 2018-08-23 kl. 15:53, skrev Maxime Villard: Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit : On 17.08.2018 17:13, Maxime Villard wrote

Re: Too many PMC implementations

2018-08-23 Thread Maxime Villard
Le 23/08/2018 à 16:28, Anders Magnusson a écrit : Den 2018-08-23 kl. 15:53, skrev Maxime Villard: Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit : On 17.08.2018 17:13, Maxime Villard wrote: Note that I'm talking about the kernel gprof, and not the userland gprof. In terms of kernel profiling

Re: Too many PMC implementations

2018-08-23 Thread Maxime Villard
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit : On 17.08.2018 17:13, Maxime Villard wrote: Note that I'm talking about the kernel gprof, and not the userland gprof. In terms of kernel profiling, it's not nonsensical to say that since we support ARM and x86 in tprof, we can cover 99% of the MI

Re: kasan: monitor pools

2018-08-22 Thread Maxime Villard
Le 21/08/2018 à 14:49, Greg Troxel a écrit : Maxime Villard writes: Here is a patch [1] that allows kasan to monitor pools and pool_caches. We recycle the existing POOL_REDZONE implementation - which I wrote three years ago, and which has never been enabled (not even on DEBUG). With this we

Re: kasan: monitor pools

2018-08-21 Thread Maxime Villard
Le 21/08/2018 à 14:05, Christos Zoulas a écrit : In article <2a4c7cde-ab5e-68b7-de0f-0a307e91a...@m00nbsd.net>, Maxime Villard wrote: Here is a patch [1] that allows kasan to monitor pools and pool_caches. We recycle the existing POOL_REDZONE implementation - which I wrote three yea

kasan: monitor pools

2018-08-21 Thread Maxime Villard
Here is a patch [1] that allows kasan to monitor pools and pool_caches. We recycle the existing POOL_REDZONE implementation - which I wrote three years ago, and which has never been enabled (not even on DEBUG). With this we can detect read/write buffer overflows on all our pools, and in

Re: Too many PMC implementations

2018-08-17 Thread Maxime Villard
Le 17/08/2018 à 16:43, Joerg Sonnenberger a écrit : On Fri, Aug 17, 2018 at 04:20:30PM +0200, Maxime Villard wrote: So no one has any opinion on that? Because in this case I will remove it soon. (Talking about the kernel gprof.) I'm quite reluctant to remove the only sample based profiler we

Re: Too many PMC implementations

2018-08-17 Thread Maxime Villard
Le 10/08/2018 à 11:40, Maxime Villard a écrit : I saw the thread [Re: Sample based profiling] on tech-userlevel@, I'm not subscribed to this list but I'm answering here because it's related to tprof among other things. I agree that it would be better to retire gprof in base, because

Re: Too many PMC implementations

2018-08-10 Thread Maxime Villard
I saw the thread [Re: Sample based profiling] on tech-userlevel@, I'm not subscribed to this list but I'm answering here because it's related to tprof among other things. I agree that it would be better to retire gprof in base, because there are more powerful tools now, and also advanced

Re: To test presence of CVE-2018-6922 ( TCP vulnerability) in NetBSD5.1

2018-08-10 Thread Maxime Villard
Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit : I am trying to test presence of CVE-2018-6922 [...] NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So there is no way this is ever going to be fixed in NetBSD 5. There was a small conversation about the issue

Strange PCI bug

2018-07-31 Thread Maxime Villard
I'm experiencing a strange, but reproducible, bug in PCI. I tried to install NetBSD 8 on two old x86 32bit machines. The hardware is completely different, but they both have an SiS controller. At boot time, they both crash in the first panic of fputrap(). I tried to boot with a -current kernel,

amd64: failed attempt at numa...

2018-07-28 Thread Maxime Villard
... but I'm posting the code in case someone cares. The idea was to duplicate the kernel .text and .rodata sections into each numa node. Also the page tree itself was partly duplicated. The goal was to speed up the instruction fetches and some parts of the VA->PA lookup: now that they were local

Re: Possible error in dtrace

2018-07-27 Thread Maxime Villard
Le 25/07/2018 à 19:56, Siddharth Muralee a écrit : I guess that makes sense. Should I submit a patch for the same as you suggested? I've committed it. But in the end I used VM_MIN_KERNEL_ADDRESS, because the variable being "kernelbase", it was less confusing. I guess we could remove the

Re: Removing dbregs

2018-07-26 Thread Maxime Villard
For the record, I ended up with a functional patch [1]. This removes the reload of DR6/DR7 on each kernel->user transition, and rather does it during context switches, only when dbregs are being used. Tested ATF on i386 and amd64, it works. Kamil wanted to do extra testing, but basically this

Re: Removing dbregs

2018-07-26 Thread Maxime Villard
Le 26/07/2018 à 10:41, Kamil Rytarowski a écrit : On 26.07.2018 09:24, Maxime Villard wrote: For the record, I ended up with a functional patch [1]. This removes the reload of DR6/DR7 on each kernel->user transition, and rather does it during context switches, only when dbregs are being u

Re: Possible error in dtrace

2018-07-25 Thread Maxime Villard
Le 25/07/2018 à 19:33, Siddharth Muralee a écrit : KERN_BASE is used only once in dtrace and no where else - if it indeed is the same as VM_MIN_KERNEL_ADDRESS then we can just substitute it. I didn't understand how VM_MAX_ADDRESS comes there. Instead of taking the kernel min address, you can

Re: Possible error in dtrace

2018-07-25 Thread Maxime Villard
Le 25/07/2018 à 16:09, Kamil Rytarowski a écrit : On 25.07.2018 16:01, Maxime Villard wrote: Le 25/07/2018 à 15:54, Siddharth Muralee a écrit : Hello, While going through sys/arch/amd64/pmap.h, I came across KERN_BASE[1] and confused it for KERNBASE[2]. Looking deeper into the same I

Re: Possible error in dtrace

2018-07-25 Thread Maxime Villard
Le 25/07/2018 à 15:54, Siddharth Muralee a écrit : Hello, While going through sys/arch/amd64/pmap.h, I came across KERN_BASE[1] and confused it for KERNBASE[2]. Looking deeper into the same I think someone made the same mistake in dtrace_isa.c{3](I might be wrong). I compared how

Re: Re-arrange contents of struct cpuinfo - kern/52919

2018-07-15 Thread Maxime Villard
Le 16/07/2018 à 00:27, Paul Goyette a écrit : Since maxv@ has already done some rearranging, but so far has not bumped the system version, I would like to do some more re-arrangement. This will group all the XEN stuff together, as well as move all of the conditional parts of sstruct cpuinfo to

Re: Too many PMC implementations

2018-07-15 Thread Maxime Villard
Le 11/07/2018 à 18:22, Maxime Villard a écrit : Right now we have three (or more?) different implementations for Performance Monitoring Counters: * PMC: this one is MI. It is used only on one ARM model (xscale I think). There used to be an x86 code for it, but it was broken, and I removed

Re: Removing dbregs

2018-07-14 Thread Maxime Villard
Le 14/07/2018 à 17:40, Kamil Rytarowski a écrit : On 14.07.2018 12:52, Maxime Villard wrote: Le 14/07/2018 à 10:29, Martin Husemann a écrit : On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: #ifdefing it out in a non-benchmarking application (I was checking ones that do

Re: Removing dbregs

2018-07-14 Thread Maxime Villard
Le 14/07/2018 à 17:55, Maxime Villard a écrit : Le 14/07/2018 à 17:40, Kamil Rytarowski a écrit : On 14.07.2018 12:52, Maxime Villard wrote: Le 14/07/2018 à 10:29, Martin Husemann a écrit : On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: #ifdefing it out in a non

Re: Removing dbregs

2018-07-14 Thread Maxime Villard
Le 14/07/2018 à 10:29, Martin Husemann a écrit : On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: #ifdefing it out in a non-benchmarking application (I was checking ones that do something with syscalls) is more negligible than 0,3% of overhead in the kernel in a loop. My vote

Re: Removing dbregs

2018-07-13 Thread Maxime Villard
Le 13/07/2018 à 21:54, Kamil Rytarowski a écrit : On 13.07.2018 21:31, Maxime Villard wrote: I don't like the dbregs code. We unconditionally write into %dr6 and %dr7 in userret, that is, during each interruptible kernel->user transition. Some measurements with PMCs show that the loads of

Removing dbregs

2018-07-13 Thread Maxime Villard
I don't like the dbregs code. We unconditionally write into %dr6 and %dr7 in userret, that is, during each interruptible kernel->user transition. Some measurements with PMCs show that the loads of dr6/dr7 are one of the first sources of recovery cycles during a build.sh - the cycles the CPU

Re: Too many PMC implementations

2018-07-12 Thread Maxime Villard
Le 11/07/2018 à 18:22, Maxime Villard a écrit : Right now we have three (or more?) different implementations for Performance Monitoring Counters: * PMC: this one is MI. It is used only on one ARM model (xscale I think). There used to be an x86 code for it, but it was broken, and I removed

Re: Too many PMC implementations

2018-07-12 Thread Maxime Villard
Le 11/07/2018 à 19:49, Kamil Rytarowski a écrit : I'm not familiar with the internals myself, but from API point of view, something usable for porting rr (https://github.com/mozilla/rr) or even Linux perf-top is highly desirable. I treat personally perf-top as a gold standard. Well, yes, but

Too many PMC implementations

2018-07-11 Thread Maxime Villard
Right now we have three (or more?) different implementations for Performance Monitoring Counters: * PMC: this one is MI. It is used only on one ARM model (xscale I think). There used to be an x86 code for it, but it was broken, and I removed it. The implementation comes with libpmc, a

Re: panic in amap_wipeout()

2018-07-10 Thread Maxime Villard
Le 10/07/2018 à 16:44, Edgar Fuß a écrit : So the machine [...] just paniced: It's running 6.1/amd64. You are using NetBSD 6 and IPF; that's about the least bug-free configuration I can think of. Really, you should switch to NetBSD 8 - even if IPF is not maintained at least the rest of the

Re: 8.0 performance issue when running build.sh?

2018-07-10 Thread Maxime Villard
Le 10/07/2018 à 11:01, Martin Husemann a écrit : On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote: I have no scientific data yet, but just noticed that build times on the auto build cluster did rise very dramatically since it has been updated to run NetBSD 8.0 RC2. Since builds

Re: interesting skylake perf tidbit

2018-07-10 Thread Maxime Villard
Le 06/07/2018 à 21:47, Maxime Villard a écrit : I guess we should do both; use "monitor" when possible, and in the places that are still required to use "pause", use a lower BACKOFF_MIN (set at boot time, depending on the cpu model) to compensate for the increased CPU lat

Re: interesting skylake perf tidbit

2018-07-06 Thread Maxime Villard
Le 18/06/2018 à 14:29, m...@netbsd.org a écrit : joerg called it stupid and said we should use monitor, he's probably right. new arm also has a similar thing. The thing is, there are several SPINLOCK_BACKOFF()s that we just can't replace by monitor. For example because we want to measure the

Re: 8.0 performance issue when running build.sh?

2018-07-06 Thread Maxime Villard
Le 06/07/2018 à 16:48, Martin Husemann a écrit : On Fri, Jul 06, 2018 at 04:40:48PM +0200, Maxime Villard wrote: This are all successfull builds of HEAD for alpha that happened after June 1: What does that mean, are you building something *on* an Alpha CPU, or are you building the Alpha port

Re: workaround intel apollo lake errata

2018-07-01 Thread Maxime Villard
Le 01/07/2018 à 10:39, co...@sdf.org a écrit : Hi, Currently Apollo Lake CPUs fail to boot with SMP enabled.[1] This is because we use MONITOR/MWAIT with interrupts disabled for waiting for secondary CPUs to hatch. Errata means the wakeup doesn't happen.[2] I've written the attached patch, and

Re: e_trapsignal removal

2018-05-01 Thread Maxime Villard
Le 27/04/2018 à 21:28, Kamil Rytarowski a écrit : On 27.04.2018 21:11, Christos Zoulas wrote: In article , Kamil Rytarowski wrote: -=-=-=-=-=- -=-=-=-=-=- I propose to remove e_trapsignal from the compat framework Rationale: -

Re: secmodel_securelevel(9) and machdep.svs.enabled

2018-04-25 Thread Maxime Villard
Le 25/04/2018 à 19:47, Alexander Nasonov a écrit : Alexander Nasonov wrote: Alexander Nasonov wrote: When securelevel is set, should be lock 1->0 change for machdep.svs.enabled (and possibly for other sysctls related to recent security mitigations)? Can I commit the attached patch? (doc

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

2018-04-03 Thread Maxime Villard
Le 02/04/2018 à 21:28, Jaromír Doleček a écrit : 2018-03-31 13:42 GMT+02:00 Jaromír Doleček : 2018-03-25 17:27 GMT+02:00 Joerg Sonnenberger : Yeah, that's what ephemeral mappings where supposed to be for. The other question is whether we can't just use

Re: Build problem with latest locore.S

2018-03-30 Thread Maxime Villard
Le 30/03/2018 à 11:53, Paul Goyette a écrit : Hmmm, it seems there was also a compile-time warning on locore.S which was not treated as fatal... In file included from ./xen/xen-public/arch-x86/xen.h:61:0, from ./xen/xen-public/xen.h:34, from

Re: Build problem with latest locore.S

2018-03-30 Thread Maxime Villard
Le 30/03/2018 à 11:43, Paul Goyette a écrit : With the latest locore.S I am seeing the following error: # link INSTALL_XEN3_DOMU/netbsd /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020 -e start -X -o netbsd

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

2018-03-25 Thread Maxime Villard
Le 25/03/2018 à 17:03, Michael van Elst a écrit : On Sun, Mar 25, 2018 at 03:39:21PM +0200, Maxime Villard wrote: The main cpu (on which your program executes) sends IPIs to remote cpus, these cpus were idle and entered the halted state, and they take some time to wake up and process the IPI

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

2018-03-25 Thread Maxime Villard
Le 25/03/2018 à 17:27, Joerg Sonnenberger a écrit : On Sun, Mar 25, 2018 at 03:19:28PM -, Michael van Elst wrote: jo...@bec.de (Joerg Sonnenberger) writes: What about having a passive unmap as fourth option? I.e. when unmapping in the transfer map, just add them to a FIFO. Process the

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

2018-03-25 Thread Maxime Villard
Le 25/03/2018 à 13:48, Michael van Elst a écrit : jaromir.dole...@gmail.com (=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?=) writes: The problem there is that FFS triggers a pathologic case. I/O transfer maps and then unmaps each block into kernel pmap, so that the data could be copied into user memory.

Re: compat code being included in non-compat kernels?

2018-03-05 Thread Maxime Villard
Le 05/03/2018 à 11:43, Paul Goyette a écrit : (Unicast, but feel free to share.) I wonder if, for now, it would make sense just to add compat_mod.c to the libcompat.o object? That would "register" the included code, and other modules which already depend on the compat module (such as the

Re: compat code being included in non-compat kernels?

2018-03-05 Thread Maxime Villard
Le 05/03/2018 à 11:02, Paul Goyette a écrit : I've notice an anomaly on which I hope someone can shed some light... For some time now I've noticed that periodically something triggers the "load all the exec modules on the off chance that it will let me exec this image" - the code is function

Re: Enabling SVS by default

2018-02-26 Thread Maxime Villard
Le 22/02/2018 à 21:14, Maxime Villard a écrit : Hi, I intend to enable SVS by default soon. [...] I've enabled it. Maxime

Re: Enabling SVS by default

2018-02-23 Thread Maxime Villard
Le 23/02/2018 à 10:45, Edgar Fuß a écrit : MV> A sysctl is now available, machdep.svs_enabled EF> Why svs_enabled and not simply svs? MV> Because that's the common naming convention? The name of the sysctl entry MV> matches the name of the associated kernel variable. What I meant is: $ sysctl -a

Re: gcc: optimizations, and stack traces

2018-02-23 Thread Maxime Villard
Le 18/02/2018 à 21:37, Maxime Villard a écrit : Le 11/02/2018 à 12:04, Krister Walfridsson a écrit : On Sun, Feb 11, 2018 at 9:11 AM, Maxime Villard <m...@m00nbsd.net> wrote: [...] we need to find a way to tell GCC to always push the frame at the beginning of the functions. This i

Re: Enabling SVS by default

2018-02-22 Thread Maxime Villard
Le 22/02/2018 à 21:53, Edgar Fuß a écrit : A sysctl is now available, machdep.svs_enabled Why svs_enabled and not simply svs? Because that's the common naming convention? The name of the sysctl entry matches the name of the associated kernel variable. In case you intend to add more

Enabling SVS by default

2018-02-22 Thread Maxime Villard
Hi, I intend to enable SVS by default soon. This will be done by uncommenting this line in GENERIC: #optionsSVS # Separate Virtual Space When SVS is compiled, it is automatically turned off at boot time if the CPU vendor is not Intel. That is to say, if you use AMD,

Re: gcc: optimizations, and stack traces

2018-02-18 Thread Maxime Villard
Le 11/02/2018 à 12:04, Krister Walfridsson a écrit : On Sun, Feb 11, 2018 at 9:11 AM, Maxime Villard <m...@m00nbsd.net> wrote: [...] we need to find a way to tell GCC to always push the frame at the beginning of the functions. This is done by passing the -fno-shrink-wrap flag

Re: gcc: optimizations, and stack traces

2018-02-11 Thread Maxime Villard
Le 09/02/2018 à 13:32, Joerg Sonnenberger a écrit : On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote: It implies that if a bug occurs _before_ these two instructions are executed, we have a %rbp that points to the _previous_ function, the one we got called from. And therefore, GDB

Re: gcc: optimizations, and stack traces

2018-02-09 Thread Maxime Villard
Le 09/02/2018 à 13:32, Joerg Sonnenberger a écrit : On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote: It implies that if a bug occurs _before_ these two instructions are executed, we have a %rbp that points to the _previous_ function, the one we got called from. And therefore, GDB

Re: gcc: optimizations, and stack traces

2018-02-09 Thread Maxime Villard
Le 09/02/2018 à 12:13, Valery Ushakov a écrit : [Summoning Krister] On Fri, Feb 09, 2018 at 11:23:17 +0100, Maxime Villard wrote: There are also several cases where functions in the call tree can disappear from the backtrace. In the following call tree: A -> B -> C -> D

Re: gcc: optimizations, and stack traces

2018-02-09 Thread Maxime Villard
Le 09/02/2018 à 12:08, Valery Ushakov a écrit : On Fri, Feb 09, 2018 at 11:38:47 +0100, Martin Husemann wrote: On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote: When I spotted this several months ago (while developing Live Kernel ASLR), I tried to look for GCC options that say

gcc: optimizations, and stack traces

2018-02-09 Thread Maxime Villard
An issue I spotted a few months ago, but PR/52560 just reminded me about it. Basically, in order to get a backtrace, GDB reads the %rbp register. At the beginning of each function, GCC inserts the two following instructions: pushq %rbp movq%rsp,%rbp Therefore, at any

Re: T_TRCTRAP handling

2018-02-07 Thread Maxime Villard
Le 07/02/2018 à 10:37, Dimitris Karagkasidis a écrit : Hello, Currently, the handling of the Trace trap on amd64 and i386 architectures is problematic under certain conditions. More specifically, on kernels compiled without DDB and KGDB support, Trace traps within supervisor mode result in

Re: amd64: kernel aslr support

2018-01-21 Thread Maxime Villard
Le 17/01/2018 à 21:48, Thomas Klausner a écrit : On Wed, Jan 17, 2018 at 08:01:19AM +0100, Maxime Villard wrote: Why does GENERIC_KASLR disable KDTRACE_HOOKS? Is this necessary, or are KDTRACE_HOOKS lowering the security somehow? In fact, it's because KDTRACE_HOOKS wants to parse one CTF

Current state of SVS and Meltdown

2018-01-21 Thread Maxime Villard
I committed this morning the last part needed to completely mitigate Meltdown on NetBSD-amd64. As I said in the commit message, we still need to change a few things for KASLR - there is some address leakage, we need to hide one instruction -, but otherwise the implementation should be perfectly

Re: /dev/ksyms permissions

2018-01-21 Thread Maxime Villard
Le 18/01/2018 à 13:43, Tom Ivar Helbekkmo a écrit : Maxime Villard <m...@m00nbsd.net> writes: Well, looking at the code, it seems to me that _kvm_open() should be changed to keep /dev/ksyms open, the same way it keeps /dev/kmem open. Agreed. This works fine for me, with and withou

Re: /dev/ksyms permissions

2018-01-18 Thread Maxime Villard
Le 18/01/2018 à 11:03, Tom Ivar Helbekkmo a écrit : Maxime Villard <m...@m00nbsd.net> writes: So, making /dev/ksyms 440 root:kmem should not break anything. If it does, then there's a bug in the offending tool in the first place. Agreed. systat is one of them. It takes care t

Re: /dev/ksyms permissions

2018-01-18 Thread Maxime Villard
Le 17/01/2018 à 21:43, Anders Magnusson a écrit : Den 2018-01-17 kl. 20:20, skrev Mouse: Maybe group kmem read, but that might require more elevated privileges in the programs that uses ksyms. What program uses ksyms now that doesn't require at least group kmem? You cannot give up kmem read

Re: amd64: kernel aslr support

2018-01-16 Thread Maxime Villard
Le 16/01/2018 à 23:54, Thomas Klausner a écrit : Hi! On Wed, Nov 15, 2017 at 07:40:55PM +0100, Maxime Villard wrote: Le 14/11/2017 à 15:43, Maxime Villard a écrit : 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

Re: amd64: svs

2018-01-13 Thread Maxime Villard
Le 11/01/2018 à 20:14, Jaromír Doleček a écrit : 2018-01-10 19:56 GMT+01:00 Maxime Villard <m...@m00nbsd.net <mailto:m...@m00nbsd.net>>: > That's what we do, too. Doing this is faster than "unmapping the kernel pages > on return to user space". > > Swi

svs: unmap pmap_kernel

2018-01-12 Thread Maxime Villard
Here is a patch [1] that removes pmap_kernel from userland. The idea may be a bit difficult to grasp, so I'll just draw the big picture. Unmapping pmap_kernel from userland is a complicated business for several reasons. The two main reasons are: (1) The kernel stack needs to be mapped in

Re: amd64: svs

2018-01-10 Thread Maxime Villard
Le 09/01/2018 à 21:23, Jaromír Doleček a écrit : 2018-01-08 10:24 GMT+01:00 Maxime Villard <m...@m00nbsd.net <mailto:m...@m00nbsd.net>>: > As far as SVS is concerned, it is not needed: each time an L4 slot is added > (pmap_get_ptp) or removed (pmap_free_ptp), SVS only

Re: amd64: svs

2018-01-08 Thread Maxime Villard
Le 08/01/2018 à 07:33, m...@netbsd.org a écrit : #if defined(XEN) pmap_tlb_shootnow(); #endif does that need to be defined(XEN) || defined(SVS) now? Actually I didn't understand why XEN had this #ifdef in the first place. As far as SVS is concerned, it is not needed: each

Re: amd64: svs

2018-01-07 Thread Maxime Villard
Le 07/01/2018 à 19:04, Jaromír Doleček a écrit : BTW Maxime, I've updated https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention to note your work on NetBSD support for SMAP and SMEP. Would it be feasible to get SMAP support pulled up to netbsd-8 by chance? That's not related to SVS,

Re: amd64: svs

2018-01-07 Thread Maxime Villard
Le 07/01/2018 à 18:22, Kamil Rytarowski a écrit : On 07.01.2018 18:13, m...@netbsd.org wrote: It will be good to document somewhere why SVS exists. it's obvious now, but it might not be in a decade. Thanks for working on this! I expect that we are now required to pullup it to stable

Re: amd64: svs

2018-01-07 Thread Maxime Villard
Le 07/01/2018 à 11:05, Maxime Villard a écrit : Le 06/01/2018 à 16:03, cl...@csel.org a écrit : Runtime detection and configuration is desired as the Linux did, rather than fixed compile-time option. It would be nice, but it is more complicated than it seems. We would have to hotpatch

Re: amd64: svs

2018-01-07 Thread Maxime Villard
Le 06/01/2018 à 16:03, cl...@csel.org a écrit : Runtime detection and configuration is desired as the Linux did, rather than fixed compile-time option. It would be nice, but it is more complicated than it seems. We would have to hotpatch the entry points, and to do that we need a way to

amd64: svs

2018-01-06 Thread Maxime Villard
Here is an implementation that isolates the user and kernel virtual spaces on amd64 [1] - SVS, for Separate Virtual Space. It is incomplete, but it's a functional first shot. The goal is to unmap the kernel when running in usermode. To achieve that, we create a per-cpu L4 page, which contains

Re: modstat and kaslr

2018-01-01 Thread Maxime Villard
Le 01/01/2018 à 02:17, John Nemeth a écrit : On Dec 31, 5:11pm, Maxime Villard wrote: } } Here is a patch [1] that hides the addresses of the kernel modules when } 'modstat -k' is entered by an unprivileged user. The current behavior is } preserved for root. } } The addresses currently leaked

modstat and kaslr

2017-12-31 Thread Maxime Villard
Hi, Here is a patch [1] that hides the addresses of the kernel modules when 'modstat -k' is entered by an unprivileged user. The current behavior is preserved for root. The addresses currently leaked cannot be used to reconstruct the layout of the kernel, since the module VAs are embedded in

Re: untangling the compat mess

2017-12-08 Thread Maxime Villard
Le 06/12/2017 à 21:23, matthew green a écrit : kernel libraries are supposed to be built as a .o not a .a, for modular/lkm kernels. did this get lost some where? libcompat is a .a, I saw that too ie, if you have a MODULAR kernel, then the build should always include all the library stuff,

untangling the compat mess

2017-12-05 Thread Maxime Villard
After investigating a dependency issue that got me highly confused the other day, I've ended up with an implementation that partly untangles the compat mess. The result is not excellent, but it already improves the situation. Currently, the common compat functions located in compat/common/* are

Re: amd64: kernel aslr support

2017-11-15 Thread Maxime Villard
Le 14/11/2017 à 15:43, Maxime Villard a écrit : 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

Re: kaslr: better rng

2017-11-15 Thread Maxime Villard
Le 14/11/2017 à 19:33, Thor Lancelot Simon a écrit : 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

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

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

Re: kaslr: better rng

2017-11-11 Thread Maxime Villard
Le 11/11/2017 à 20:14, Taylor R Campbell a écrit : If we _both_ reveal y = H(x) for some initial secret x, and then use y as the new secret, we've just revealed the new secret. The hash of y against rdtsc and rdseed is the new secret, not just y. It's not a recurrent Yn+1 = H(Yn) construction

Re: kaslr: better rng

2017-11-11 Thread Maxime Villard
Following a conversation with Taylor, I ended up with the following implementation for the prekern [1] [2]. It uses a set of seeds that are hashed together in rounds, and it doesn't use an additional file. It is based on the SHAKE256 hash function, which can produce a variable sized output. We

Re: kaslr: better rng

2017-11-08 Thread Maxime Villard
Le 08/11/2017 à 18:17, Maxime Villard a écrit : Le 08/11/2017 à 17:37, Taylor R Campbell a écrit : Date: Wed, 8 Nov 2017 17:08:42 +0100 From: Maxime Villard <m...@m00nbsd.net> Ah alright. But in my mail (that you were answering to) I did understand that the entropy file comes from the pr

Re: kaslr: better rng

2017-11-08 Thread Maxime Villard
Le 08/11/2017 à 17:37, Taylor R Campbell a écrit : Date: Wed, 8 Nov 2017 17:08:42 +0100 From: Maxime Villard <m...@m00nbsd.net> Ah alright. But in my mail (that you were answering to) I did understand that the entropy file comes from the previous run; what I was saying was, I would

Re: kaslr: better rng

2017-11-08 Thread Maxime Villard
Le 07/11/2017 à 17:21, Taylor R Campbell a écrit : Date: Tue, 7 Nov 2017 09:16:25 +0100 From: Maxime Villard <m...@m00nbsd.net> Le 06/11/2017 à 19:47, Taylor R Campbell a écrit : The entropy file is supposed to be rewritten each time it's read, and on shutdown, or something like that.

Re: kaslr: better rng

2017-11-07 Thread Maxime Villard
different files. Le 07/11/2017 à 03:50, Thor Lancelot Simon a écrit : On Mon, Nov 06, 2017 at 06:51:33PM +0100, Maxime Villard wrote: What is the reason for using only part of the file, in any application? I meant to say that the components don't take random values from the same area

Re: kaslr: better rng

2017-11-06 Thread Maxime Villard
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 used in the bootloader, in the prekern and in the kernel (early). I would like to use

Re: kaslr: better rng

2017-11-06 Thread Maxime Villard
Le 06/11/2017 à 18:35, Taylor R Campbell a écrit : Date: Mon, 6 Nov 2017 07:30:35 +0100 From: Maxime Villard <m...@m00nbsd.net> I would like to use a system similar to the /var/db/entropy-file implementation. That is to say, when running the system generates /var/db/random-file, which

kaslr: better rng

2017-11-05 Thread Maxime Villard
I'm in a point where I need to have a better rng before continuing - and an rng that can be used in the bootloader, in the prekern and in the kernel (early). I would like to use a system similar to the /var/db/entropy-file implementation. That is to say, when running the system generates

Re: kmodule: absolute symbols

2017-11-02 Thread Maxime Villard
Le 02/11/2017 à 18:41, Christos Zoulas a écrit : In article , Christos Zoulas wrote: (note: we've always had this issue, so what, no one has ever tried to modload COMPAT_16 on amd64?) I would declare getval_unlocked as taking void

kmodule: absolute symbols

2017-11-02 Thread Maxime Villard
Throwing this here in case someone cares. In the kernel module relocator we don't support absolute symbols coming from the kernel, and it means that we can't modload a module containing for example: extern char sigcode[]; printf("sigcode = %p\n", sigcode); Currently, absolute

Re: amd64: kernel aslr support

2017-10-10 Thread Maxime Villard
Le 07/10/2017 à 21:29, Valery Ushakov a écrit : On Sat, Oct 07, 2017 at 20:42:58 +0200, Maxime Villard wrote: Le 04/10/2017 ? 21:00, Maxime Villard a ?crit : Here is a Kernel ASLR implementation for NetBSD-amd64. [...] Known issues: [...] * There are several redefinitions in the prekern

Re: amd64: kernel aslr support

2017-10-07 Thread Maxime Villard
Le 04/10/2017 à 21:00, Maxime Villard a écrit : Here is a Kernel ASLR implementation for NetBSD-amd64. [...] Known issues: [...] * There are several redefinitions in the prekern headers. The way to remove them depends on where we put the prekern in the source tree. Does someone have

Re: amd64: kernel aslr support

2017-10-06 Thread Maxime Villard
Le 06/10/2017 à 08:19, Martin Husemann a écrit : On Thu, Oct 05, 2017 at 12:56:02PM +0200, Maxime Villard wrote: I don't think it is possible to compile some parts as relocatable and some others as static. What we could do is compile both the kernel and the prekern separately, and use objcopy

Re: amd64: kernel aslr support

2017-10-06 Thread Maxime Villard
Le 06/10/2017 à 10:37, Martin Husemann a écrit : I don't get the issue with the bootloader - it just loads one binary and doesn't care about ASLR, the "prekernel" entry point handles that later (rearranging any mappings the bootloader might have previously done afterwards)? The bootloader

Re: amd64: kernel aslr support

2017-10-06 Thread Maxime Villard
Le 06/10/2017 à 02:30, Thor Lancelot Simon a écrit : * The RNG is not really strong. Help in this area would be greatly appreciated. This is tricky mostly because once you start probing for hardware devices or even CPU features, you're going to find yourself wanting more and more of the

Re: amd64: kernel aslr support

2017-10-06 Thread Maxime Villard
Le 05/10/2017 à 17:39, Mouse a écrit : Is live-kernel update more viable with this approach? Live kernel update is a much more complicated business, [...] I didn't write that the bit about live-kernel updates, but it occurs to me that it could have been intended to refer not to updating the

Re: amd64: kernel aslr support

2017-10-05 Thread Maxime Villard
Le 05/10/2017 à 14:59, Kamil Rytarowski a écrit : On 05.10.2017 12:56, Maxime Villard wrote: The advantage of having a separate prekern is that you can update the kernel without touching the prekern, or the other way around. Is live-kernel update more viable with this approach? It's

Re: amd64: kernel aslr support

2017-10-05 Thread Maxime Villard
Le 05/10/2017 à 09:12, Martin Husemann a écrit : On Wed, Oct 04, 2017 at 09:00:50PM +0200, Maxime Villard wrote: This implementation is based on a specialized kernel, called the prekern, which relocates the real NetBSD kernel. The bootloader loads both the prekern and the kernel in memory

  1   2   3   >