Re: CVS commit: src/sys/arch/x86/x86

[Maxime Villard]

Le 03/10/2017 à 22:47, Alexander Nasonov a écrit :

Maxime Villard wrote:

In case you didn't notice, this sysctl results directly from the answers I
got, and is not my original plan (about which I changed my mind as a
consequence of the conversation). So now tell me exactly which point I didn't
consider and which reply I ignored. The thread is here?[1], go ahead, I'm
watching you.

[1] https://marc.info/?l=netbsd-tech-kern=149071535930695=2


Some people (including me) wanted more granular control. Your sysctl
doesn't give such control.


You replied two times in this thread.

https://marc.info/?l=netbsd-tech-kern=149074135206958=2
https://marc.info/?l=netbsd-tech-kern=149133012012784=2

In the first mail, you said that it was better to have a all-or-nothing
sysctl, which is *exactly* what I just committed. In the second one, as a
reply to me, you were indeed talking about more granular control -- but with
vdso, which we don't have, so it's basically not doable.

Maxime

(PS: there is no point in having it done in a note section either, since
unpriv user can still create a binary with rdtsc enabled and side channel
the kernel.)

Re: CVS commit: src/sys/arch/x86/x86

[Alexander Nasonov]

Maxime Villard wrote:
> In case you didn't notice, this sysctl results directly from the answers I
> got, and is not my original plan (about which I changed my mind as a
> consequence of the conversation). So now tell me exactly which point I didn't
> consider and which reply I ignored. The thread is here?[1], go ahead, I'm
> watching you.
> 
> [1] https://marc.info/?l=netbsd-tech-kern=149071535930695=2

Some people (including me) wanted more granular control. Your sysctl
doesn't give such control.

-- 
Alex

Re: CVS commit: src/sys/arch/x86/x86

[maya]

If pax mprotect is an example then maxv should just go around rm -rf'ing
any parts of the tree he doesn't like without even checking that the
kernel builds afterwards, since that's the way we do things around here.

It was months until I could run meld again, even disabling it for just
python was frowned upon. I don't see a bikeshed to discuss turning it on
on tech-kern, it was just done with zero preparation for anything in
pkgsrc and with no discussion whatsoever.

Re: CVS commit: src/sys/arch/x86/x86

[Maxime Villard]

Le 03/10/2017 à 21:14, Joerg Sonnenberger a écrit :

I'm not responding to this nonsensical thread anymore, everything got told
months ago. The option is here, people don't need to give a damn about it
unless they explicitly want to - which is still legitimate in some cases,
including for kaslr, whether it pleases you or not. There are plenty of
useless sysctls to complain about if you like.


Funny. You've been ignoring the replies you got month ago, so of course
there is nothing new to discuss. Frankly, I don't find that acceptable
behavior.


The stupidity of emails like that is the real funny thing here. I don't see
any point in such conversations, but since throwing shit at the fan is the
only thing you find useful (and so do I apparently), let's continue.

In case you didn't notice, this sysctl results directly from the answers I
got, and is not my original plan (about which I changed my mind as a
consequence of the conversation). So now tell me exactly which point I didn't
consider and which reply I ignored. The thread is here [1], go ahead, I'm
watching you.

[1] https://marc.info/?l=netbsd-tech-kern=149071535930695=2

Re: CVS commit: src/sys/arch/x86/x86

[Joerg Sonnenberger]

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote:
> Just like disabling va0 or enabling PaX mprotect; if you feel like these are
> no issues, then what's the fuss. You would be well served to read the "rdtsc
> is still enabled by default" part of my email.

Disabling va0 is low impact. Enabling PaX mprotect by default is far
from it. It doesn't help that again the set of people enforcing this
policies and the set of people that work on actually fixing the fallout
is wildly disjunct.

> I'm not responding to this nonsensical thread anymore, everything got told
> months ago. The option is here, people don't need to give a damn about it
> unless they explicitly want to - which is still legitimate in some cases,
> including for kaslr, whether it pleases you or not. There are plenty of
> useless sysctls to complain about if you like.

Funny. You've been ignoring the replies you got month ago, so of course
there is nothing new to discuss. Frankly, I don't find that acceptable
behavior.

