Re: Intel CPU design flaw - FreeBSD affected? [AMD family Zen/17h status]

[Mark Millard]

On 2018-Jan-6, at 2:02 PM, Mark Millard  wrote:

> On 2018-Jan-4, at 7:32 PM, Mark Millard  wrote:
> 
>> Darren Reed darrenr at freebsd.org wrote on
>> Thu Jan 4 11:56:29 UTC 2018 :
>> 
>>> Most people are only talking about meltdown which doesn't hit AMD.
>>> spectre impacts *both* Intel and AMD.
>>> 
>>> SuSE are making available a microcode patch for AMD 17h processors that
>>> disables branch prediction:
>>> 
>>> 
>>> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html
>> 
>> https://www.amd.com/en/corporate/speculative-execution
>> 
>> reports. . .
>> 
>> For the Bounds Check Bypass Spectre variant (#1):
>> 
>> Resolved by software / OS updates to be made available
>> by system vendors and manufacturers. Negligible performance
>> impact expected.
>> 
>> For the Branch Target Injection Spectre variant (#2):
>> 
>> Differences in AMD architecture mean there is a near zero
>> risk of exploitation of this variant. Vulnerability to
>> Variant 2 has not been demonstrated on AMD processors to
>> date.
>> 
>> For the Rogue Data Cache Load Meltdown variant (#3):
>> 
>> Zero AMD vulnerability due to AMD architecture differences.
>> 
>> 
>> 
>> How long #2 will have a "has not been demonstrated" status
>> is yet to be seen.
> 
> https://www.phoronix.com/scan.php?page=news_item=AMD-Branch-Prediction-Still
> 
> reports that SUSE's microcode update for AMD's Zen/17h does
> not disable branch prediction, despite SUSE's existing
> description:
> 
> QUOTE
> I reached out to AMD and on Friday heard back. They wrote in an email
> to Phoronix that this Zen/17h microcode update does not disable branch
> prediction. They'll be working with SUSE to re-clarify this microcode
> update description... But as far as what this microcode update does in
> the wake of SPECTRE they have yet to clarify or why this microcode
> binary has yet to make it to other Linux distributions. If/when I hear
> anything more, I'll certainly post about it but doesn't appear to be
> anything as dramatic as disabling branch prediction, which could have
> slaughtered their CPU performance.
> END QUOTE

https://www.amd.com/en/corporate/speculative-execution has been updated
and amd no longer claims that #2 has not been demonstrated. They state
there will  be microcode updates for it:

QUOTE
AMD will make optional microcode updates available to our customers and partners
for Ryzen and EPYC processors starting this week. We expect to make updates
available for our previous generation products over the coming weeks.
END QUOTE

===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? [AMD family Zen/17h status]

[Mark Millard]

On 2018-Jan-4, at 7:32 PM, Mark Millard  wrote:

> Darren Reed darrenr at freebsd.org wrote on
> Thu Jan 4 11:56:29 UTC 2018 :
> 
>> Most people are only talking about meltdown which doesn't hit AMD.
>> spectre impacts *both* Intel and AMD.
>> 
>> SuSE are making available a microcode patch for AMD 17h processors that
>> disables branch prediction:
>> 
>> 
>> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html
> 
> https://www.amd.com/en/corporate/speculative-execution
> 
> reports. . .
> 
> For the Bounds Check Bypass Spectre variant (#1):
> 
> Resolved by software / OS updates to be made available
> by system vendors and manufacturers. Negligible performance
> impact expected.
> 
> For the Branch Target Injection Spectre variant (#2):
> 
> Differences in AMD architecture mean there is a near zero
> risk of exploitation of this variant. Vulnerability to
> Variant 2 has not been demonstrated on AMD processors to
> date.
> 
> For the Rogue Data Cache Load Meltdown variant (#3):
> 
> Zero AMD vulnerability due to AMD architecture differences.
> 
> 
> 
> How long #2 will have a "has not been demonstrated" status
> is yet to be seen.

https://www.phoronix.com/scan.php?page=news_item=AMD-Branch-Prediction-Still

reports that SUSE's microcode update for AMD's Zen/17h does
not disable branch prediction, despite SUSE's existing
description:

QUOTE
I reached out to AMD and on Friday heard back. They wrote in an email
to Phoronix that this Zen/17h microcode update does not disable branch
prediction. They'll be working with SUSE to re-clarify this microcode
update description... But as far as what this microcode update does in
the wake of SPECTRE they have yet to clarify or why this microcode
binary has yet to make it to other Linux distributions. If/when I hear
anything more, I'll certainly post about it but doesn't appear to be
anything as dramatic as disabling branch prediction, which could have
slaughtered their CPU performance.
END QUOTE

===
Mark Millard
markmi at dsl-only.net


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Klaus P. Ohrhallinger]

On 04.01.2018 22:07, Michael Butler wrote:

> 
> Interestingly, the Xeon 5400 series is not listed as vulnerable in the
> Intel documentation where the 5500 and 5600s are; I checked as I have a
> bunch of E5440s in service.
> 
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr
> 

Thanks for the link. Seems this was not available when I searched for a
list of vulnerable CPUs.

I'm not sure about Xeon W5590, it is on the list but the spectre poc
does not read anything.

For meltdown, somewhere in the news I read that all Intel CPUs since
1995 are vulnerable, which is rubbish.
The paper says Intel CPUs since 2010.

I tried different approaches to get meltdown working on Xeon E5420 and
W5590 (launched Q3/2009) ... just nothing.

So I am really happy that my 10 HP Proliant DL360 G5 are still safe.
At least for me, a lot of panic for nothing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[Andrew Reilly]

On Fri, Jan 05, 2018 at 02:27:40AM +0800, blubee blubeeme wrote:
> I'd love to see if RISC-V is vulnerable to this?
> 
> I think they are in the best position to capitalize on this clusterfk...

It's a micro-architecture flaw, not an instruction set flaw, so
just as for ARM and amd64, it will depend on the specific version.
The only RISC-V hardware that I'm aware of is in-order (no speculation)
so unlikely to be affected.  There aren't any data-centre-scale
RISC-V systems yet, but some are being worked-on.  Will be interesting
to see if they suddenly push out roadmaps while they go back to
re-design to avoid this...

Cheers,

Andrew

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Erich Dollansky]

Hi,

On Thu, 4 Jan 2018 15:33:46 +0100
Stefan Esser  wrote:

> Am 04.01.18 um 12:56 schrieb Darren Reed:
> > On 4/01/2018 11:51 AM, Mark Heily wrote:  
> >> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
> >>
> >> The register article says the specifics are under embargo still.
> >> That would make it hard for anybody working with Intel to comment
> >> publicly on the flaw and any mitigations that may be underway. It
> >> would be unwise to assume that all the details are out until the
> >> embargo lifts.
> >>
> >>
> >> Details of the flaws are now published at:
> >>
> >> https://meltdownattack.com  
> > 
> > The web page has both: meltdown and spectre.
> > Most people are only talking about meltdown which doesn't hit AMD.
> > spectre impacts *both* Intel and AMD.
> > 
> > SuSE are making available a microcode patch for AMD 17h processors
> > that disables branch prediction:
> > 
> > https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html 
> >  
> 
> Disabling branch prediction will have a very noticeable effect on
> execution speed in general (while split page tables only affect
> programs that perform system calls at a high frequency).
> 
> I have not fully read the Meltdown and Spectre papers, yet, but I do
> assume, that the attack at the branch prediction tries to counter
> KASLR, which we do not support at all in FreeBSD.
> 
> So, I guess, we do not have to bother with disabling of branch
> prediction in FreeBSD for the time being?
> 
an attack on KASLR will not work, but any other attack will be get data
from the kernel out. So, FreeBSD is affected but not by the attacks
which will work on the other operating systems. Information still can
be extracted.

Erich
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Mark Millard]

Darren Reed darrenr at freebsd.org wrote on
Thu Jan 4 11:56:29 UTC 2018 :

> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that
> disables branch prediction:
> 
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

https://www.amd.com/en/corporate/speculative-execution

reports. . .

For the Bounds Check Bypass Spectre variant (#1):

Resolved by software / OS updates to be made available
by system vendors and manufacturers. Negligible performance
impact expected.

For the Branch Target Injection Spectre variant (#2):

Differences in AMD architecture mean there is a near zero
risk of exploitation of this variant. Vulnerability to
Variant 2 has not been demonstrated on AMD processors to
date.

For the Rogue Data Cache Load Meltdown variant (#3):

Zero AMD vulnerability due to AMD architecture differences.



How long #2 will have a "has not been demonstrated" status
is yet to be seen.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? Information from Arm

[Jon Brawn]

Wotcha!

My employer, Arm, have made the following website available to help with 
deciding what to do about this security issue.

http://www.arm.com/security-update 

Note: I am not writing here as a representative of Arm, and cannot provide 
further information about this issue. I would encourage you to read all the 
pages and the white paper thoroughly to best understand this issue as it 
relates to working with Arm processors.

Jon.

smime.p7s
Description: S/MIME cryptographic signature

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Conrad Meyer]

Possibly because Xeon 5400 dates to 2007 — it may have less advanced
speculative / out-of-order execution and may not have the same branch
prediction algorithm as Haswell.

On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler
 wrote:
> On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
>> On 04.01.2018 19:51, Jan Kokemüller wrote:
>>
>>> It is possible to emulate a high resolution counter with a thread that
>>> continuously increments a variable [1]. This is the reason why browser
>>> vendors are currently disabling the SharedArrayBuffer feature [2].
>>>
>>> [1]: 
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
>>> [2]: 
>>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>>
>> I tried the phtread example from [1] but even with some tweaking is does
>> not work at all.
>>
>> This is a multiprocessor system, with moderate load.
>>
>> As far as I understand the matter, it can only work if both threads
>> share the same cpu cache, otherwise the counter variable is either never
>> up-to-date, or has to be fetched and stored from/to memory, which is way
>> too slow for this purpose.
>>
>> Any suggestions ?
>>
>> ---
>>
>> CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
>> K8-class CPU)
>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>> FreeBSD/SMP: 2 package(s) x 4 core(s)
>
> Interestingly, the Xeon 5400 series is not listed as vulnerable in the
> Intel documentation where the 5500 and 5600s are; I checked as I have a
> bunch of E5440s in service.
>
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr
>
> imb
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Michael Butler]

On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
> On 04.01.2018 19:51, Jan Kokemüller wrote:
> 
>> It is possible to emulate a high resolution counter with a thread that
>> continuously increments a variable [1]. This is the reason why browser
>> vendors are currently disabling the SharedArrayBuffer feature [2].
>>
>> [1]: 
>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
>> [2]: 
>> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
> 
> I tried the phtread example from [1] but even with some tweaking is does
> not work at all.
> 
> This is a multiprocessor system, with moderate load.
> 
> As far as I understand the matter, it can only work if both threads
> share the same cpu cache, otherwise the counter variable is either never
> up-to-date, or has to be fetched and stored from/to memory, which is way
> too slow for this purpose.
> 
> Any suggestions ?
> 
> ---
> 
> CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
> K8-class CPU)
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> FreeBSD/SMP: 2 package(s) x 4 core(s)

Interestingly, the Xeon 5400 series is not listed as vulnerable in the
Intel documentation where the 5500 and 5600s are; I checked as I have a
bunch of E5440s in service.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Klaus P. Ohrhallinger]

On 04.01.2018 19:51, Jan Kokemüller wrote:

> It is possible to emulate a high resolution counter with a thread that
> continuously increments a variable [1]. This is the reason why browser
> vendors are currently disabling the SharedArrayBuffer feature [2].
> 
> [1]: 
> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
> [2]: 
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

I tried the phtread example from [1] but even with some tweaking is does
not work at all.

This is a multiprocessor system, with moderate load.

As far as I understand the matter, it can only work if both threads
share the same cpu cache, otherwise the counter variable is either never
up-to-date, or has to be fetched and stored from/to memory, which is way
too slow for this purpose.

Any suggestions ?

---

CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (2500.14-MHz
K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Jan Kokemüller]

On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> All PoC code I have seen today relies on those instructions.
> Is there any other way to measure the memory/cache access times ?

It is possible to emulate a high resolution counter with a thread that
continuously increments a variable [1]. This is the reason why browser
vendors are currently disabling the SharedArrayBuffer feature [2].

[1]: 
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
[2]: 
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[blubee blubeeme]

On Fri, Jan 5, 2018 at 2:25 AM, Klaus P. Ohrhallinger  wrote:

> On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> > Hello,
> >
> > I disabled the ldtsc and ldtscp instructions for usermode on one of my
> > production servers:
> >
>
> Oops, RDTSC of course.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
I'd love to see if RISC-V is vulnerable to this?

I think they are in the best position to capitalize on this clusterfk...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Klaus P. Ohrhallinger]

