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
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().
-
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 mailto:m...@netbsd.org>> wrote:
John Klos mailto:j...@ziaspace.com>> wrote:
FWIW, Intel updated their microcode on 8-Jan-
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 mailto:m...@netbsd.org>> wrote:
John Klos mailto:j...@ziaspace.com>> wrote:
FWIW, Intel updated their microcode on 8-Jan-2018:
https://downloadcenter.intel.com/downl
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
On 2018/01/15 3:42, Dave Huang wrote:
On Jan 13, 2018, at 22:20, Emmanuel Dreyfus mailto:m...@netbsd.org>> wrote:
John Klos mailto:j...@ziaspace.com>> wrote:
FWIW, Intel updated their microcode on 8-Jan-2018:
https://downloadcenter.intel.com/download/27431/
I can't find any documentation wh
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 version 0x58,
> plat
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 for each
>> family of processors.
>
>
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
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 tests from git repositor
Le 11/01/2018 à 20:14, Jaromír Doleček a écrit :
2018-01-10 19:56 GMT+01:00 Maxime Villard mailto:m...@m00nbsd.net>>:
> 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, b
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 2
> 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 relinguish PCID when the
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.
>
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
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 structure
cache flush
Le 09/01/2018 à 21:23, Jaromír Doleček a écrit :
2018-01-08 10:24 GMT+01:00 Maxime Villard mailto:m...@m00nbsd.net>>:
> 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
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 stale in the pmap
common pmap uses ASIDs too, I was curious about it before hearing about
the vulnerability because I thought it might have performance benefits.
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 tim
Sorry, to specify, that is:
2141 #if defined(XEN)
2142 pmap_tlb_shootnow();
2143 #endif
in x86/pmap.c
#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?)
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,
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 branches
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
eventuall
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
D
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!
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 entr
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 microcode
> 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: t
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 hotpatc
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 th
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 a real fix? Indeed, do we h
> 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 (appar
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. Gu
somewhat off-topic, but even AMD will suffer from meltdown in xen PV,
with the kernel running in ring3
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.
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 the
38 matches
Mail list logo