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

2017-03-24 Thread coypu 
On Thu, Mar 23, 2017 at 05:25:51PM +, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Thu Mar 23 17:25:51 UTC 2017
> 
> Modified Files:
>   src/sys/arch/amd64/amd64: locore.S machdep.c trap.c
> 
> Log Message:
> Remove this call gate on amd64, it is useless and vulnerable.
> 
> Call gates do not modify %rflags, so interrupts are not disabled when
> entering the gate. There is a small window where we are in kernel mode and
> with a userland %gs, and if an interrupt happens here we will rejump into
> the kernel but not switch to the kernel TLS.
> 
> Userland can simply perform a gate call in a loop, and hope that at some
> point an interrupt will be received in this window - which necessarily will
> be the case. With a specially-crafted %gs it is certainly enough to
> escalate privileges.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.121 -r1.122 src/sys/arch/amd64/amd64/locore.S
> cvs rdiff -u -r1.253 -r1.254 src/sys/arch/amd64/amd64/machdep.c
> cvs rdiff -u -r1.94 -r1.95 src/sys/arch/amd64/amd64/trap.c
> 

cool!

I see in arch/i386/i386/locore.S that there is another call gate and
there's:

1246 IDTVEC(osyscall)
1247 #ifndef XEN
1248 /* XXX we are in trouble! interrupts be off here. */
1249 cli /* must be first instruction */
1250 #endif
1251 pushfl  /* set eflags in trap frame */

Is 'cli' as first instruction what should've been done here, if it
wasn't been otherwise useless? can xen not do it?

thanks.

Re: CVS commit: src/tests/lib/libc/sys

2017-03-24 Thread Paul Goyette 

Module Name:src
Committed By:   martin
Date:   Fri Mar 24 08:18:27 UTC 2017

Modified Files:
src/tests/lib/libc/sys: t_mprotect.c

Log Message:
Do not toggle global security.pax.mprotect state in an attempt to
activate it for the current process. It does not work and tests should
not change global system state anyway.
Instead: skip the test is pax.mprotect is not globally enabled. We
could use a better check for this (querying the current processes pax 
flags), but unfortunately we don't have one.


I'll be committing a new sysctl variable proc.curproc.paxflags which 
will provide the ability to quest the current process's pax flags (or, 
indeed, the pax flags for any process which the caller is "allowed to 
see").



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

re: CVS commit: src

2017-03-24 Thread matthew green 
"Nathanial Sloss" writes:
> Module Name:  src
> Committed By: nat
> Date: Thu Mar 23 15:50:48 UTC 2017
> 
> Modified Files:
>   src/distrib/sets/lists/base: shl.mi
>   src/lib/libossaudio: ossaudio.c shlib_version
> 
> Log Message:
> Calculate GETISPACE/GETOSPACE properly.
> Bump version.

this didn't change or add to the ABI in any way did it?  ie, there's
no need to bump the version.

thanks.


.mrg.