Re: CVS commit: src/sys/kern

2018-12-03 Thread Robert Elz
Date:Mon, 3 Dec 2018 15:30:35 +0100 From:Maxime Villard Message-ID: <03e1d0b4-d6b9-5f45-4770-ee6b161b8...@m00nbsd.net> | It shouldn't be hard to open new sysctls that don't leak stuff. You really should stop using biased terminology. Of course we don't want the

Re: CVS commit: src/sys/kern

2018-12-03 Thread Maxime Villard
Le 03/12/2018 à 15:24, matthew green a écrit : the broken kvm tools which ones? this level of security None of Linux, Windows, MacOS and more accept to leak pointers; it is not a high level, it is a basic level. And no, this change shouldn't stay as-is. It shouldn't be hard to open new

re: CVS commit: src/sys/kern

2018-12-03 Thread Christos Zoulas
On Dec 4, 10:20am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/kern | i just had an idea about a relatively simple hack to allow | kvm tools to work sanely in kaslr space, even if they're not | fully converted yet. | | a secmodel overlay that has a way to allow

re: CVS commit: src/sys/kern

2018-12-03 Thread matthew green
i just had an idea about a relatively simple hack to allow kvm tools to work sanely in kaslr space, even if they're not fully converted yet. a secmodel overlay that has a way to allow a uid/gid combo to retrieve the addresses, not just root, and then have that combo set to */kvm. then, kvm tools

re: CVS commit: src/sys/kern

2018-12-03 Thread matthew green
Maxime Villard writes: > > the broken kvm tools > > which ones? fstat for a start. > > this level of security > > None of Linux, Windows, MacOS and more accept to leak pointers; it is not > a high level, it is a basic level. > > And no, this change shouldn't stay as-is. It shouldn't be hard

Re: CVS commit: src/sys/kern

2018-12-03 Thread Manuel Bouyer
On Mon, Dec 03, 2018 at 07:27:11PM +, Christos Zoulas wrote: > In article <20181203183537.ga1...@antioche.eu.org>, > Manuel Bouyer wrote: > >On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: > >> In other words, 80% of KASLR is enabled by default, regardless of #ifdef > >>

Re: CVS commit: src/sys/kern

2018-12-03 Thread Christos Zoulas
In article <6c2b4529-2f69-4b94-a580-a7b85057c...@me.com>, Jason Thorpe wrote: > > >> On Dec 3, 2018, at 11:27 AM, Christos Zoulas wrote: >> >> I don't think that the things that KASLR randomizes by default are useful >> to debugging. I.e. you can't depend on two successive kernel crashes to >>

Re: CVS commit: src/sys/kern

2018-12-03 Thread Christos Zoulas
In article <20181203191043.zou-_%stef...@sdaoden.eu>, Steffen Nurpmeso wrote: >Manuel Bouyer wrote in <20181203183537.ga1...@antioche.eu.org>: > |On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: > |> In other words, 80% of KASLR is enabled by default, regardless of #ifdef > |>

Re: CVS commit: src/sys/kern

2018-12-03 Thread Jason Thorpe
> On Dec 3, 2018, at 11:27 AM, Christos Zoulas wrote: > > I don't think that the things that KASLR randomizes by default are useful > to debugging. I.e. you can't depend on two successive kernel crashes to > have identical PTE addresses; OTOH you can depend that the text addresses > are the

Re: CVS commit: src/sys/kern

2018-12-03 Thread Christos Zoulas
In article <20181203183537.ga1...@antioche.eu.org>, Manuel Bouyer wrote: >On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: >> In other words, 80% of KASLR is enabled by default, regardless of #ifdef >> KASLR. Therefore, it is wrong to add an ifdef, because in either case we > >So

Re: CVS commit: src/sys/kern

2018-12-03 Thread Steffen Nurpmeso
Manuel Bouyer wrote in <20181203183537.ga1...@antioche.eu.org>: |On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: |> In other words, 80% of KASLR is enabled by default, regardless of #ifdef |> KASLR. Therefore, it is wrong to add an ifdef, because in either case we | |So

