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
status
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 correc
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
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 rende
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 don
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 o
"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
> src/sy
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.
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 security.
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: GENERIC
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 to
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 there's
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 t
> 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 sa
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
> |> KASL
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
>>
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
> >> KASLR
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 to
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
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 a
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 sys
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 k
22 matches
Mail list logo