Joerg

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Mon, Oct 2, 2017 at 4:09 PM, Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:

> > Date: Mon, 2 Oct 2017 21:42:11 +0200
> > From: Joerg Sonnenberger 
> >
> > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote:
> > > Add a machdep.tsc_user_enable sysctl, to enable/disable the rdtsc
> > > instruction in usermode. It defaults to enabled.
> >
> > Do we really need this change? I've said it before, I consider this a
> > really stupid idea and effectively useless complexity. rdtsc is not
> > necessary for precision measurement as long as an attacker is willing to
> > waste CPU time, i.e. having one core spinning incrementing a counter and
> > reading that one of a second core will give fairly accurate measurements
> > as long as both cores are near each other. It's normally not that
> > difficult to ensure that.
>
> Concur.  The way to thwart timing side channel attacks is not to
> pretend attackers don't have stop-watches; it's to avoid the variable
> timing that creates the side channels in the first place.
>

Even if you don't have the ability to change the defective hardware?

Why should I provide an attacker a stop watch? I want him/her to build
their own that has the potential to be accurate enough, but is necessarily
less accurate than the one I'm denying them access to.

Warner

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger  wrote:

> On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote:
> > Even if you don't have the ability to change the defective hardware?
>
> The hardware is not defective. We are not talking about variable timing
> for basic arithmetic operations based on the operand value. Outside
> maybe division, that could be considered a hardware bug. A believe
> that timing of complex operations like memory access should be constant
> is IMO completely misguided for general purpose computing. Outside a
> very narrow range of hardware, it is absurd to even consider it.


On other processors, the issues are needing to do timing attacks due to
flaws in the hardware. For x86, no such bugs are known. History suggests it
is unwise to take the absence of evidence to be evidence of absence

> Why should I provide an attacker a stop watch? I want him/her to build
> > their own that has the potential to be accurate enough, but is
> necessarily
> > less accurate than the one I'm denying them access to.
>
> It has been said before: this is breaking completely valid use cases
> without actually fixing anything. It is security by obscurity at its
> best.
>

I'm not advocating turning it off by default. I'm saying that it would be
useful to allow removal of access to the counter as a mitigation technique,
perhaps while waiting for a more general / complete fix for a kernel bug to
be available.

Warner

Re: CVS commit: src/sys/arch/x86/x86

[David Holland]

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote:
 > I'm not responding to this nonsensical thread anymore,

The problem is, you keep acting unilaterally without having gathered a
consensus, then ignoring the resulting objections and demanding to
have everything your way and only your way.

Your ideas about how to proceed (about this or any of the other recent
issues) are not the only possible correct ways forward.

(Obviously, mine are.)

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys

[Manuel Bouyer]

On Tue, Oct 03, 2017 at 07:53:41PM +0200, Kamil Rytarowski wrote:
> For a server or a product I wouldn't want to run such executables and I
> would use SECURE or HIGHLY-SECURE mode.

This is why for servers I rebuild a kernel with only what I need
(and in term of hardware drivers too).
And of course there's no MODULAR here.

Much better than disabling random features which may, or may not, be the
next security issue.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 03.10.2017 19:27, Christos Zoulas wrote:
> On Oct 3,  7:03pm, m...@m00nbsd.net (Maxime Villard) wrote:
> -- Subject: Re: CVS commit: src/sys
> 
> | What about you both cut the drama and the bullshit right here. What has been
> | said already repeatedly, again, and again, is that choosing one side over 
> the
> | other just does not work. There is no "most secure", there is no "most 
> usable".
> | There is the *middle* of it; some security with features that are still
> | compiled but not accessible by unpriv user by default, some usability with a
> | way to enable the feature that requires the least effort possible.
> 
> 
> How about the most usable is what we have now, and the most secure we can
> get via a sysctl? Or the other way around? We do need a decision on where
> we are heading though, because we keep disabling features piecemeal in the
> name of security.
> 
> christos
> 

I think that the approach in the middle is to use secmodel_securelevel(9).

Add fine-grained switch at which level compat_* stops to work with
default "1".

Desktop users will use INSECURE, server ones SECURE. I run Opera with
compat_linux and from time to time bootstrap something from Linux
executables. I don't care about extra hardening, my desktop does not
serve any public services.

