Re: amd64: svs

On Mon, Jan 15, 2018 at 07:39:39PM +0900, Masanobu SAITOH wrote: > One of possibilities is that Goldmont core has no this > vulnerability and RDCL_NO bit just indicate it. The most reliable way to tell would be to port the Linux Meltdown PoC. -- Emmanuel Dreyfus m...@netbsd.org

Re: amd64: svs

On 2018/01/15 18:12, Emmanuel Dreyfus wrote: On Mon, Jan 15, 2018 at 05:34:18PM +0900, Masanobu SAITOH wrote: cpu0: MSR_IA32_ARCH_CAPABILITIES=0x1 I've not written this bit by myself. Where can this be readen without your patch? In cpu_ucode_intel.c::cpu_ucode_intel_apply().

Re: amd64: svs

On 2018/01/15 17:42, Masanobu SAITOH wrote: On 2018/01/15 17:34, Masanobu SAITOH wrote: On 2018/01/15 3:42, Dave Huang wrote: On Jan 13, 2018, at 22:20, Emmanuel Dreyfus > wrote: John Klos > wrote: FWIW,

Re: amd64: svs

On 2018/01/15 17:34, Masanobu SAITOH wrote: On 2018/01/15 3:42, Dave Huang wrote: On Jan 13, 2018, at 22:20, Emmanuel Dreyfus > wrote: John Klos > wrote: FWIW, Intel updated their microcode on 8-Jan-2018:

Re: amd64: svs

On Mon, Jan 15, 2018 at 05:34:18PM +0900, Masanobu SAITOH wrote: > > cpu0: MSR_IA32_ARCH_CAPABILITIES=0x1 > I've not written this bit by myself. Where can this be readen without your patch? -- Emmanuel Dreyfus m...@netbsd.org

Re: amd64: svs

On 2018/01/15 3:42, Dave Huang wrote: On Jan 13, 2018, at 22:20, Emmanuel Dreyfus > wrote: John Klos > wrote: FWIW, Intel updated their microcode on 8-Jan-2018:

Re: amd64: svs

Emmanuel Dreyfus wrote: > It does not seems to fix much. > > I tried the tests from git repository > http://github.com/IAIK/meltdown.git > > This is Linux-centric, but at least, the "secret" case seems to apply on > NetBSD. It reports vulnerability before (cpu0: microcode

Re: amd64: svs

On Jan 13, 2018, at 22:20, Emmanuel Dreyfus wrote: > > John Klos wrote: > >> FWIW, Intel updated their microcode on 8-Jan-2018: >> >> https://downloadcenter.intel.com/download/27431/ >> >> I can't find any documentation which shows what exactly is fixed

Re: amd64: svs

On Sun, Jan 14, 2018 at 05:20:43AM +0100, Emmanuel Dreyfus wrote: > > I can't find any documentation which shows what exactly is fixed for each > > family of processors. > > It does not seems to fix much. By itself not, but it allows better workarounds by the OS. Martin

Re: amd64: svs

John Klos wrote: > FWIW, Intel updated their microcode on 8-Jan-2018: > > https://downloadcenter.intel.com/download/27431/ > > I can't find any documentation which shows what exactly is fixed for each > family of processors. It does not seems to fix much. I tried the

Re: amd64: svs

Le 11/01/2018 à 20:14, Jaromír Doleček a écrit : 2018-01-10 19:56 GMT+01:00 Maxime Villard >: > That's what we do, too. Doing this is faster than "unmapping the kernel pages > on return to user space". > > Switching the address space costs one

Re: amd64: svs

It looks like two of the Dell machines I use have BIOS updates that include the new microcode, but I don't know when it'll be available for the other machines I use. The standalone microcode update at https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File is dated

Re: amd64: svs

> Date: Thu, 11 Jan 2018 20:24:55 +0100 > From: Martin Husemann > > On Thu, Jan 11, 2018 at 08:14:59PM +0100, Jaromír Dole?ek wrote: > > Okay, I'll look into this. The feature seems pretty simple to use, though > > it will need > > some care to allow inactive processes to

Re: amd64: svs

On Thu, 11 Jan 2018, Martin Husemann wrote: > On Thu, Jan 11, 2018 at 08:14:59PM +0100, Jaromír Dole?ek wrote: > > Okay, I'll look into this. The feature seems pretty simple to use, though > > it will need > > some care to allow inactive processes to relinguish PCID when there is > > shortage. >

