Intel backdoor: not a bug, a feature (buy a new processor!!!)

For friendly off topic discussion not covered in a forum above.
Forum rules
No politics, please.
User avatar
escimo
Posts: 123
Joined: Sat Mar 22, 2008 4:07 am
Location: Frankfurt/Main, Germany
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby escimo » Fri Jan 05, 2018 5:41 am

The solution: IN-MEMORY ENCRYPTION for everything.

I don't know hardware solutions but I expact the feature will be implemented with the next wave/generation of CPU's and chipsets, maybe RAM modules as well.
In software you're already able to compensate this with e.g. Intel's SGX or AMD's SME/SEV, not mentioning the performance impact.

BTW: I think I will wait with my next equipment acquisition (workstation) until this is fixed in hardware or better you're able to easily encrypt all your memory (RAM). OMG the stack of changes and bugs which you can expact with this changes ... :shock: - Otherwise the prises could drop :mrgreen:
SNI: PCD-4H (sphinx), PCD-3Msx (cupido), SCENIC Pro C5 (scenic)
SUN: SPARCstation 2 (toosy), Ultra 60 (<noname>), Blade 2000 (betsy)

User avatar
spiroyster
Donor
Donor
Posts: 167
Joined: Thu May 03, 2012 8:24 am
Location: Somerset, UK

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby spiroyster » Fri Jan 05, 2018 6:21 am

The deeper one goes, you have to start wondering at what point Eve (as in Alice, Bob etc) stops giving a sh*t. o.0

Encryption would be the answer, but at some point the data will exist decrypted in digital form, on some medium... and this will no doubt be accessible by someone or something. So this boils back down to how secure the services (kernel specifically) can protect access to those memory areas from unsolicited visits/copies (exploits, or by design).

Nothing is really safe, encryption is only as secure as the security of the key holders. Who do you trust and how much do you trust them etc. ... yes open hardware is no doubt the key (no pun intended) rather than security through 'intellectual property obscurity' :twisted: .... was it ever established if 'that' OpenBSD backdoor was courtesy the Feds or not :lol: ? I guess the other problem with 'Open', if someone is the first to find an exploit, who says they need to tell anyone? That bearded guy? His vigilante tree hugging minions *cough* community.

User avatar
Raion-Fox
Donor
Donor
Posts: 1556
Joined: Thu Jan 30, 2014 5:01 pm
Location: near King George, Virginia
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby Raion-Fox » Fri Jan 05, 2018 9:05 am

I'm not panicking as an Intel user only because not only did kernel.org and MS push out patches soon, even on 8.1 and 7, the performance hit I can stand to take. I'm going to postpone any upgrades to new tech until the dust has settled.
:O3x02L: R16000 700MHz 8GB RAM kanna
:Octane: R12000 300MHz SI 896MB RAM yuuka
:Octane2: R12000A 400MHz V6 2.5GB RAM
:Tezro: Quad R16000 700MHz V12 8GB RAM murasaki
:Indy: (Acclaim) R4600 133MHz XL Graphics 32MB RAM
:Indy: (Challenge S) R4600 133MHz (MIPS III Build Server)

I am probably posting from yangxiaolong, HP Z230 with Xeon E3-1230v3, 16GB RAM, GeForce 750ti, and running NetBSD and Windows 8.1 Embedded.
Owner and operator of http://irix.pw

User avatar
marshallh
Posts: 31
Joined: Tue Nov 03, 2009 12:53 pm

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby marshallh » Fri Jan 05, 2018 3:27 pm

I'll take the security risk, I need compiles to be as fast as possible :D Typical fpga compile is between 3 to 5 minutes for me. I have the fastest singlethreaded proc I can get my hands on (6700k) and not looking forward to seeing times get longer. Guess I can always OC...

User avatar
vishnu
Donor
Donor
Posts: 3279
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby vishnu » Sat Jan 06, 2018 9:35 pm

Looks like AMD is pretty sure they don't suffer from this vulnerability, this is in the changelog for Linux 4.14.12, released yesterday:

Code: Select all

    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.
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
escimo
Posts: 123
Joined: Sat Mar 22, 2008 4:07 am
Location: Frankfurt/Main, Germany
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby escimo » Sun Jan 07, 2018 9:52 am

First. Well, nothing is save in life but death. :)

Second. As I understood, the kernel patch only applies to the "Meltdown" named attack but not for "Spectre", because for the later one you not need KPT/I. Or does I miss something?
Source: https://m.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html?seite=2
(sorry german language)
The article including also links to the papers.

EDIT: dead -> death
Last edited by escimo on Sun Jan 07, 2018 6:04 pm, edited 1 time in total.
SNI: PCD-4H (sphinx), PCD-3Msx (cupido), SCENIC Pro C5 (scenic)
SUN: SPARCstation 2 (toosy), Ultra 60 (<noname>), Blade 2000 (betsy)