For a server or a product I wouldn't want to run such executables and I
would use SECURE or HIGHLY-SECURE mode.

MODULAR vs non-MODULAR kernel approach appears to me too complex.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Christos Zoulas]

On Oct 3,  7:03pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys

| What about you both cut the drama and the bullshit right here. What has been
| said already repeatedly, again, and again, is that choosing one side over the
| other just does not work. There is no "most secure", there is no "most 
usable".
| There is the *middle* of it; some security with features that are still
| compiled but not accessible by unpriv user by default, some usability with a
| way to enable the feature that requires the least effort possible.


How about the most usable is what we have now, and the most secure we can
get via a sysctl? Or the other way around? We do need a decision on where
we are heading though, because we keep disabling features piecemeal in the
name of security.

christos

Re: CVS commit: src/sys

[Maxime Villard]

Le 03/10/2017 à 18:53, Christos Zoulas a écrit :

In article <20171003162103.ga25...@britannica.bec.de>,
Joerg Sonnenberger   wrote:

On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:

Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :

On 03.10.2017 15:35, Greg Troxel wrote:

Then, I think the debate
reduces to "should the checked-in GENERIC enable the emulation sysctl".


I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.

My personal preference is to keep it enabled by default


Let me just expose my point in another way, and try to prevent possible
misunderstandings: compat_linux and friends *must be disabled by default*.


This is *exactly* the point a lot of people disagreed with.


Yes, and for that we need to come up with a policy on the default OS
configuration. Do we provide by default the most secure configuration,
or the most usable one with easy ways to change from one to the other?


What about you both cut the drama and the bullshit right here. What has been
said already repeatedly, again, and again, is that choosing one side over the
other just does not work. There is no "most secure", there is no "most usable".
There is the *middle* of it; some security with features that are still
compiled but not accessible by unpriv user by default, some usability with a
way to enable the feature that requires the least effort possible.

Re: CVS commit: src/sys/arch/x86/x86

[Maxime Villard]

Le 03/10/2017 à 13:26, Joerg Sonnenberger a écrit :

At the same time, it has interesting interactions with power management
and the instruction queue.


The queue is flushed by a serializing instruction executed right before, which
is the recommended use case; the interaction with power management - and
by this I suppose you mean that some bioses change the cpu frequency depending
on the battery, temp, etc - also affects the software clock an attacker might
be running. In either case, rdtsc remains more accurate.


An additional thing we could do, if
we had proper NUMA support, would be to add a mode where the kernel schedules
unprivileged applications on a cluster, and the rest of the kernel and suid
LWPs on the other clusters. But that's far, far from us.


It would also kill performance.


no, but that's a different debate, so I'm leaving it there


Hiding the TSC doesn't solve any problem for this configuration.


solves problems, no; makes it harder to exploit problems, yes


All this sysctl provides is a very false sense of security and a way to
randomly break applications


Just like disabling va0 or enabling PaX mprotect; if you feel like these are
no issues, then what's the fuss. You would be well served to read the "rdtsc
is still enabled by default" part of my email.

I'm not responding to this nonsensical thread anymore, everything got told
months ago. The option is here, people don't need to give a damn about it
unless they explicitly want to - which is still legitimate in some cases,
including for kaslr, whether it pleases you or not. There are plenty of
useless sysctls to complain about if you like.

Re: CVS commit: src/sys

[Christos Zoulas]

In article <20171003162103.ga25...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:
>> Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
>> > On 03.10.2017 15:35, Greg Troxel wrote:
>> > > Then, I think the debate
>> > > reduces to "should the checked-in GENERIC enable the emulation sysctl".
>> > 
>> > I don't see a better answer to this question: yes, no or depends on the
>> > flavor of the kernel.
>> > 
>> > My personal preference is to keep it enabled by default
>> 
>> Let me just expose my point in another way, and try to prevent possible
>> misunderstandings: compat_linux and friends *must be disabled by default*.
>
>This is *exactly* the point a lot of people disagreed with.

Yes, and for that we need to come up with a policy on the default OS
configuration. Do we provide by default the most secure configuration,
or the most usable one with easy ways to change from one to the other?

christos

Re: CVS commit: src/sys