Re: CVS commit: src/sys/kern

2018-12-03 Thread Manuel Bouyer
On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: > In other words, 80% of KASLR is enabled by default, regardless of #ifdef > KASLR. Therefore, it is wrong to add an ifdef, because in either case we So there's no way to completely disable KASLR now ? Although I admit it's usefull

Re: CVS commit: src

2018-12-03 Thread Christos Zoulas
In article <27289.1543846...@splode.eterna.com.au>, matthew green wrote: >"Maxime Villard" writes: >> Module Name: src >> Committed By:maxv >> Date:Sun Dec 2 21:00:13 UTC 2018 >> >> Modified Files: >> src/share/mk: bsd.sys.mk >> src/sys/arch/amd64/conf:

Re: CVS commit: src/sys/kern

2018-12-03 Thread Christos Zoulas
In article <24368.1543847...@splode.eterna.com.au>, matthew green wrote: >until all the broken kvm tools are fixed this change really >must stay as-is. if someone truly wants this level of >security they can choose it, but it's not OK to break basic >features by default in the name of

re: CVS commit: src/sys/kern

2018-12-03 Thread matthew green
until all the broken kvm tools are fixed this change really must stay as-is. if someone truly wants this level of security they can choose it, but it's not OK to break basic features by default in the name of security. .mrg.

re: CVS commit: src

2018-12-03 Thread matthew green
"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Sun Dec 2 21:00:13 UTC 2018 > > Modified Files: > src/share/mk: bsd.sys.mk > src/sys/arch/amd64/conf: GENERIC > src/sys/arch/amd64/include: param.h > src/sys/conf: files ssp.mk >

Re: CVS commit: src/sys/kern

2018-12-03 Thread Maxime Villard
Le 03/12/2018 à 13:07, Martin Husemann a écrit : On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: In other words, 80% of KASLR is enabled by default, regardless of #ifdef KASLR. I'd call that a bug. No, it's a basic level of security. It is also the best randomization of all

Re: CVS commit: src/sys/kern

2018-12-03 Thread Martin Husemann
On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: > In other words, 80% of KASLR is enabled by default, regardless of #ifdef > KASLR. I'd call that a bug. > Therefore, it is wrong to add an ifdef, because in either case we > don't want unpriv to retrieve kernel addresses. And we

Re: CVS commit: src/sys/kern

2018-12-03 Thread Maxime Villard
Le 03/12/2018 à 11:49, Martin Husemann a écrit : On Mon, Dec 03, 2018 at 06:39:18AM +0100, Maxime Villard wrote: This is bad. GENERIC already has some KASLR enabled by default [1], and with your change you're rendering that useless. Please revert. Please describe in more details how this

Re: CVS commit: src/bin/sh

2018-12-03 Thread Robert Elz
Date:Mon, 3 Dec 2018 10:53:29 + From:"Martin Husemann" Message-ID: <20181203105329.45433f...@cvs.netbsd.org> | Log Message: | Make pendingsigs forward declaration match the definition. Grunge, sorry about that - I assume that's what went wrong with the alpha

Re: CVS commit: src/sys/kern

2018-12-03 Thread Martin Husemann
On Mon, Dec 03, 2018 at 06:39:18AM +0100, Maxime Villard wrote: > This is bad. GENERIC already has some KASLR enabled by default [1], and > with your change you're rendering that useless. Please revert. Please describe in more details how this renders something useless, if I read the change

Re: CVS commit: src/sys/kern

2018-12-03 Thread Maxime Villard
Le 03/12/2018 à 01:11, Christos Zoulas a écrit : Module Name:src Committed By: christos Date: Mon Dec 3 00:11:02 UTC 2018 Modified Files: src/sys/kern: files.kern init_sysctl.c Log Message: Expose addresses depending on the KASLR setting (from mrg@). Restores the