Hello,

I disabled the ldtsc and ldtscp instructions for usermode on one of my
production servers:

% ./spectre
Reading 40 bytes:
Bus error (core dumped)

All PoC code I have seen today relies on those instructions.
Is there any other way to measure the memory/cache access times ?

On 10.4-RELEASE I had to rebuild world and some ports, but now
everything seems to be working fine.
Patches attached.

Regards, Klaus
diff -aupr src.orig/sys/amd64/amd64/initcpu.c src/sys/amd64/amd64/initcpu.c
--- src.orig/sys/amd64/amd64/initcpu.c  2017-09-29 02:20:05.0 +0200
+++ src/sys/amd64/amd64/initcpu.c   2018-01-04 15:19:32.741729000 +0100
@@ -210,6 +210,7 @@ initializecpu(void)
}
if (cpu_stdext_feature & CPUID_STDEXT_FSGSBASE)
cr4 |= CR4_FSGSBASE;
+   cr4 |= CR4_TSD;
 
/*
 * Postpone enabling the SMEP on the boot CPU until the page
diff -aupr src.orig/sys/x86/x86/tsc.c src/sys/x86/x86/tsc.c
--- src.orig/sys/x86/x86/tsc.c  2017-09-29 02:20:06.0 +0200
+++ src/sys/x86/x86/tsc.c   2018-01-04 15:19:32.756123000 +0100
@@ -658,6 +658,7 @@ tsc_freq_changed(void *arg, const struct
 static int
 sysctl_machdep_tsc_freq(SYSCTL_HANDLER_ARGS)
 {
+#if 0
int error;
uint64_t freq;
 
@@ -671,6 +672,9 @@ sysctl_machdep_tsc_freq(SYSCTL_HANDLER_A
freq >> (int)(intptr_t)tsc_timecounter.tc_priv);
}
return (error);
+#else
+   return (EOPNOTSUPP);
+#endif
 }
 
 SYSCTL_PROC(_machdep, OID_AUTO, tsc_freq, CTLTYPE_U64 | CTLFLAG_RW,
diff -aupr src.orig/lib/libc/amd64/sys/__vdso_gettc.c 
src/lib/libc/amd64/sys/__vdso_gettc.c
--- src.orig/lib/libc/amd64/sys/__vdso_gettc.c  2017-09-29 02:20:13.0 
+0200
+++ src/lib/libc/amd64/sys/__vdso_gettc.c   2018-01-04 16:53:31.590961000 
+0100
@@ -30,17 +30,22 @@ __FBSDID("$FreeBSD: releng/10.4/lib/libc
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "libc_private.h"
 
 static u_int
 __vdso_gettc_low(const struct vdso_timehands *th)
 {
+#if 0
uint32_t rv;
 
__asm __volatile("rdtsc; shrd %%cl, %%edx, %0"
: "=a" (rv) : "c" (th->th_x86_shift) : "edx");
return (rv);
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettc
@@ -48,7 +53,11 @@ u_int
 __vdso_gettc(const struct vdso_timehands *th)
 {
 
+#if 0
return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32());
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettimekeep
@@ -56,5 +65,9 @@ int
 __vdso_gettimekeep(struct vdso_timekeep **tk)
 {
 
+#if 0
return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk)));
+#else
+   return (ENOSYS);
+#endif
 }
diff -aupr src.orig/lib/libc/i386/sys/__vdso_gettc.c 
src/lib/libc/i386/sys/__vdso_gettc.c
--- src.orig/lib/libc/i386/sys/__vdso_gettc.c   2017-09-29 02:20:14.0 
+0200
+++ src/lib/libc/i386/sys/__vdso_gettc.c2018-01-04 17:03:03.096724000 
+0100
@@ -30,17 +30,22 @@ __FBSDID("$FreeBSD: releng/10.4/lib/libc
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "libc_private.h"
 
 static u_int
 __vdso_gettc_low(const struct vdso_timehands *th)
 {
+#if 0
uint32_t rv;
 
__asm __volatile("rdtsc; shrd %%cl, %%edx, %0"
: "=a" (rv) : "c" (th->th_x86_shift) : "edx");
return (rv);
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettc
@@ -48,7 +53,11 @@ u_int
 __vdso_gettc(const struct vdso_timehands *th)
 {
 
+#if 0
return (th->th_x86_shift > 0 ? __vdso_gettc_low(th) : rdtsc32());
+#else
+   return (0);
+#endif
 }
 
 #pragma weak __vdso_gettimekeep
@@ -56,5 +65,9 @@ int
 __vdso_gettimekeep(struct vdso_timekeep **tk)
 {
 
+#if 0
return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk)));
+#else
+   return (ENOSYS);
+#endif
 }
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC

[Klaus P. Ohrhallinger]

On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> Hello,
> 
> I disabled the ldtsc and ldtscp instructions for usermode on one of my
> production servers:
> 

Oops, RDTSC of course.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Warner Losh]

On Thu, Jan 4, 2018 at 7:33 AM, Stefan Esser  wrote:

> Am 04.01.18 um 12:56 schrieb Darren Reed:
> > On 4/01/2018 11:51 AM, Mark Heily wrote:
> >> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
> >>
> >> The register article says the specifics are under embargo still. That
> would
> >> make it hard for anybody working with Intel to comment publicly on the
> flaw
> >> and any mitigations that may be underway. It would be unwise to assume
> that
> >> all the details are out until the embargo lifts.
> >>
> >>
> >> Details of the flaws are now published at:
> >>
> >> https://meltdownattack.com
> >
> > The web page has both: meltdown and spectre.
> > Most people are only talking about meltdown which doesn't hit AMD.
> > spectre impacts *both* Intel and AMD.
> >
> > SuSE are making available a microcode patch for AMD 17h processors that
> > disables branch prediction:
> >
> > https://lists.opensuse.org/opensuse-security-announce/
> 2018-01/msg4.html
>
> Disabling branch prediction will have a very noticeable effect on execution
> speed in general (while split page tables only affect programs that perform
> system calls at a high frequency).
>
> I have not fully read the Meltdown and Spectre papers, yet, but I do
> assume,
> that the attack at the branch prediction tries to counter KASLR, which we
> do
> not support at all in FreeBSD.
>
> So, I guess, we do not have to bother with disabling of branch prediction
> in
> FreeBSD for the time being?
>

Branch prediction has nothing to do with defeating KASLR. It's rather the
whole crux of the attack. Disabling it is one way to prevent Specter.

The only thing that will help Meltdown, though, is separate page tables.

It's only an incidental foot note that these methods don't care about KASLR
and KASLR isn't at all effective in blunting these attacks.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Chris H]

On Thu, 4 Jan 2018 15:33:46 +0100 "Stefan Esser"  said


Am 04.01.18 um 12:56 schrieb Darren Reed:
> On 4/01/2018 11:51 AM, Mark Heily wrote:
>> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>>
>> The register article says the specifics are under embargo still. That would
>> make it hard for anybody working with Intel to comment publicly on the flaw
>> and any mitigations that may be underway. It would be unwise to assume that
>> all the details are out until the embargo lifts.
>>
>>
>> Details of the flaws are now published at:
>>
>> https://meltdownattack.com
> 
> The web page has both: meltdown and spectre.

> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that

> disables branch prediction:
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html


Disabling branch prediction will have a very noticeable effect on execution
speed in general (while split page tables only affect programs that perform
system calls at a high frequency).

OUCH! That was the whole point of these; drop cores, and frequency, for huge
cache lines, and branch prediction. You eliminate that branch prediction, and
these become near useless. :-(
Glad I waited, before getting one!



I have not fully read the Meltdown and Spectre papers, yet, but I do assume,
that the attack at the branch prediction tries to counter KASLR, which we do
not support at all in FreeBSD.

So, I guess, we do not have to bother with disabling of branch prediction in
FreeBSD for the time being?

Regards, STefan

--Chris


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Stefan Esser]

Am 04.01.18 um 12:56 schrieb Darren Reed:
> On 4/01/2018 11:51 AM, Mark Heily wrote:
>> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>>
>> The register article says the specifics are under embargo still. That would
>> make it hard for anybody working with Intel to comment publicly on the flaw
>> and any mitigations that may be underway. It would be unwise to assume that
>> all the details are out until the embargo lifts.
>>
>>
>> Details of the flaws are now published at:
>>
>> https://meltdownattack.com
> 
> The web page has both: meltdown and spectre.
> Most people are only talking about meltdown which doesn't hit AMD.
> spectre impacts *both* Intel and AMD.
> 
> SuSE are making available a microcode patch for AMD 17h processors that
> disables branch prediction:
> 
> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

Disabling branch prediction will have a very noticeable effect on execution
speed in general (while split page tables only affect programs that perform
system calls at a high frequency).

I have not fully read the Meltdown and Spectre papers, yet, but I do assume,
that the attack at the branch prediction tries to counter KASLR, which we do
not support at all in FreeBSD.

So, I guess, we do not have to bother with disabling of branch prediction in
FreeBSD for the time being?

Regards, STefan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Tomoaki AOKI]

And now official announcement from Intel...

 
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr


On Wed, 3 Jan 2018 19:51:40 -0500
Mark Heily  wrote:

> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
> 
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
> 
> 
> Details of the flaws are now published at:
> 
> https://meltdownattack.com
> 
> 
> Warner
> 
> On Jan 2, 2018 4:13 PM, "Michael Butler"  wrote:
> 
> > Has any impact assessment been made as to FreeBSD's exposure or
> > mitigation strategies?
> >
> > 'Kernel memory leaking' Intel processor design flaw forces Linux,
> > Windows redesign - The Register
> >
> > Other OSes will need an update, performance hits loom A fundamental
> > design flaw in Intel's processor chips has forced a significant redesign
> > of the Linux and Windows kernels to defang the chip-level security bug.…
> > Programmers are scrambling to overhaul the open-source Linux kernel's
> > virtual memory system. Meanwhile, Microsoft is expected to publicly
> > introduce necessary changes to its Windows operating system in this
> > month's Patch Tuesday ...
> >
> > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> >
> > imb
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 


-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Darren Reed]

On 4/01/2018 11:51 AM, Mark Heily wrote:
> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
>
>
> Details of the flaws are now published at:
>
> https://meltdownattack.com

The web page has both: meltdown and spectre.
Most people are only talking about meltdown which doesn't hit AMD.
spectre impacts *both* Intel and AMD.

SuSE are making available a microcode patch for AMD 17h processors that
disables branch prediction:

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html

Kind Regards,
Darren

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[blubee blubeeme]

On Thu, Jan 4, 2018 at 8:51 AM, Mark Heily  wrote:

> On Jan 2, 2018 19:05, "Warner Losh"  wrote:
>
> The register article says the specifics are under embargo still. That would
> make it hard for anybody working with Intel to comment publicly on the flaw
> and any mitigations that may be underway. It would be unwise to assume that
> all the details are out until the embargo lifts.
>
>
> Details of the flaws are now published at:
>
> https://meltdownattack.com
>
>
> Warner
>
> On Jan 2, 2018 4:13 PM, "Michael Butler" 
> wrote:
>
> > Has any impact assessment been made as to FreeBSD's exposure or
> > mitigation strategies?
> >
> > 'Kernel memory leaking' Intel processor design flaw forces Linux,
> > Windows redesign - The Register
> >
> > Other OSes will need an update, performance hits loom A fundamental
> > design flaw in Intel's processor chips has forced a significant redesign
> > of the Linux and Windows kernels to defang the chip-level security bug.…
> > Programmers are scrambling to overhaul the open-source Linux kernel's
> > virtual memory system. Meanwhile, Microsoft is expected to publicly
> > introduce necessary changes to its Windows operating system in this
> > month's Patch Tuesday ...
> >
> > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> >
> > imb
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
This is insane...

And to think a few months ago people were complaining that Ryzen processors
and specifically Threadripper might be insecure in data centers, ha.

This is a massive clusterfk
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Mark Heily]

On Jan 2, 2018 19:05, "Warner Losh"  wrote:

The register article says the specifics are under embargo still. That would
make it hard for anybody working with Intel to comment publicly on the flaw
and any mitigations that may be underway. It would be unwise to assume that
all the details are out until the embargo lifts.


Details of the flaws are now published at:

https://meltdownattack.com


Warner

On Jan 2, 2018 4:13 PM, "Michael Butler"  wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> Other OSes will need an update, performance hits loom A fundamental
> design flaw in Intel's processor chips has forced a significant redesign
> of the Linux and Windows kernels to defang the chip-level security bug.…
> Programmers are scrambling to overhaul the open-source Linux kernel's
> virtual memory system. Meanwhile, Microsoft is expected to publicly
> introduce necessary changes to its Windows operating system in this
> month's Patch Tuesday ...
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> imb
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

More food for thought.

https://mobile.twitter.com/pwnallthethings/status/947978927284383744

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Kurt Jaeger
Sent: 02/01/2018 21:41
To: Cy Schubert
Cc: FreeBSD Current
Subject: Re: Intel CPU design flaw - FreeBSD affected?

Hi!

> You can see if your cpu supports pcid using cpuinfo from ports.

portfind cpuinfo

finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo
command ?

-- 
p...@opsec.eu+49 171 3101372 2 years to go !

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

Sorry, cpuid.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Kurt Jaeger
Sent: 02/01/2018 21:41
To: Cy Schubert
Cc: FreeBSD Current
Subject: Re: Intel CPU design flaw - FreeBSD affected?

Hi!

> You can see if your cpu supports pcid using cpuinfo from ports.

portfind cpuinfo

finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo
command ?

-- 
p...@opsec.eu+49 171 3101372 2 years to go !

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Kurt Jaeger]

Hi!

> You can see if your cpu supports pcid using cpuinfo from ports.

portfind cpuinfo

finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo
command ?

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

On January 2, 2018 4:56:48 PM PST, Michael Butler  
wrote:
>On 01/02/18 19:20, Cy Schubert wrote:
>> This Linux commit gives us a hint.
>> 
>> https://lkml.org/lkml/2017/12//27/2
>
>Sadly, the articles I've read to date make no mention of which Intel
>silicon revs are vulnerable. However, the use of the PCID feature,
>which
>is only available on more recent CPUs, does seem to afford a slightly
>lesser performance hit when completely splitting the kernel and user
>address space mappings :-(
>
>   imb

Yes.

You can see if your cpu supports pcid using cpuinfo from ports. Then look at 
input line 0x07 in the hexdump.  Bit 0x0a of rbx will indicate if invpcid is 
available. We simply need to manipulate a copy of cr3 and reload it.

My amd gear in my basement isn't affected but my laptop is. It supports pcid 
but not invpcid.

There will be a performance hit. Looking at the Linux patch, looks like the 
workaround is optional. I would suspect not through a sysctl, that would be 
silly.


---
Cy Schubert
 or 
-- small keyboard in use, apologies for typos and autocorrect --
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Michael Butler]

On 01/02/18 19:20, Cy Schubert wrote:
> This Linux commit gives us a hint.
> 
> https://lkml.org/lkml/2017/12//27/2

Sadly, the articles I've read to date make no mention of which Intel
silicon revs are vulnerable. However, the use of the PCID feature, which
is only available on more recent CPUs, does seem to afford a slightly
lesser performance hit when completely splitting the kernel and user
address space mappings :-(

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

On January 2, 2018 4:24:55 PM PST, Cy Schubert <cy.schub...@komquats.com> wrote:
>https://mobile.twitter.com/grsecurity/status/948170302286172160?p=v
>
>---
>Sent using a tiny phone keyboard.
>Apologies for any typos and autocorrect.
>Also, this old phone only supports top post. Apologies.
>
>Cy Schubert
><cy.schub...@cschubert.com> or <c...@freebsd.org>
>The need of the many outweighs the greed of the few.
>---
>
>-Original Message-
>From: Zaphod Beeblebrox
>Sent: 02/01/2018 15:50
>To: Michael Butler
>Cc: FreeBSD Current
>Subject: Re: Intel CPU design flaw - FreeBSD affected?
>
>>From the information that was leaked by AMD claiming that their
>processors
>didn't have the flaws, it would seem any OS in which the kernel
>occupies
>the same address space as the userland would be vulnerable.  The AMD
>post
>implied that Intel's speculative execution of code did not check the
>validity of the operands before speculatively executing the code.  I
>suppose the implication is that the security check "catches up" with
>the
>speculative execution at some point ... and that their (AMD's)
>microcode
>did check.
>
>Anyways... for those keeping score at home, this is a privilege
>escalation
>bug... so it's only really useful in concert with other bugs ... but
>still
>pretty huge.
>
>Some estimate that between 5% and 30% performance degradation may be
>unavoidable.  Some say it's worse or can't be fully fixed.
>
>Certainly, the sunk cost of current CPUs is a huge issue for server
>farm
>vendors like Amazon and/or google.
>
>On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler
><i...@protected-networks.net>
>wrote:
>
>> Has any impact assessment been made as to FreeBSD's exposure or
>> mitigation strategies?
>>
>> 'Kernel memory leaking' Intel processor design flaw forces Linux,
>> Windows redesign - The Register
>>
>> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>>
>>
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"
>
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"

No need for invpcid, https://patchwork.kernel.org/patch/10081791/.
---
Cy Schubert
<cy.schub...@cschubeet.com> or <c...@freebsd.org>
-- small keyboard in use, apologies for typos and autocorrect --
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Zaphod Beeblebrox
Sent: 02/01/2018 15:50
To: Michael Butler
Cc: FreeBSD Current
Subject: Re: Intel CPU design flaw - FreeBSD affected?

>From the information that was leaked by AMD claiming that their processors
didn't have the flaws, it would seem any OS in which the kernel occupies
the same address space as the userland would be vulnerable.  The AMD post
implied that Intel's speculative execution of code did not check the
validity of the operands before speculatively executing the code.  I
suppose the implication is that the security check "catches up" with the
speculative execution at some point ... and that their (AMD's) microcode
did check.

Anyways... for those keeping score at home, this is a privilege escalation
bug... so it's only really useful in concert with other bugs ... but still
pretty huge.

Some estimate that between 5% and 30% performance degradation may be
unavoidable.  Some say it's worse or can't be fully fixed.

Certainly, the sunk cost of current CPUs is a huge issue for server farm
vendors like Amazon and/or google.

On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler <i...@protected-networks.net>
wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

https://mobile.twitter.com/grsecurity/status/948170302286172160?p=v

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Zaphod Beeblebrox
Sent: 02/01/2018 15:50
To: Michael Butler
Cc: FreeBSD Current
Subject: Re: Intel CPU design flaw - FreeBSD affected?

>From the information that was leaked by AMD claiming that their processors
didn't have the flaws, it would seem any OS in which the kernel occupies
the same address space as the userland would be vulnerable.  The AMD post
implied that Intel's speculative execution of code did not check the
validity of the operands before speculatively executing the code.  I
suppose the implication is that the security check "catches up" with the
speculative execution at some point ... and that their (AMD's) microcode
did check.

Anyways... for those keeping score at home, this is a privilege escalation
bug... so it's only really useful in concert with other bugs ... but still
pretty huge.

Some estimate that between 5% and 30% performance degradation may be
unavoidable.  Some say it's worse or can't be fully fixed.

Certainly, the sunk cost of current CPUs is a huge issue for server farm
vendors like Amazon and/or google.

On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler <i...@protected-networks.net>
wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Intel CPU design flaw - FreeBSD affected?

[Cy Schubert]

This Linux commit gives us a hint.

https://lkml.org/lkml/2017/12//27/2

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Warner Losh
Sent: 02/01/2018 16:05
To: Michael Butler
Cc: FreeBSD Current
Subject: Re: Intel CPU design flaw - FreeBSD affected?

The register article says the specifics are under embargo still. That would
make it hard for anybody working with Intel to comment publicly on the flaw
and any mitigations that may be underway. It would be unwise to assume that
all the details are out until the embargo lifts.

Warner

On Jan 2, 2018 4:13 PM, "Michael Butler" <i...@protected-networks.net> wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> Other OSes will need an update, performance hits loom A fundamental
> design flaw in Intel's processor chips has forced a significant redesign
> of the Linux and Windows kernels to defang the chip-level security bug.…
> Programmers are scrambling to overhaul the open-source Linux kernel's
> virtual memory system. Meanwhile, Microsoft is expected to publicly
> introduce necessary changes to its Windows operating system in this
> month's Patch Tuesday ...
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> imb
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Warner Losh]

The register article says the specifics are under embargo still. That would
make it hard for anybody working with Intel to comment publicly on the flaw
and any mitigations that may be underway. It would be unwise to assume that
all the details are out until the embargo lifts.

Warner

On Jan 2, 2018 4:13 PM, "Michael Butler"  wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> Other OSes will need an update, performance hits loom A fundamental
> design flaw in Intel's processor chips has forced a significant redesign
> of the Linux and Windows kernels to defang the chip-level security bug.…
> Programmers are scrambling to overhaul the open-source Linux kernel's
> virtual memory system. Meanwhile, Microsoft is expected to publicly
> introduce necessary changes to its Windows operating system in this
> month's Patch Tuesday ...
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> imb
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel CPU design flaw - FreeBSD affected?

[Zaphod Beeblebrox]

>From the information that was leaked by AMD claiming that their processors
didn't have the flaws, it would seem any OS in which the kernel occupies
the same address space as the userland would be vulnerable.  The AMD post
implied that Intel's speculative execution of code did not check the
validity of the operands before speculatively executing the code.  I
suppose the implication is that the security check "catches up" with the
speculative execution at some point ... and that their (AMD's) microcode
did check.

Anyways... for those keeping score at home, this is a privilege escalation
bug... so it's only really useful in concert with other bugs ... but still
pretty huge.

Some estimate that between 5% and 30% performance degradation may be
unavoidable.  Some say it's worse or can't be fully fixed.

Certainly, the sunk cost of current CPUs is a huge issue for server farm
vendors like Amazon and/or google.

On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler 
wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"