[Joerg Sonnenberger]

On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:
> Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
> > On 03.10.2017 15:35, Greg Troxel wrote:
> > > Then, I think the debate
> > > reduces to "should the checked-in GENERIC enable the emulation sysctl".
> > 
> > I don't see a better answer to this question: yes, no or depends on the
> > flavor of the kernel.
> > 
> > My personal preference is to keep it enabled by default
> 
> Let me just expose my point in another way, and try to prevent possible
> misunderstandings: compat_linux and friends *must be disabled by default*.

This is *exactly* the point a lot of people disagreed with.

Joerg

smbfs

[maya]

We can rump mount a lot of those filesystems, it would be nice if that
was be the default way too. A lot less risky

Re: CVS commit: src/sys

[Maxime Villard]

Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :

On 03.10.2017 15:35, Greg Troxel wrote:

Then, I think the debate
reduces to "should the checked-in GENERIC enable the emulation sysctl".


I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.

My personal preference is to keep it enabled by default


Let me just expose my point in another way, and try to prevent possible
misunderstandings: compat_linux and friends *must be disabled by default*. How
exactly, it does not really matter to me; I committed the sysctl because it was
the cleanest solution proposed so far, and if people have other preferences
that'll be fine, as long as these compat options *remain disabled by default*.

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 03.10.2017 15:35, Greg Troxel wrote:
> Then, I think the debate
> reduces to "should the checked-in GENERIC enable the emulation sysctl".

I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.

My personal preference is to keep it enabled by default, but I would ask
core@ for the official statement and follow it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Greg Troxel]

Manuel Bouyer  writes:

> On Mon, Oct 02, 2017 at 02:39:47PM +0200, Maxime Villard wrote:
>> > Actually I did suggest to make the default dependant on MODULAR.
>> 
>> what's the point exactly?
>
> that if I build a non-modular kernel with an emulation option explicitely
> selected, it works at boot. Even in single-user mode.

I think the real point is hidden behind this statement.

If I just run GENERIC, because I'm not paying attention to details, then
I am not "building a non-modular kernel with an emulation option
explicitly selected".  I'm accepting a default.

As I understand it, the real debate is about whether the distributed
GENERIC kernel will run Linux emulation by default, or whether it should
require some enabling of that emulation.   All the rest is details
flowing from that main decision.

Certainly there could be a kernel option to default the sysctl to on.
People who wnt to "explicitly select an emulation optoon" can turn on
that define, and have it working from boot.   Then, I think the debate
reduces to "should the checked-in GENERIC enable the emulation sysctl".


signature.asc
Description: PGP signature

Re: CVS commit: src/sys/arch/x86/x86

[Joerg Sonnenberger]

On Tue, Oct 03, 2017 at 08:17:27AM +0200, Maxime Villard wrote:
> What is clear, however, is that the effort needed to perform accurate
> measurements in software is much higher than that needed to invoke a hardware
> instruction that will instantly give about the most accurate answer possible.

Have you tried getting reliable answers out of rdtsc lately? It is
suprisingly difficult. TSC is nice for two properties:
- it is cheap as in it consumes few cycles by itself
- it has a high resolution

At the same time, it has interesting interactions with power management
and the instruction queue. As such, "the most accurate answer" is not
true either.

> Disabling rdtsc is almost the only thing we can do; we can't update the
> hardware to kill the variable timing.

Variable timing won't go away. Any "security" technique that can't deal
with it is doomed to failure.

> An additional thing we could do, if
> we had proper NUMA support, would be to add a mode where the kernel schedules
> unprivileged applications on a cluster, and the rest of the kernel and suid
> LWPs on the other clusters. But that's far, far from us.

It would also kill performance. Again, cycle timing rarely matters and
hiding the TSC won't fix any of the cases where it does. Those are
algorithmic issues. Hiding the TSC can make it harder to apply noise in
those unfixable cases though.

> So the sysctl is here, and is enabled. People don't need to care about it by
> default. The use case I see is for ssh servers running kaslr kernels.

Hiding the TSC doesn't solve any problem for this configuration. All
this sysctl provides is a very false sense of security and a way to
randomly break applications. That means it creates a support cost for
little to no gain.

Joerg