robespierre
Posts: 1632
Joined: Mon Sep 12, 2011 2:28 pm
Location: Boston

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby robespierre » Sun Jan 07, 2018 12:01 pm

escimo wrote:As I understood, the kernel patch only applies to the "Meltdown" named attack but not for "Spectre", because for the later one you not need KPT/I. Or does I miss something?

Spectre is mostly a problem for applications. Firefox and Chrome announced mitigations last week.
It could also be a problem for web servers or other programs that run unsigned packages from the net.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:

User avatar
spiroyster
Donor
Donor
Posts: 167
Joined: Thu May 03, 2012 8:24 am
Location: Somerset, UK

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby spiroyster » Thu Jan 11, 2018 6:29 am

Does anyone know if a 'patched' guest OS could jump/side-channel its way into an 'un-patched' host OS's kernel space? Or even the other way around, an 'un-patched' guest OS and 'patched' host OS?

I have no idea how virtualised kernels operate wrt the host kernel space... :cry:

User avatar
uunix
Donor
Donor
Posts: 1867
Joined: Sun Mar 27, 2011 12:48 pm
Location: Stourbridge / England / UK

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby uunix » Thu Jan 11, 2018 7:41 am

If you have a web application running on a server, that just does DB serving and web pages, therefore no outgoing 'browsing', could this be affected do we know?
Last edited by uunix on Thu Jan 11, 2018 8:26 am, edited 1 time in total.
-----------------------------------------------------------------------
Hey Ho! Pip & Dandy!
:Octane2: :O2: :Indigo: :Indy:
-----------------------------------------------------------------------

User avatar
spiroyster
Donor
Donor
Posts: 167
Joined: Thu May 03, 2012 8:24 am
Location: Somerset, UK

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby spiroyster » Thu Jan 11, 2018 7:52 am