Re: amd64: svs

On Thu, Jan 11, 2018 at 08:14:59PM +0100, Jaromír Dole?ek wrote: > Okay, I'll look into this. The feature seems pretty simple to use, though > it will need > some care to allow inactive processes to relinguish PCID when there is > shortage. All sane architectures are already using it ;-) Sparc64

Re: amd64: svs

2018-01-10 19:56 GMT+01:00 Maxime Villard : > That's what we do, too. Doing this is faster than "unmapping the kernel pages > on return to user space". > > Switching the address space costs one "movq %rax,%cr3". Yes, but address space switch also causes an implicit TLB/paging

Re: amd64: svs

2018-01-08 10:24 GMT+01:00 Maxime Villard : > > As far as SVS is concerned, it is not needed: each time an L4 slot is added > (pmap_get_ptp) or removed (pmap_free_ptp), SVS only applies the change in the > user page tables. > > The TLB is then flushed as usual: the slots that are

Re: amd64: svs

common pmap uses ASIDs too, I was curious about it before hearing about the vulnerability because I thought it might have performance benefits.

Re: amd64: svs

Le 08/01/2018 à 07:33, m...@netbsd.org a écrit : #if defined(XEN) pmap_tlb_shootnow(); #endif does that need to be defined(XEN) || defined(SVS) now? Actually I didn't understand why XEN had this #ifdef in the first place. As far as SVS is concerned, it is not needed: each

Re: amd64: svs

Sorry, to specify, that is: 2141 #if defined(XEN) 2142 pmap_tlb_shootnow(); 2143 #endif in x86/pmap.c

Re: amd64: svs

#if defined(XEN) pmap_tlb_shootnow(); #endif does that need to be defined(XEN) || defined(SVS) now? (does lots of that need to be domU || SVS?)

Re: amd64: svs

Le 07/01/2018 à 19:04, Jaromír Doleček a écrit : BTW Maxime, I've updated https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention to note your work on NetBSD support for SMAP and SMEP. Would it be feasible to get SMAP support pulled up to netbsd-8 by chance? That's not related to SVS,

Re: amd64: svs

Le 07/01/2018 à 18:22, Kamil Rytarowski a écrit : On 07.01.2018 18:13, m...@netbsd.org wrote: It will be good to document somewhere why SVS exists. it's obvious now, but it might not be in a decade. Thanks for working on this! I expect that we are now required to pullup it to stable

Re: amd64: svs

BTW Maxime, I've updated https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention to note your work on NetBSD support for SMAP and SMEP. Would it be feasible to get SMAP support pulled up to netbsd-8 by chance? The AMD Epyc processors support SMEP/SMAP as well, hopefully this will

Re: amd64: svs

On 07.01.2018 18:13, m...@netbsd.org wrote: > It will be good to document somewhere why SVS exists. it's obvious now, > but it might not be in a decade. > > Thanks for working on this! > I expect that we are now required to pullup it to stable branches. Thanks for the fixes! signature.asc

Re: amd64: svs

It will be good to document somewhere why SVS exists. it's obvious now, but it might not be in a decade. Thanks for working on this!

Re: amd64: svs

Le 07/01/2018 à 11:05, Maxime Villard a écrit : Le 06/01/2018 à 16:03, cl...@csel.org a écrit : Runtime detection and configuration is desired as the Linux did, rather than fixed compile-time option. It would be nice, but it is more complicated than it seems. We would have to hotpatch the

Re: amd64: svs

On Sun, Jan 07, 2018 at 12:26:00PM +0900, cl...@csel.org wrote: [..] > The Redhat and Microsoft implicitly says "Intel will release microcode > soon". I hoped to it. > > the Linux supported by the google goes to the KPTI, maybe, > it means the Intel does not plan to mitigate by the new

Re: amd64: svs

> The Redhat and Microsoft implicitly says "Intel will release > microcode soon". I hoped to it. It's possible it's _partially_ fixable in microcode. It's possible it's fixable in microcode and my pessimism is wrong. But the scenario I think most likely is the one Dave Huang's post describes:

Re: amd64: svs

Le 06/01/2018 à 16:03, cl...@csel.org a écrit : Runtime detection and configuration is desired as the Linux did, rather than fixed compile-time option. It would be nice, but it is more complicated than it seems. We would have to hotpatch the entry points, and to do that we need a way to

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: amd64: svs

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

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.

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