Intel hardware bug
Mike Tancsa
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
Lev Serebryakov
Wednesday, January 3, 2018, 4:56:50 AM, you wrote:
> No way around it. It's hardware FAIL, and ignoring it isn't an option since
> it's apparently a huge hole.
Looks like there IS way around it and it was "silently" committed to Linux
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
But TLB flush on each syscall (twice) will slow down system, of course, so
there should be option to disable it.
--
Best regards,
Lev mailto:l...@FreeBSD.org
Royce Williams
> Hello Joey,
>
> Wednesday, January 3, 2018, 4:56:50 AM, you wrote:
>
> > No way around it. It's hardware FAIL, and ignoring it isn't an option
> since
> > it's apparently a huge hole.
> Looks like there IS way around it and it was "silently" committed to Linux
>
> http://pythonsweetness.tumblr.com/post/169166980422/the-
> mysterious-case-of-the-linux-page-table
>
> But TLB flush on each syscall (twice) will slow down system, of course, so
> there should be option to disable it.
>
https://gist.github.com/dougallj/f9ffd7e37db35ee953729491cfb71392
Royce
Bryan Drewery
> I am guessing this will impact FreeBSD as well ?
>
> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
statement from FreeBSD will likely be made before it is lifted. I do
know that the right people are definitely aware of what's going on.
--
Regards,
Bryan Drewery
Ronald F. Guilmette
In message <477ab39d-286d-d9a2...@sentex.net>,
>I am guessing this will impact FreeBSD as well ?
>
>http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Why couldn't this have been announced the week -before- I bought an Intel
processor and motherboard to replace my aging AMD rig, rather than the week
-after- I did so?
Geeeesssh!
Eric van Gyzen
>
> In message <477ab39d-286d-d9a2...@sentex.net>,
> Mike Tancsa <mi...@sentex.net> wrote:
>
>> I am guessing this will impact FreeBSD as well ?
>>
>> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> Swell. Just swell.
>
> Why couldn't this have been announced the week -before- I bought an Intel
> processor and motherboard to replace my aging AMD rig, rather than the week
> -after- I did so?
>
> Geeeesssh!
not a "bug" in Intel CPUs.
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Eric
Julian H. Stacey
> I am guessing this will impact FreeBSD as well ?
> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
https://lkml.org/lkml/2017/12/4/709
[patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)
https://gruss.cc/files/kaiser.pdf Funded by ERC & EU
KASLR is Dead: Long Live KASLR
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
July 28, 2017
The mysterious case of the Linux Page Table Isolation patches
... Ref to FreeBSD
http://www.bbc.co.uk/news/technology-42553818
Major flaw in millions of Intel chips revealed
https://www.theguardian.com/technology/2018/jan/03/major-security-flaw-found-intel-processors-computers-windows-mac-os-linux
Wed 3 Jan `18 14.24 GMT
Major security flaw found in Intel processors
https://twitter.com/aionescu/status/948609809540046849
9:39 AM - 3 Jan 2018
MacOS fix the Intel #KPTI Issue? Why yes ... since 10.13.2
https://twitter.com/aionescu/status/948609809540046849
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx?source=isesitlnk0000001&mrr=1.00
Dec 19, 2017 at 5:10PM
Intel's CEO Just Sold A Lot of StocK ..
Krzanich is keeping the bare minimum
https://github.com/IAIK/KAISER/
Kernel Address Isolation to have Side-channels Efficiently Removed
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Upgrades inc reboots of lots of commercial global net servers is
predicted once patches are out for each OS in a few days. I wonder
what keywords industry will settle on to refer to this by (eg last
time "FOOF bug") Options inc.: KASLR, KAISER, Kernel Address tables,
Intel software mitigation, x86/kpti: Kernel Page Table Isolation.
I don't know what effect this has on FreeBSD, I guess we'll see an
authoritative announcement in a bit, when memory management people
get time to stop coding & drop back to PR, Meanwhile:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/bibliography-osinternals.html
https://duckduckgo.com/?sites=www.FreeBSD.org%2Cdocs.FreeBSD.org%2Clists.FreeBSD.org%2Cwiki.FreeBSD.org%2Cforums.FreeBSD.org&ka=v&kt=v&kh=1&kj=r2&q=memory+management&submit=Search&ia=web
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/page-table-optimizations.html
https://forums.freebsd.org/threads/63955/page-2
Cheers,
Julian
--
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich
http://berklix.eu/brexit/ UK stole 3,700,000 votes; 700,000 from Brits in EU.
http://berklix.eu/queen/ Sign petition before end of 2017.
David M. Syzdek
> On Jan 3, 2018, at 11:59 AM, Eric van Gyzen <vang...@FreeBSD.org> wrote:
>
> On 01/03/2018 14:48, Ronald F. Guilmette wrote:
>>
>> In message <477ab39d-286d-d9a2...@sentex.net>,
>> Mike Tancsa <mi...@sentex.net> wrote:
>>
>>> I am guessing this will impact FreeBSD as well ?
>>>
>>> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>>
>> Swell. Just swell.
>>
>> Why couldn't this have been announced the week -before- I bought an Intel
>> processor and motherboard to replace my aging AMD rig, rather than the week
>> -after- I did so?
>>
>> Geeeesssh!
>
> Wait until Tuesday before you explode. Intel are now saying that it's
> not a "bug" in Intel CPUs.
>
> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
>
> Eric
It looks more like they are playing fast and loose with words. From the article you linked:
Intel believes these exploits do not have the potential to corrupt, modify or delete data.
and
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
They did not say it is *NOT* a bug, just that it is not a bug unique to Intel. I’ve not seen speculation regarding the “bug” being able to corrupt, modify, or delete data, I’ve only seen speculation that the bug allows unprivileged processes to see privileged memory/cache.
Additionally, they indirectly imply that both AMD and ARM chips are affected by the same bug, however this is, at least in AMD’s case, appears to be directly refuted by a patch submitted to the Linux kernel by AMD:
https://lkml.org/lkml/2017/12/27/2 <https://lkml.org/lkml/2017/12/27/2>
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Since other statements are misleading, it could be that the “workloads” being described could be a hibernated laptop; a halted firewall (where the firewall/routing rules are still running in the kernel); a lightweight user who only uses e-mail and facebook; etc:
Contrary to some reports, any performance impacts are workload-dependent,
and, for the average computer user, should not be significant and will be mitigated
over time.
Finally their belief of being the most secure products in the world and actual reality may differ:
Intel believes its products are the most secure in the world and that, with the support of
its partners, the current solutions to this issue provide the best possible security for its
customers.
I generally read a company’s press releases in response to negative publicity with the assumption that they are not lying, but are obfuscating the truth or dancing around an issue in order to cast themselves in the best possible light. The proof that this tactic works is that Eric interpreted the release to say that there is not a bug in Intel’s hardware instead of Intel is one of many vendors whose product has this bug (though this remains to be seen).
—David M. Syzdek
Shawn Webb
> I am guessing this will impact FreeBSD as well ?
>
> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
Tor-ified Signal: +1 443-546-8752
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
Ronald F. Guilmette
In message <02563ce4-437c-ab96...@FreeBSD.org>,
>not a "bug" in Intel CPUs.
I say again: Sheeeeeeeessssshhh!
Just within the last three months, we first had:
"All your WPA2 WiFi are belong to us!"
and now, to add insult to injury, we get:
"All your Intel *and* ARM CPUs are belong to us!"
Obviously, the enemy is what it has always been... complexity. All this stuff
is just so hellishly complex nowadays that no single human can grasp and hold
even a significant fraction of these things in their minds at any one time.
The result is as inevitable as it is predictable. Our machines are making us
substantially *less* secure.
But I guess that I personally don't have nearly as much reason to bitch and
moan as, for example, any origanization that managed or is managing some vast
fleet of WiFi hardware (HomeDepot?), or any of the cloud computing vendors who
have just seen perhaps 30% of their installed compute power go up in smoke,
virtually overnight. If anybody has ample reason to be royally pissed off
about all of this nonsense, then it is surely those folks, more than me.
Regards,
rfg
P.S. Right about now, I'd like to have a job working for whichever big ad
agency has the AMD account. The ad copy for AMD's next marketing campaign
practically writes itself... "Performance without penality!"
Oliver Pinter
> On Wednesday, January 03, 2018 02:59:35 PM Eric van Gyzen wrote:
>
> >
> > Wait until Tuesday before you explode. Intel are now saying that it's
> > not a "bug" in Intel CPUs.
> >
> > https://newsroom.intel.com/news/intel-responds-to-
> security-research-findings
> > /
>
Nope. See this part of announcement :
"Intel believes these exploits do not have the potential to corrupt, modify
compromising. ;)
>
> --
> Joey Kelly
> Minister of the Gospel and Linux Consultant
> http://joeykelly.net
> 504-239-6550
Brett Glass
leaks. Some Intel processors without speculative execution - such as the
Atom CPUs (including the embedded ones) - won't be affected,
whereas the bigger,
fancier i3, i5, i7, and Xeon processors will. It's unclear on which side of the
line the Atom C2000 series (which had out-of-order but not
speculative execution)
will lie.
Hopefully, when FreeBSD develops kernel patches to address the bug, it will
exempt the unaffected processors. (I do a lot of work for embedded
Atoms, and hope
that they will not be slowed by patches intended for CPUs that actually need
them.)
--Brett Glass
At 06:56 PM 1/2/2018, Joey Kelly wrote:
>On Tuesday, January 02, 2018 08:52:27 PM Mike Tancsa wrote:
> > I am guessing this will impact FreeBSD as well ?
> >
> > http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>it's apparently a huge hole.
>
Dag-Erling Smørgrav
> They did not say it is *NOT* a bug, just that it is not a bug unique
> ARM chips are affected by the same bug, however this is, at least in
There are three different issues. One of them (CVE-2017-5754, labeled
“Meltdown”) is easily mitigated and has so far only been shown to affect
Intel processors. The other two (CVE-2017-5753 and CVE-2017-5715,
collectively labeled “Spectre”) affect AMD and ARM processors as well
and have no known workaround.
So far, it has been shown that an unprivileged process can read data
from the kernel (Meltdown) and other processes (Spectre), and that a
privileged process in a VM can read data from the host and presumably
also from other VMs on the same host (Spectre).
DES
--
Dag-Erling Smørgrav - d...@des.no
Eric McCorkle
> "David M. Syzdek" <david....@acsalaska.net> writes:
>> They did not say it is *NOT* a bug, just that it is not a bug unique
>> to Intel. [...] Additionally, they indirectly imply that both AMD and
>> ARM chips are affected by the same bug, however this is, at least in
>> AMD’s case, appears to be directly refuted [...] by AMD:
>
> There are three different issues. One of them (CVE-2017-5754, labeled
> “Meltdown”) is easily mitigated and has so far only been shown to affect
> Intel processors. The other two (CVE-2017-5753 and CVE-2017-5715,
> collectively labeled “Spectre”) affect AMD and ARM processors as well
> and have no known workaround.
>
> So far, it has been shown that an unprivileged process can read data
> from the kernel (Meltdown) and other processes (Spectre), and that a
> privileged process in a VM can read data from the host and presumably
> also from other VMs on the same host (Spectre).
That right there is enough to pluck things like TLS session keys, GELI
master keys, and anything else on that level out of kernel memory.
Given enough skill, resources, and motivation, it's likely that an
attacker could craft a javascript-based version of the attack, then
every javascript website (aka all of them) is a potential attack vector.
Ronald F. Guilmette
In message <2347560.A...@elisha.atlnet>,
Joey Kelly <jo...@joeykelly.net> wrote:
>...
>No, I mean their lame excuses, dances around the truth, claiming many other
>platforms AND OPERATING SYSTEMS do it too. 'Tain't so. This is hardware, INTEL
>hardware, and not an OS problem...
While it is clearly true, even from the current very preliminary reports, that
this is indeed a hardware issue, rather than an OS issue, you may want to reserve
judgement about the possibility that this thing is confined only to Intel hardware.
Intel, of course, has said that they believe that this bug may also affect
AMD and also ARM CPUs. (But then they would say that, wouldn't they?) But
AMD, for its part, has already put out a public statement saying that their
CPUs are not affected.
So now, the other shoe that we should all be expecting to drop, any time now,
is some public statement from ARM Holdings, PLC. If one has already been issued
by that company, then Google News doesn't seem to be giving me any easy way to
find it, and there is nothing of relevance on the ARM corporate web site
(www.arm.com). So I suspect that they haven't said anything yet, which is
itself a rather ominous data point.
If it turns out that this same bug, or same sort of bug, also affects ARM-based
chips, then that is quite possibly an even bigger deal than the already obvious
Intel cataclysm.
Regards,
rfg
P.S. It occured to me today just how much this bug, and the still-fresh WPA2
insecurities, are likely to cost -- said costs to be paid by an entire planet's
worth of both individuals and businesses. I believe that it may be a conservative
estimate to say that each one of these cock ups may cost the global economy
something in the range of tens of billions of dollars, or perhaps even more.
Immediately following on the heals of this thought, a somewhat humorous idea
occured to me...
These days we have bug bounty programs which pay people to find bugs, in particular,
security-rlated bugs. And perhaps as a result, nowadays we have a bumper crop of
them to deal with.
In contrast to that, for the past many decades, at least, in my country,
at least, when there is an excess of some commodity... e.g. wheat, or corn,
or some such thing... the government pays farmers to NOT grow that specific
commodity.
Given the gigantic global costs resulting from these ever-more-horrendous bugs
that clever researchers are out there discovering, nowadays, on a regular basis,
perhaps we should be paying people to NOT find bugs. That might be more cost
effective, in the long run.
And there is some precedent for this kind of counter-intutive reward system,
and not just in the field (excuse the pun) of agricultural commodities...
https://www.washingtonpost.com/local/paying-criminals-not-to-commit-crime-may-not-be-so-funny-after-all/2016/02/08/151ab936-cea3-11e5-b2bc-988409ee911b_story.html
http://www.foxnews.com/politics/2016/08/24/one-california-city-is-paying-people-not-to-commit-crimes.html
http://www.guns.com/2017/09/01/sacramento-city-council-approves-1-5-million-program-to-combat-gun-violence/
Ronald F. Guilmette
In message <0bb7ffc6-fa51-98db...@metricspace.net>,
>Given enough skill, resources, and motivation, it's likely that an
>attacker could craft a javascript-based version of the attack, then
>every javascript website (aka all of them) is a potential attack vector.
to take issue with your use of future tense in this context.
Unless you have access to the innermost compartmentalized data sources of
at least all of NSA, FSB, and Mossad, I think it qualifies as being, at best,
speculation to believe that none of the proverbial "state actors" have managed
to stumble upon any of these horrendous security problems which are alleged
to have been present already for a good decade or more, in chips used in and
distributed throughout the entire world.
Data isolation between unrelated user-level processes and between user-level
processes and the kernel is, as I understand it, the bedrock upon which
essentially all computer security rests. As such, it would seem to be
a thing that would likely have been poked and prodded, relentlessly, by any
actor which, during the past ten years or more, has yearned for unlimited
knowledge about friends, enemies, or both. Can we know that none of them
"crafted a javascript-based version of the attack" against any of these
several issues already, and perhaps even years ago? (They might have done
so and then, realizing the value of what they found, compartmentalized the
information in a place where even Snowden would never have been aware of it.)
Alright. So call me paranoid, if you like. But I seem to dimly recall that
there was some executive at some Silicon Valley based semiconductor company
who, years ago, advised people that paranoia might actually be an admirable
quality, at least for those wishing to survive.
Regards,
rfg
Erich Dollansky
On Wed, 03 Jan 2018 16:29:12 -0800
"Ronald F. Guilmette" <r...@tristatelogic.com> wrote:
> In message <02563ce4-437c-ab96...@FreeBSD.org>,
> Eric van Gyzen <vang...@FreeBSD.org> wrote:
>
> Obviously, the enemy is what it has always been... complexity. All
the 8086 with many thing 'reserved for future use' but nobody cared.
Intel used segments to separate things everybody hated.
Intel introduced later the rings, everybody ignored.
Instead of keeping the things separated - as suggested by Intel's
design - people used shortcuts whenever possible.
People would have had to think a bit more those days.
But Darwin was not sleeping and people have to think now.
> this stuff is just so hellishly complex nowadays that no single human
> can grasp and hold even a significant fraction of these things in
like Intel suggested in the Seventies and Eighties.
> P.S. Right about now, I'd like to have a job working for whichever
> big ad agency has the AMD account. The ad copy for AMD's next
> marketing campaign practically writes itself... "Performance without
> penality!"
Erich
Steven Hartland
> In message <2347560.A...@elisha.atlnet>,
> Joey Kelly <jo...@joeykelly.net> wrote:
>
>> ...
>> No, I mean their lame excuses, dances around the truth, claiming many other
>> platforms AND OPERATING SYSTEMS do it too. 'Tain't so. This is hardware, INTEL
>> hardware, and not an OS problem...
> While it is clearly true, even from the current very preliminary reports, that
> this is indeed a hardware issue, rather than an OS issue, you may want to reserve
> judgement about the possibility that this thing is confined only to Intel hardware.
>
> Intel, of course, has said that they believe that this bug may also affect
> AMD and also ARM CPUs. (But then they would say that, wouldn't they?) But
> AMD, for its part, has already put out a public statement saying that their
> CPUs are not affected.
>
> So now, the other shoe that we should all be expecting to drop, any time now,
> is some public statement from ARM Holdings, PLC. If one has already been issued
> by that company, then Google News doesn't seem to be giving me any easy way to
> find it, and there is nothing of relevance on the ARM corporate web site
> (www.arm.com). So I suspect that they haven't said anything yet, which is
> itself a rather ominous data point.
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
> If it turns out that this same bug, or same sort of bug, also affects ARM-based
> chips, then that is quite possibly an even bigger deal than the already obvious
> Intel cataclysm.
>
>
> Regards,
> rfg
>
Dag-Erling Smørgrav
> Given enough skill, resources, and motivation, it's likely that an
> attacker could craft a javascript-based version of the attack, then
> every javascript website (aka all of them) is a potential attack vector.
Uh, this has already been demonstrated. According to Google, Chrome 64
(to be released in a few days) includes countermeasures against it. I
don't have any further details.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Intel used segments to separate things everybody hated.
Everybody hated segment-level memory protection, but the i386 also
introduced page-level memory protection, which was widely used and has
since been expanded to provide features that were never available at the
segment level.
> Intel introduced later the rings, everybody ignored.
Not at all. They just don't use all four. Unless you start looking at
hardware virtualization extensions, which introduce additional
protection levels.
> Instead of keeping the things separated - as suggested by Intel's
> design - people used shortcuts whenever possible.
This is irrelevant. We are talking about timing-based side-channel
attacks. The attacker is not able to access protected memory directly,
but is able to deduce its contents by repeatedly performing illegal
memory accesses and then checking how they affect the cache.
DES
--
Dag-Erling Smørgrav - d...@des.no
Eric McCorkle
> Eric McCorkle <er...@metricspace.net> writes:
>> Given enough skill, resources, and motivation, it's likely that an
>> attacker could craft a javascript-based version of the attack, then
>> every javascript website (aka all of them) is a potential attack vector.
>
> Uh, this has already been demonstrated. According to Google, Chrome 64
> (to be released in a few days) includes countermeasures against it. I
> don't have any further details.
This does not surprise me at all.
Brett Glass
>This is irrelevant. We are talking about timing-based side-channel
>attacks. The attacker is not able to access protected memory directly,
>but is able to deduce its contents by repeatedly performing illegal
>memory accesses and then checking how they affect the cache.
on the list can help explain it to me. The "Spectre" attack is claimed
to work by altering the contents of the cache via a speculatively
executed instruction. But the contents of that memory are not revealed
directly to the program. So, how does it deduce the contents of physical
memory merely from the fact that there's a cache miss on its address?
--Brett Glass
Eric McCorkle
> At 08:01 AM 1/4/2018, Dag-Erling Smørgrav wrote:
>
>> This is irrelevant. We are talking about timing-based side-channel
>> attacks. The attacker is not able to access protected memory directly,
>> but is able to deduce its contents by repeatedly performing illegal
>> memory accesses and then checking how they affect the cache.
>
> This is something I do not yet fully understand; perhaps someone here
> on the list can help explain it to me. The "Spectre" attack is claimed
> to work by altering the contents of the cache via a speculatively
> executed instruction. But the contents of that memory are not revealed
> directly to the program. So, how does it deduce the contents of physical
> memory merely from the fact that there's a cache miss on its address?
You can speculatively execute code based on the value of a fetched
memory address, which may eventually fault. This can be used to pull
things into cache, which can then be measured.
The attack looks like this:
1) Fetch kernel/other process memory, which eventually faults
2) Do a bit-shift/mask operation to pluck out one bit of the fetched
value. This gets executed speculatively on the fetched value in (1).
3) Execute fetches of two different addresses depending on some bit in
the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This
also gets executed speculatively despite the fact that (1) ends up faulting.
4) Recover from fault in (1)
5) Measure performance of accesses to the two addresses to determine
which one is cached.
The really terrible thing about this is that it suggests a *class* of
attacks: side-channels based on CPU implementations, of which this is
the first (and most obvious) one to be discovered. I suspect this is
going to be dogging us for years to come.
Brett Glass
>The attack looks like this:
>
>1) Fetch kernel/other process memory, which eventually faults
>2) Do a bit-shift/mask operation to pluck out one bit of the fetched
>value. This gets executed speculatively on the fetched value in (1).
>3) Execute fetches of two different addresses depending on some bit in
>the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This
>also gets executed speculatively despite the fact that (1) ends up faulting.
>4) Recover from fault in (1)
>5) Measure performance of accesses to the two addresses to determine
>which one is cached.
fatal rather than allowing recovery to occur. Of course, this would
reveal errors
in sloppy code, which some developers would not like. (I recall how much some
folks squawked back in the olden days, when segmentation faults - remember
segments? - revealed bugs in their code. I, personally, liked segmentation
because I was a perfectionist.... I wanted my code to crash dramatically if
there was an error so I could fix it.)
--Brett Glass
Eric McCorkle
> At 09:03 AM 1/4/2018, Eric McCorkle wrote:
>
>> The attack looks like this:
>>
>> 1) Fetch kernel/other process memory, which eventually faults
>> 2) Do a bit-shift/mask operation to pluck out one bit of the fetched
>> value. This gets executed speculatively on the fetched value in (1).
>> 3) Execute fetches of two different addresses depending on some bit in
>> the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This
>> also gets executed speculatively despite the fact that (1) ends up
>> faulting.
>> 4) Recover from fault in (1)
>> 5) Measure performance of accesses to the two addresses to determine
>> which one is cached.
>
> Hmmmm. The obvious way to combat this would be to make this class of fault
> fatal rather than allowing recovery to occur. Of course, this would
> reveal errors
> in sloppy code, which some developers would not like. (I recall how much
> some
> folks squawked back in the olden days, when segmentation faults - remember
> segments? - revealed bugs in their code. I, personally, liked segmentation
> because I was a perfectionist.... I wanted my code to crash dramatically if
> there was an error so I could fix it.)
>
That breaks the entire way that page faults and virtual memory works,
though. You could block meltdown, I suppose, by making the entire
kernel address space absolutely forbidden under penalty of an
uncatchable signal.
This won't stop spectre (same attack against another process' pages), or
a similar attack within the same address space (say, to break out of
some kind of intra-process isolation).
Eric McCorkle
> You could block meltdown, I suppose, by making the entire
> kernel address space absolutely forbidden under penalty of an
> uncatchable signal.
and could be measured by another core.
I suppose you could attempt to flush them upon killing a process in this
way, but you still have a window, so it's only a probabilistic defense.
Erich Dollansky
On Thu, 04 Jan 2018 16:01:51 +0100
Dag-Erling Smørgrav <d...@des.no> wrote:
> Erich Dollansky <freebsd....@sumeritec.com> writes:
> > Intel used segments to separate things everybody hated.
>
> Everybody hated segment-level memory protection, but the i386 also
good that hate is meanwhile illegal.
> introduced page-level memory protection, which was widely used and has
> since been expanded to provide features that were never available at
> the segment level.
Yes, but instead of combining both, the segment registers were set to
point to the same memory locations disabling the additional protection
given by the segments.
>
> > Intel introduced later the rings, everybody ignored.
>
> Not at all. They just don't use all four. Unless you start looking
> at hardware virtualization extensions, which introduce additional
> protection levels.
It was just abusing them to replace the supervisor flag other
processors have or have had.
>
> > Instead of keeping the things separated - as suggested by Intel's
> > design - people used shortcuts whenever possible.
>
> This is irrelevant. We are talking about timing-based side-channel
> attacks. The attacker is not able to access protected memory
> directly, but is able to deduce its contents by repeatedly performing
> illegal memory accesses and then checking how they affect the cache.
Directly yes, not if the kernel memory would be always in a different
segment. It would land then in cache only when memory near segment
bounds are accessed. Which could be easily avoided.
Anyway, we cannot turn the clock back now. I just wanted to mention
that Intel has had different thoughts those days. I am not even sure if
Intel engineers remember this.
Erich
Dag-Erling Smørgrav
> [much elided]
> Directly yes, not if the kernel memory would be always in a different
> segment. It would land then in cache only when memory near segment
> bounds are accessed. Which could be easily avoided.
Are you familiar with the expression “not even wrong”?
DES
--
Dag-Erling Smørgrav - d...@des.no
Ronald F. Guilmette
In message <736a2b77-d4a0-b03f...@metricspace.net>,
>The attack looks like this:
>
>1) Fetch kernel/other process memory, which eventually faults
>2) Do a bit-shift/mask operation to pluck out one bit of the fetched
>value. This gets executed speculatively on the fetched value in (1).
>3) Execute fetches of two different addresses depending on some bit in
>the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This
>also gets executed speculatively despite the fact that (1) ends up faulting.
>4) Recover from fault in (1)
>5) Measure performance of accesses to the two addresses to determine
>which one is cached.
you wern't supposed to have access to. But of course, that doesn't really
matter if you are an attacker.
If the above steps can be repeated, programatically, ad infinitum, to read
bits from "protected" memory... and I see no reason why they can't be...
then yea, this bug is every bit as bad as the media is making it out to be,
and maybe even worse.
All your secrets are belong to us!
Time to invest in abacuses... or is that abacai?
Regards,
rfg
Karsten König
On 05.01.2018 11:07, Jules Gilbert via freebsd-security wrote:
> Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no one!, has in the past, or will in the future be able to exploit this to actually do something not nice.
> I'm not saying that the hardware shouldn't be fixed, I am saying that we don't need to worry about this.
we should indeed worry about this. This could be just the tip of the
iceberg. Think about Rowhammer. This was a bug which affected RAM. In
the beginning it was just some basic computer science research which was
hard to trigger. After some month people found ways to exploit Rowhammer
via JavaScript so that every person using a browser was a possible target.
The same could happen with this stuff, people are already working on this.
Best,
Karsten
> In the early days of DOS their was a hardware bug in nearly all floppy controllers, it wasn't even discovered until (I think,) 1985 or so. The thing is..., no one reported unusual problems.
> So what is this, really?, it's a market exploit opportunity for AMD.
Jules Gilbert via freebsd-security
But their are several people here I respect very much and if they say I'm wrong about an area they focus on,... me bad.
On Friday, January 5, 2018, 9:48:50 AM EST, Dag-Erling Smørgrav <d...@des.no> wrote:
Jules Gilbert <repeatable_...@yahoo.com> writes:
> Sorry guys, you just convinced me that no one, not the NSA, not the
> FSB, no one!, has in the past, or will in the future be able to
> exploit this to actually do something not nice.
The technique has already been proven by multiple independent parties to
work quite well, allowing an attacker to read kernel memory at speeds of
up to 500 kB/s. But I guess you know better...
DES
--
Dag-Erling Smørgrav - d...@des.no
Eric McCorkle
> POWER has the same thing. It's actually stronger separation, since user
> processes don't share addresses either -- all processes, including the
> kernel, have windowed access to an 80-bit address space, so no process
> can even describe an address in another process's address space. There
> are ways, of course, in which IBM could have messed up the
> implementation, so the fact that it *should* be secure does not mean it
> *is*.
That's interesting, as it conflicts with Red Hat's vulnerability
disclosure. It that because the silicon is buggy, or because Linux
somehow ends up being vulnerable when it need not be?
>
> SPARC avoids the issue because almost all implementations are in-order.
Definitely not true of the post-Oracle models. I saw a tech talk on the
core once.
Cameron, Frank J
> On 01/05/2018 11:40, Nathan Whitehorn wrote:
> > POWER has the same thing. It's actually stronger separation, since user
> > processes don't share addresses either -- all processes, including the
> > kernel, have windowed access to an 80-bit address space, so no process
> > can even describe an address in another process's address space. There
> > are ways, of course, in which IBM could have messed up the
> > implementation, so the fact that it *should* be secure does not mean it
> > *is*.
>
> That's interesting, as it conflicts with Red Hat's vulnerability
> disclosure. It that because the silicon is buggy, or because Linux
> somehow ends up being vulnerable when it need not be?
involves installing patches to both system firmware and operating
systems. The firmware patch provides partial remediation to this
vulnerability and is a pre-requisite for the OS patch to be effective."
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
-----------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may contain
company proprietary information. If you are not the intended
recipient, notify the sender immediately and delete this
message. Publication, reproduction, forwarding, or content
disclosure is prohibited without the consent of the original
sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
-----------------------------------------------------------------
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.Sc...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---
-----Original Message-----
From: Eric McCorkle
Sent: 05/01/2018 10:45
To: freebsd-...@freebsd.org
Subject: Re: Intel hardware bug
On 01/05/2018 11:40, Nathan Whitehorn wrote:
> POWER has the same thing. It's actually stronger separation, since user
> processes don't share addresses either -- all processes, including the
> kernel, have windowed access to an 80-bit address space, so no process
> can even describe an address in another process's address space. There
> are ways, of course, in which IBM could have messed up the
> implementation, so the fact that it *should* be secure does not mean it
> *is*.
That's interesting, as it conflicts with Red Hat's vulnerability
disclosure. It that because the silicon is buggy, or because Linux
somehow ends up being vulnerable when it need not be?
>
Definitely not true of the post-Oracle models. I saw a tech talk on the
core once.
Ronald F. Guilmette
In message <SN1PR0501MB2125B3606...@SN1PR0501MB2125.namprd05.prod.out
look.com>, Andrew Duane <adu...@juniper.net> wrote:
>I wouldn't think Javascript would have the accurate timing required to leve=
>rage this attack, but I don't really know enough about the language.
This brings up something I have been wondering about, although my guess is
that much greater minds than mine have already considered this possible
mitigation...
If the meltdown or spectre (or both) attacks are based on careful analysis
of timing information, following a memory fault, then why just just introduce
a very tiny delay, of randomized duration, in the relevant kernel fault handler,
following each such fault?
(Since nothing I've read is talking about this, I am guessing that this would
be an even bigger loser, performance-wise, than the mitigations that have been
developed so far.)
Regards,
rfg
Cameron, Frank J
> I wouldn't think Javascript would have the accurate timing required to
"The performance.now() method returns a DOMHighResTimeStamp, measured
in milliseconds, accurate to five thousandths of a millisecond (5
microseconds)."
https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
"We implemented a clock with a parallel counting thread using the
SharedArrayBuffer. ... The resulting resolution is close to the resolution
of the native timestamp counter. On our Intel Core i5 test machine, we
achieve a resolution of up to 2ns using the shared array buffer. This
is equivalent to a resolution of only 4 CPU cycles, which is 3 orders
of magnitude better than the timestamp provided by performance.now."
https://gruss.cc/files/fantastictimers.pdf
-----------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may contain
company proprietary information. If you are not the intended
recipient, notify the sender immediately and delete this
message. Publication, reproduction, forwarding, or content
disclosure is prohibited without the consent of the original
sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
-----------------------------------------------------------------
Mike Tancsa
> Regardless, is there someone within FreeBSD that is working on patches for this set of problems, at least for Intel? Linux already has at least some, and I believe NetBSD does too. Of course Windows has already pushed out a Windows10 fix, 7 and 8 are coming.
There is an official announcement on the FreeBSD site (quote below). Not
sure about NetBSD, but DragonFly seems to have published some patches.
Looks quite extensive :(
https://www.phoronix.com/scan.php?page=news_item&px=DragonFly-Meltdown-Fixed
" About the Meltdown and Spectre attacks: FreeBSD was made aware of the
problems in late December 2017. We're working with CPU vendors and the
published papers on these attacks to mitigate them on FreeBSD. Due to
the fundamental nature of the attacks, no estimate is yet available for
the publication date of patches."
---Mike
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
Don Lewis
>
> In message <SN1PR0501MB2125B3606...@SN1PR0501MB2125.namprd05.prod.out
> look.com>, Andrew Duane <adu...@juniper.net> wrote:
>
>>I wouldn't think Javascript would have the accurate timing required to leve=
>>rage this attack, but I don't really know enough about the language.
>
> This brings up something I have been wondering about, although my guess is
> that much greater minds than mine have already considered this possible
> mitigation...
>
> If the meltdown or spectre (or both) attacks are based on careful analysis
> of timing information, following a memory fault, then why just just introduce
> a very tiny delay, of randomized duration, in the relevant kernel fault handler,
> following each such fault?
difference in access time between a cache hit and a cache miss. Whether
or not you get a cache hit vs. a cache miss is dependent on whether the
speculative execution filled that particular cache line, and that
depends on the value of the data that the exploit code is trying to
exfiltrate. Since the code is being executed speculatively, a fault
only halts the speculative execution at that point and doesn't actually
result in a call to the fault handler because the CPU eventually figures
out that that execution path would not be taken afterall due to some
earlier condition that it eventually resolves. That tosses all of the
CPU state associated with the speculative execution path, but the cache
state remains as a leftover side effect.
John-Mark Gurney
> If the meltdown or spectre (or both) attacks are based on careful analysis
> of timing information, following a memory fault, then why just just introduce
> a very tiny delay, of randomized duration, in the relevant kernel fault handler,
> following each such fault?
impact. You just need to collect more samples to average out the noise.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."