I have found a lump on the front of my O2 :(, does it have bit-rot?

.... upon further inspection I have discovered its the power button.

User avatar
ClassicHasClass
Donor
Donor
Posts: 2148
Joined: Wed Jul 25, 2012 7:12 pm
Location: Sunny So Cal
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby ClassicHasClass » Thu Jan 11, 2018 8:52 am

uunix wrote:If you have a web application running on a server, that just does DB serving and web pages, therefore no outgoing 'browsing', could this be affected do we know?


Assuming it's running your code and not arbitrary code someone else sneaked onto it, I wouldn't think there would be much risk.
smit happens.

:Fuel: bigred, 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
:Indy: indy, 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze, 175MHz R10000, Solid IMPACT
probably posted from Image bruce, Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * RDI PrecisionBook * BeBox * Solbourne S3000 * Commodore 128 * many more...

User avatar
bifo
Posts: 88
Joined: Sat Aug 20, 2016 8:02 pm

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby bifo » Fri Jan 12, 2018 5:44 am

Latest updates on potential performance hits (not pasting the whole thing because it's quite long):
https://www.nextplatform.com/2018/01/08 ... ver-taxes/

Particularly relevant for people here:
Neither early UltraSparc chips from Sun Microsystems, nor Itaniums from Intel, are effected by Spectre or Meltdown, but IBM’s latest several generations of Power chips are affected at least back to the Power7 chips from 2010 and continuing forward to the brand new Power9 chips that made their formal debut in HPC iron back in December and that will roll out throughout IBM’s Power Systems line this year. In its statement, IBM said that it would have patches out for firmware on Power machines using Power7+, Power8, Power8+, and Power9 chips on January 9 along with Linux patches for those machines; patches for the company’s own AIX Unix and proprietary IBM i operating systems will not be available until February 12. The System z mainframe processors also have speculative execution, so they should, in theory, be susceptible to Spectre but maybe not Meltdown.


The numbers breakdown from Red Hat is in the article and comes with a variety of qualifications, but if you aren't too concerned with that then this is the conclusion:
We have to make some assumptions to make a point here. So first, let’s assume that the average performance hit is somewhere around 10 percent for a server based on microbenchmarks, and that the heavily virtualized environment in most enterprise datacenters washes out against the lower impact expected for enterprise workloads. Call it something on the order of $60 billion a year in worldwide system sales. So the impact is $6 billion a year in the value of the computing that is being lost, at the grossest, highest denominator level. For modern machines, this is like giving up two, four, or maybe even six cores out of the machine, if the performance hit pans out as we expect on existing machines across a wide variety of workloads. Add this up over the three or four generations of servers sitting out there in the 40 million or so servers in the world, and maybe the hit is more to the tune of $25 billion without taking into account the depreciated value of the installed base. Even if you do, it is still probably north of $10 billion in damages.

It will be interesting to see how many lawyers try to file a class action lawsuit against Intel and possibly other processor makers to chase that money. We are not saying that it is necessarily justified, by the way. But clearly it would have been better if this set of speculative execution exploits was discovered a decade ago before the technology became so pervasive.

There is a possibility that companies are not dramatically affected by the performance hits from the Meltdown and Spectre patches and they just buy slightly more capacious CPUs, and maybe a slightly larger number of machines, to cover that hit. No big deal.

What seems more likely is that CPU makers and their downstream OEMs and ODMs will have to give a little on the prices for their processors and systems once the performance hits are better qualified. But it can’t be anything close to 10 percent, is our guess. And even if it is 5 percent, Intel will have to bear the brunt of that hit – meaning Intel will have to shave off something like 15 percent or maybe even a 20 percent on its Skylake processors or else see customers trying to buy much cheaper Broadwells and Haswells – because it seems entirely unfair to pass that cost completely over to the OEMs and ODMs, who are already living on skinny margins as it is.

User avatar
escimo
Posts: 123
Joined: Sat Mar 22, 2008 4:07 am
Location: Frankfurt/Main, Germany
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby escimo » Fri Jan 12, 2018 3:26 pm

bifo wrote:Particularly relevant for people here:
Neither early UltraSparc chips from Sun Microsystems, (...), are effected by Spectre or Meltdown, (...)
Maybe but that doesn't mean it's better :mrgreen:

UltraSPARC I --> in-order-exec but w/ high amount of cache-miss penalties. so nothing really bad.

UltraSPARC II --> in-order-exec w/ extension to US1 design but https://www.theregister.co.uk/2001/03/07/sun_suffers_ultrasparc_ii_cache/, http://www.sparcproductdirectory.com/artic-2001-dec-1.html

UltraSPARC III --> out-of-order-exec but http://www.theregister.co.uk/2001/04/04/sun_warns_of_data_corruption/, http://www.tomshardware.co.uk/sun-ultrasparc-iii-chip-glitch-found,news-3335.html, http://www.sparcproductdirectory.com/artic-2002-jan-pb.html

For US3 they deactivated the prefetch pipeline with software (firmware) which results in lower FP perf. - yes, in theory it was safe, regardless of the performance bottlenecks ;)

EDIT: "that means not" -2- "doesn't mean"
Last edited by escimo on Tue Jan 16, 2018 5:17 am, edited 2 times in total.
SNI: PCD-4H (sphinx), PCD-3Msx (cupido), SCENIC Pro C5 (scenic)
SUN: SPARCstation 2 (toosy), Ultra 60 (<noname>), Blade 2000 (betsy)

User avatar
tomvos
Donor
Donor
Posts: 141
Joined: Fri Jul 04, 2008 1:08 pm
Location: Aachen, Germany, Europe
Contact:

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby tomvos » Mon Jan 15, 2018 9:43 pm

robespierre wrote:
tomvos wrote:However I'm not really able to tell whether spectre or meltdown would not be able to be exploited on the mill architecture, too?

I haven't had time to work out whether the Spectre approach would work or not. The side-channel exploited by this family of attacks is that the cache is not fully associative, and that a speculative cache load can evict another cache line with some address bits in common. So if you test how fast you can access a certain cache line A legitimately, you can detect when it has been evicted by another cache line B which you cannot access. And that cache line B can be loaded based on arbitrary data (a double indirect data access) executed speculatively. This scheme can be stopped by several architectural changes, the most obvious of which is datatype tags that distinguish addresses. Another change would be to use fine-grained parallelism so you don't have different trust domains within the same address space. Mandatory array bounds checking would also work: Spectre relies on the processor speculating down a branch that falsely assumes the array index is within bounds.


Spectre and Meltdown do not affect the Mill.

https://millcomputing.com/blog/wp-conte ... tre.03.pdf
:Fuel: :Octane2: :O2: :O2: :1600SW: :Indy: :Indy:
Where subtlety fails us we must simply make do with cream pies.

User avatar
Krokodil
Donor
Donor
Posts: 498
Joined: Fri Apr 17, 2015 2:32 pm
Location: The House of Particular Individuals

Re: Intel backdoor: not a bug, a feature (buy a new processor!!!)

Unread postby Krokodil » Sun Feb 04, 2018 9:34 pm

Not real excited at the notion that I should have to replace my Sandy Bridge and Ivy Bridge machine because of this stupid issue. Though the Sandy Bridge machine is in its twilight years, I just don't feel like spending money to replace it, right now.

Atleast the Alpha, MIPS and SPARC aren't affected by this foolishness.
:Octane2: - :O2: - :Octane: - :Indigo2IMP:
Alphaserver DS10 - 466MHZ
Sun Ultra 5 - 440MHZ.


Return to “Everything Else”

Who is online

Users browsing this forum: No registered users and 1 guest