Intel CPU design flaw - FreeBSD affected?

Discussion:

(too old to reply)

Michael Butler

2018-01-02 23:13:44 UTC

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

Zaphod Beeblebrox

2018-01-02 23:49:57 UTC

Permalink

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.

Cy Schubert

2018-01-03 00:20:00 UTC

Permalink

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
<***@cschubert.com> or <***@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

Post by Michael Butler
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

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

Michael Butler

2018-01-03 00:56:48 UTC

Permalink

Post by Cy Schubert
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

Kurt Jaeger

2018-01-03 05:39:57 UTC

Permalink

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 ?

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

Cy Schubert

2018-01-03 00:24:17 UTC

Permalink

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

Cy Schubert
<***@cschubert.com> or <***@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?

Post by 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.

Post by Zaphod Beeblebrox
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/

Cy Schubert

2018-01-03 00:24:55 UTC

Permalink

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
<***@cschubert.com> or <***@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?

Post by Zaphod Beeblebrox
From the information that was leaked by AMD claiming that their processors

Cy Schubert

2018-01-03 00:56:16 UTC

Permalink

Post by 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
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?

Post by 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

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

No need for invpcid, https://patchwork.kernel.org/patch/10081791/.
---
Cy Schubert
<***@cschubeet.com> or <***@freebsd.org>
-- small keyboard in use, apologies for typos and autocorrect --

Cy Schubert

2018-01-03 06:05:28 UTC

Permalink

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
<***@cschubert.com> or <***@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 ?

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

Mark Heily

2018-01-04 00:51:40 UTC

Permalink

On Jan 2, 2018 19:05, "Warner Losh" <***@bsdimp.com> 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

blubee blubeeme

2018-01-04 01:39:49 UTC

Permalink

Post by Cy Schubert
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.
https://meltdownattack.com
Warner

freebsd.org"
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

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

Darren Reed

2018-01-04 11:56:11 UTC

Permalink

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/msg00004.html

Kind Regards,
Darren

Stefan Esser

2018-01-04 14:33:46 UTC

Permalink

Post by Darren Reed

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
https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.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

Warner Losh

2018-01-04 16:29:16 UTC

Permalink

Post by Darren Reed

Post by Cy Schubert
The register article says the specifics are under embargo still. That

would

Post by Darren Reed

Post by Cy Schubert
make it hard for anybody working with Intel to comment publicly on the

flaw

Post by Darren Reed

Post by Cy Schubert
and any mitigations that may be underway. It would be unwise to assume

that

Post by Darren Reed

Post by Cy Schubert
all the details are out until the embargo lifts.
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
https://lists.opensuse.org/opensuse-security-announce/

2018-01/msg00004.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

Tomoaki AOKI

2018-01-04 14:26:31 UTC

Permalink

And now official announcement from Intel...

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

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

Post by Michael Butler
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.$B!D(B
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

--
Tomoaki AOKI <***@dec.sakura.ne.jp>

Klaus P. Ohrhallinger

2018-01-04 18:25:56 UTC

Permalink

Hello,
I disabled the ldtsc and ldtscp instructions for usermode on one of my

Oops, RDTSC of course.

blubee blubeeme

2018-01-04 18:27:40 UTC

Permalink

Post by Klaus P. Ohrhallinger

Hello,
I disabled the ldtsc and ldtscp instructions for usermode on one of my

Oops, RDTSC of course.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

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...

Andrew Reilly

2018-01-06 02:30:29 UTC

Permalink

Post by blubee blubeeme
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

Klaus P. Ohrhallinger

2018-01-04 18:23:56 UTC

Permalink

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

Jan Kokemüller

2018-01-04 18:51:12 UTC

Permalink

Post by Klaus P. Ohrhallinger
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/

Klaus P. Ohrhallinger

2018-01-04 19:59:56 UTC

Permalink

Post by Jan KokemÃ¼ller
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)

Michael Butler

2018-01-04 21:07:19 UTC

Permalink

Post by Klaus P. Ohrhallinger

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 ?
---
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&languageid=en-fr

imb

Conrad Meyer

2018-01-04 21:43:35 UTC

Permalink

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

Post by Michael Butler

Post by Klaus P. Ohrhallinger

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 ?
---
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&languageid=en-fr
imb
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

Klaus P. Ohrhallinger

2018-01-06 10:31:50 UTC

Permalink

Post by Michael Butler
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&languageid=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.

Mark Millard

2018-01-05 03:32:13 UTC

Permalink

Darren Reed darrenr at freebsd.org wrote on

Post by Darren Reed
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
https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.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

Mark Millard

2018-01-06 22:02:39 UTC

Permalink

Post by Mark Millard
Darren Reed darrenr at freebsd.org wrote on

https://www.amd.com/en/corporate/speculative-execution
reports. . .
Resolved by software / OS updates to be made available
by system vendors and manufacturers. Negligible performance
impact expected.
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.
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&px=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

Mark Millard

2018-01-12 05:11:59 UTC

Permalink

Post by Mark Millard

Post by Mark Millard
Darren Reed darrenr at freebsd.org wrote on

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Branch-Prediction-Still
reports that SUSE's microcode update for AMD's Zen/17h does
not disable branch prediction, despite SUSE's existing
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