Re: amd64: svs

On 1/6/2018 19:58, Mouse wrote: Why? Is there any reason to not deploy known effective countermeasures while waiting for a real fix? Indeed, do we have any reason to think a real fix will be forthcoming from Intel? In view of their attempts to downplay their bugs, I have negative confidence

Re: amd64: svs

On Sat, 6 Jan 2018 20:58:51 -0500 (EST) Mouse wrote: > > I think, we should wait for a while to coming new microcode and > > disclosure of specification update from intel. > > Why? Is there any reason to not deploy known effective countermeasures > while waiting for

Re: amd64: svs

> Xen project say meltdown vulnerability is only for Intel. That matches my understanding: only Intel optimizes that aggressively. (Apparently.) Of course, there are also the various forms of spectre, exploiting much the same hardware bugs, just in different ways - ways _not_ involving the

Re: amd64: svs

off topics... Xen project say meltdown vulnerability is only for Intel. https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ "Only Intel processors are impacted by Meltdown (referred to as SP3 in Advisory 254). On Intel processors, only 64-bit PV mode guests can attack Xen.

Re: Go binary panics on amd64-current - SIG*unknown

In article <20180106224309.w2vicky2i6rf6fvu@neva>, Alexander Nasonov wrote: >I downloaded IACA tool from intel.com but I couldn't run it: > >$ ktrace ./iaca-v3.0-lin64/iaca >fatal error: rt_sigaction read failure > >runtime stack: >runtime.throw(0x75de24, 0x19) >

Re: Go binary panics on amd64-current - SIG*unknown

I think the issue is caused by linux defining signals from 1 to LINUX__NSIG, while the linux compat code in netbsd recognises signals from 1 to LINUX__NSIG-1. That's why the binary is aborting when calling sigaction on signal 64, which is LINUX__NSIG on amd64. - S

Re: Go binary panics on amd64-current - SIG*unknown

On Sat, Jan 06, 2018 at 10:43:09PM +, Alexander Nasonov wrote: > runtime.getsig(0x40, 0x441c60) > /nfs/iil/disks/kfw/tools/go/go-latest/src/runtime/os_linux.go:427 > +0x92 Is that a linux binary? that seems to come from:

Go binary panics on amd64-current - SIG*unknown

I downloaded IACA tool from intel.com but I couldn't run it: $ ktrace ./iaca-v3.0-lin64/iaca fatal error: rt_sigaction read failure runtime stack: runtime.throw(0x75de24, 0x19) /nfs/iil/disks/kfw/tools/go/go-latest/src/runtime/panic.go:596 +0x95 runtime.getsig(0x40, 0x441c60)

re: modstat and kaslr

Maxime Villard writes: > Hi, > Here is a patch [1] that hides the addresses of the kernel modules when > 'modstat -k' is entered by an unprivileged user. The current behavior is > preserved for root. > > The addresses currently leaked cannot be used to reconstruct the layout of > the kernel,

Re: amd64: svs

somewhat off-topic, but even AMD will suffer from meltdown in xen PV, with the kernel running in ring3

Re: meltdown

Hello, On Sat, 6 Jan 2018 07:33:50 + m...@netbsd.org wrote: > Loongson-2 had an issue where from branch prediction it would prefetch > instructions from the I/O area and deadlock. > > This happened in normal usage so we build the kernel with a binutils > flag to output different jumps and

Re: amd64: svs

some comments. AMD line of CPUs does not need such VM space separation from meltdown point of view. I hope future CPU designs have proper security checks and do not require such a separation. Runtime detection and configuration is desired as the Linux did, rather than fixed compile-time option.

Re: meltdown

>> Though of course "fail early" is an obvious principle to security >> types, given the cost of aborting work in progress I can easily see >> the opposite being true for CPU designers (I'm not one, so I don't >> really know). Which idiom (check permissions, then speculate / >> speculate, then

amd64: svs

Here is an implementation that isolates the user and kernel virtual spaces on amd64 [1] - SVS, for Separate Virtual Space. It is incomplete, but it's a functional first shot. The goal is to unmap the kernel when running in usermode. To achieve that, we create a per-cpu L4 page, which contains