Re: CVS commit: src/tools/compat

[David H. Gutteridge]

> Module Name:src
> Committed By:   christos
> Date:   Mon Oct  2 22:19:45 UTC 2017
> 
> Modified Files:
> src/tools/compat: compat_defs.h configure.ac fpurge.c
> 
> Log Message:
> handle __fpurge being declared in 

This has broken the tools build of awk for me.

cc -O -D__EXTENSIONS__ -I/home/disciple/netbsd-
current/src/obj/tooldir.NetBSD-8.99.3-amd64/include/compat
-I/home/disciple/netbsd-current/src/tools/compat
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist -I. -c
-o run.lo.o -Wno-format-nonliteral   /home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist/run.c
/home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist/run.c:
In function 'closeall':
/home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist/run.c:1
873:12: error: void value not ignored as it ought to be
 stat = fpurge(files[i].fp) == EOF;
^

*** Failed target:  run.lo
*** Failed command: cc -O -D__EXTENSIONS__ -I/home/disciple/netbsd-
current/src/obj/tooldir.NetBSD-8.99.3-amd64/include/compat
-I/home/disciple/netbsd-current/src/tools/compat
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist -I. -c
-o run.lo.o -Wno-format-nonliteral /home/disciple/netbsd-
current/src/tools/awk/../../external/historical/nawk/bin/../dist/run.c
*** Error code 1

Stop.

Reverting this change fixes the build.

Regards,

Dave

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

[Joerg Sonnenberger]

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.

> 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.

Joerg

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

[Taylor R Campbell]

> Date: Mon, 2 Oct 2017 16:25:34 -0600
> From: Warner Losh 
> 
> 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.

There are plenty of legitimate applications of stop-watches.  It would
be great to forbid the attacker from doing arithmetic on your CPU too,
but if you forbid all your applications from using it, well, the chunk
of magic sand in your computer becomes about as useful as a chunk of
inert sand.

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

[Taylor R Campbell]

> 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.

Re: CVS commit: src/sys

[Maxime Villard]

Le 02/10/2017 à 19:12, Manuel Bouyer a écrit :

On Mon, Oct 02, 2017 at 07:05:20PM +0200, Maxime Villard wrote:

Le 02/10/2017 à 18:51, Manuel Bouyer a écrit :

On Mon, Oct 02, 2017 at 06:11:57PM +0200, Maxime Villard wrote:

so we remove COMPAT_LINUX from all architectures that do not support kernel
modules? this doesn't make compat_linux "nearby" or "easy to use" anymore


which architecture are theses ?


look at the many config files in evbarm/conf for example, some of them have
COMPAT_LINUX without MODULAR


I don't think COMPAT_LINUX is that usefull on arm. AFAIK there's no binary-only
app that we could run here.


that's another debate

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

[Joerg Sonnenberger]

On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Mon Oct  2 19:23:16 UTC 2017
> 
> Modified Files:
>   src/sys/arch/x86/x86: tsc.c tsc.h x86_machdep.c
> 
> Log Message:
> 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.

Joerg

Re: CVS commit: src/sys

[Joerg Sonnenberger]

On Mon, Oct 02, 2017 at 03:36:17PM +0200, Martin Husemann wrote:
> On Mon, Oct 02, 2017 at 03:16:14PM +0200, Maxime Villard wrote:
> > Le 02/10/2017 à 14:47, Manuel Bouyer a écrit :
> > > 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.
> > 
> > and what do we do with architectures that don't support kernel modules?
> 
> No emulation unless you build a custom kernel with the compat enabled.

No crippling of GENERIC please.

Joerg

Re: CVS commit: src/sys

[Manuel Bouyer]

On Mon, Oct 02, 2017 at 07:05:20PM +0200, Maxime Villard wrote:
> Le 02/10/2017 à 18:51, Manuel Bouyer a écrit :
> > On Mon, Oct 02, 2017 at 06:11:57PM +0200, Maxime Villard wrote:
> > > so we remove COMPAT_LINUX from all architectures that do not support 
> > > kernel
> > > modules? this doesn't make compat_linux "nearby" or "easy to use" anymore
> > 
> > which architecture are theses ?
> 
> look at the many config files in evbarm/conf for example, some of them have
> COMPAT_LINUX without MODULAR

I don't think COMPAT_LINUX is that usefull on arm. AFAIK there's no binary-only
app that we could run here.

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

Re: CVS commit: src/sys

[Maxime Villard]

Le 02/10/2017 à 18:51, Manuel Bouyer a écrit :

On Mon, Oct 02, 2017 at 06:11:57PM +0200, Maxime Villard wrote:

so we remove COMPAT_LINUX from all architectures that do not support kernel
modules? this doesn't make compat_linux "nearby" or "easy to use" anymore


which architecture are theses ?


look at the many config files in evbarm/conf for example, some of them have
COMPAT_LINUX without MODULAR

Re: CVS commit: src/sys

[Manuel Bouyer]

On Mon, Oct 02, 2017 at 06:11:57PM +0200, Maxime Villard wrote:
> so we remove COMPAT_LINUX from all architectures that do not support kernel
> modules? this doesn't make compat_linux "nearby" or "easy to use" anymore

which architecture are theses ?

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

Re: CVS commit: src/sys

[Maxime Villard]

Le 02/10/2017 à 15:36, Martin Husemann a écrit :

On Mon, Oct 02, 2017 at 03:16:14PM +0200, Maxime Villard wrote:

Le 02/10/2017 à 14:47, Manuel Bouyer a écrit :

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.


and what do we do with architectures that don't support kernel modules?


No emulation unless you build a custom kernel with the compat enabled.


so we remove COMPAT_LINUX from all architectures that do not support kernel
modules? this doesn't make compat_linux "nearby" or "easy to use" anymore

Re: CVS commit: src/sys

[Kamil Rytarowski]

On 02.10.2017 15:36, Martin Husemann wrote:
> On Mon, Oct 02, 2017 at 03:16:14PM +0200, Maxime Villard wrote:
>> Le 02/10/2017 à 14:47, Manuel Bouyer a écrit :
>>> 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.
>>
>> and what do we do with architectures that don't support kernel modules?
> 
> No emulation unless you build a custom kernel with the compat enabled.
> 
> Martin
> 

I would leave this and all other compat code turned on by default.

There could be a sysinst option or note how to harden it (adding an
entry in /etc/sysctl.conf).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys

[Martin Husemann]

On Mon, Oct 02, 2017 at 03:16:14PM +0200, Maxime Villard wrote:
> Le 02/10/2017 à 14:47, Manuel Bouyer a écrit :
> > 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.
> 
> and what do we do with architectures that don't support kernel modules?

No emulation unless you build a custom kernel with the compat enabled.

Martin

Re: CVS commit: src/sys

[Martin Husemann]

On Mon, Oct 02, 2017 at 02:47:57PM +0200, Manuel Bouyer wrote:
> 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 agree with that requirement.

And if I boot a MODULAR kernel and explicitly load the module, I want it
to work too, no additional sysctl setting.

I also agree with emulation not doing any module auto-loads by default.
A sysctl to swith this behaviour (temporarily) might be ok.

Martin
P.S.: this is not a good list for this discussion, tech-kern might be better.

Re: CVS commit: src/sys

[Manuel Bouyer]

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.

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

Re: CVS commit: src/sys

[Maxime Villard]

Le 01/10/2017 à 13:38, Manuel Bouyer a écrit :

On Sun, Oct 01, 2017 at 09:38:32AM +0200, Maxime Villard wrote:


No. It is clear that none of the proposals in the recent threads has brought
unanimous consensus, but this sysctl appears to be the least problematic
solution. You can speculate endlessly on how difficult it is to type "modload",
on how many more sysctls we need to add to do autoloads, on where to put the
functions, the #ifdefs, the options, and so on; meanwhile, I'm going to get
things done. For now it's a sysctl - if you have a better and implementable
idea, I'll be happy to hear about it and to work on it.


Actually I did suggest to make the default dependant on MODULAR.


what's the point exactly?

Re: CVS commit: src/sys/dev

[Tetsuya Isaki]

At Mon, 2 Oct 2017 07:06:15 +,
> Committed By: nat
> Date: Mon Oct  2 07:06:15 UTC 2017
> 
> Modified Files:
>   src/sys/dev: auconv.c
> 
> Log Message:
> Allow maxused to be an odd number of bytes.  This makes single byte
> conversions work for the test described in the PR.

Please read PR, nat@.
I don't hope to correct this ridiculous macro.
It just increases dead code in kernel.
I'd like to clarify the specification first (See also PR/52585).
---
Tetsuya Isaki