Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 23 May 2018, 20:54
All times are UTC - 4
 Forum index » Off-Topic Area » Security
Intel/Linux 20% slowdown
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 4 [59 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
Keisha

Joined: 18 Nov 2014
Posts: 465

PostPosted: Fri 05 Jan 2018, 16:34    Post subject:  

ac2011 wrote:
Keisha wrote:
ac2011 wrote:
I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.
Or wait for a Puppy to appear with an appropriately patched kernel. The final mainline version of 4.16 should work, when it appears. Maybe, just maybe, 4.15. Or a legacy version kernel with the patchset backported.


That would solve Meltdown but not Spectre, which I believe requires recompilation of applications with 'retpoline' or similar mitigations..

But you said you use an AMD A CPU, which is not susceptible to the Spectre #2 attack which is mitigated by retpoline (see https://www.amd.com/en/corporate/speculative-execution). It only applies to Intel CPU's. Spectre #2 requires either retpoline patches to the kernel and software, or a microcode update (so says https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html). This implies that if you have the Intel microcode update in force, retpoline is unnecessary.

_________________
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.” --Bruce Lee
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1541
Location: N.E. USA

PostPosted: Fri 05 Jan 2018, 16:39    Post subject:  

I see a reference to the Intel Management Engine with Atom's being suseptible to THOSE things.

The Two Atom Series are;

C3xxx (Silvermont Architecture) AKA x3 series SoFIA
E39xx (Silvermont Archetecture) AKA x5 series Apollo Lake

So the Bonnell Architecture is EXEMPT.

Regards
8Geee

_________________
Linux user #498913

Some people need to reimagine their thinking.
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Fri 05 Jan 2018, 16:48    Post subject:  

Keisha wrote:
ac2011 wrote:
Keisha wrote:
ac2011 wrote:
I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.
Or wait for a Puppy to appear with an appropriately patched kernel. The final mainline version of 4.16 should work, when it appears. Maybe, just maybe, 4.15. Or a legacy version kernel with the patchset backported.


That would solve Meltdown but not Spectre, which I believe requires recompilation of applications with 'retpoline' or similar mitigations..

But you said you use an AMD A CPU, which is not susceptible to the Spectre #2 attack which is mitigated by retpoline (see https://www.amd.com/en/corporate/speculative-execution). It only applies to Intel CPU's. Spectre #2 requires either retpoline patches to the kernel and software, or a microcode update (so says https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html). This implies that if you have the Intel microcode update in force, retpoline is unnecessary.


The AMD A series is vulnerable to #1. Fix for that is recompiled binaries. From your Google link: "Variant 1 (CVE-2017-5753), “bounds check bypass.” This vulnerability affects specific sequences within compiled applications, which must be addressed on a per-binary basis."

You're right about retpoline. I thought that was required for binary recompilation but according to that Google link it's not. I'm not clear what changes would be required in binaries if not mitigating instructions, though.
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Fri 05 Jan 2018, 16:50    Post subject:  

8Geee wrote:
I see a reference to the Intel Management Engine with Atom's being suseptible to THOSE things.

The Two Atom Series are;

C3xxx (Silvermont Architecture) AKA x3 series SoFIA
E39xx (Silvermont Archetecture) AKA x5 series Apollo Lake

So the Bonnell Architecture is EXEMPT.

Regards
8Geee


Seems to be, hence the N280. It'll be fun going back a decade in computing power...
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1541
Location: N.E. USA

PostPosted: Fri 05 Jan 2018, 16:55    Post subject:  

There are some N2800 boxes around. These are 2-core Atoms using the Bonnell archetecture, and the last best processor that is EXEMPT from IME and Meltdown/Spectre.

Cheers
8Geee

_________________
Linux user #498913

Some people need to reimagine their thinking.
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Fri 05 Jan 2018, 17:05    Post subject:  

8Geee wrote:
There are some N2800 boxes around. These are 2-core Atoms using the Bonnell archetecture, and the last best processor that is EXEMPT from IME and Meltdown/Spectre.

Cheers
8Geee


Thanks, but given it's a >2008 design I suspect it might have the Intel Management Engine, and that's a no-no for me. No point in jumping from one frying pan into another.

Edit: I know you wrote exempt from IME but do you have any links for that? Libreboot says anything from Intel after 2008 is compromised, and anything from 2013 onward for AMD, hence my 2012 AMD A-series box. The N2800 would be a better option than the N280 if it's IME-free.

Last edited by ac2011 on Fri 05 Jan 2018, 17:43; edited 1 time in total
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1541
Location: N.E. USA

PostPosted: Fri 05 Jan 2018, 17:42    Post subject:  

If the CPU is not Atom C3000 or E3900 there is NO Intel Management Engine. The 2008 reference is for desktop Nehalem CPU's. This is common FUD being sent all over.

Link to both Atom Processors and Intel OOOE was already given in one of my previous posts on topic. The source is Wikipedia.


As for Intel Management Engine look here. Skip the geeky stuff if you want, but there are important verified points about what is affected, and "other names" for it. You will find that the 2008 reference is for the Nehalem desktop. And you will also find that AMD distributed a patch for their version that shuts off that "feature" without harm. Intel's version bricks the computer.


Regards
8Geee

_________________
Linux user #498913

Some people need to reimagine their thinking.

Last edited by 8Geee on Fri 05 Jan 2018, 17:51; edited 1 time in total
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Fri 05 Jan 2018, 17:45    Post subject:  

8Geee wrote:
If the CPU is not Atom C3000 or E3900 there is NO Intel Management Engine. The 2008 reference is for desktop Nehalem CPU's. This is common FUD being sent all over.

Regards
8Geee


Thanks (I think you wrote while I was editing). This sounds more appealing. My Google-fu apparently isn't good enough to find a definitive list of IME vs non-IME CPUs.
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1541
Location: N.E. USA

PostPosted: Fri 05 Jan 2018, 17:53    Post subject:  

me too, but uncle Barney Google has a nit to pik with competitors to Android and Chrome. se la vie.

Regards
8Geee

_________________
Linux user #498913

Some people need to reimagine their thinking.
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2323

PostPosted: Fri 05 Jan 2018, 18:04    Post subject:  

belham2 wrote:
We should also be talking about what users can do to protect themselves. I think the following might help and/or provide some guide:

1) make sure you have 2-4 different bootable systems . System 1 is for general web use. System 2, a backup to System 1. System 3, a system with a browser that is used only for email and sensitive site access (that means going directly to those sites, and nowhere else). System 4, a backup to system 3.
.
.
4) In Systems 3 and 4 above, these systems are with browsers that have javascript enabled (most sensitive sites, i.e. bank, etc won't function without javascript enabled in the browser). Also, these systems are never to be booted up and used for anything else. Install basic minimums to this systems (Ubuntu minimal, or Debian minimal, and Puppy installs are great choices here. My preference: I build minimal Debian installs myself. Also, I trust Barry inside and out---and for a USB stick for a System 3/4 boot, these are the way to go.
.
.
7) Last but not least, in the Systems 3 and 4 that you build, or install and/or whatever, don't install any extra software packages---no new added programs for anything (except a browser, and, if building, only the basics for a DE functioning system). This shouldn't need explained, given what Systems 3 & 4 will be used for.

Great advice Belham2. I have Debian (main repo's only) for casual use (their security team are hot). For your 3/4 I use OpenBSD. Once installed already to a partition (a6 type), you can just download/verify the latest snapshot bsd.rd (usually under pub/OpenBSD/snapshots ... and your PC/device folder, /pub/OpenBSD/snapshots/amd64/bsd.rd for me) saving it to / and then boot that (reboot and enter "boot bsd.rd"). That 9MB or so ramdisk snapshot enables you to upgrade, install ...etc. I usually reinstall afresh and its all textual/cli style that takes around 5 minutes to run through (mostly its just accepting defaults and I use the http based install option so there's no need for CD's etc., just pulls down everything it needs). After a reboot I mount my Debian partition (for me running disklabel sd0 shows the ext3 partitions and for me its mkdir sda2;mount /dev/sd0j sda2 to mount the Debian partition) in which I have copies of the /etc/X11/xorg.conf, /etc/sysctrl.conf, ~/.Xdefaults ~/.xsession. ~/.twmrc and ~.profile that I copy over to the new OpenBSD install and then pkg_add (similar to Debian's apt-get) firefox-esr-i18n-en-GB and its all good to go.

Tracking openbsd --current conceptually isn't as stable as --release or --stable, but so far I've not encountered any problems and that has pre-built binaries of the latest versions so there's no need to compile anything. You can run into problems where the mirrors are being updated as you're pulling things down, but that's relatively rare (not encountered it myself, but have seen mention of it by others) and a simple re-try again later resolves that issue.

A fresh install of the latest versions of OpenBSD (which includes X that is set to run at a low-privilege levels) and browser used only to go directly to your banks web site is relatively secure. OpenBSD however doesn't have the range of programs as available from Debian, so as a day to day general system Debian works well for me. Nice to have a slice of both Linux and Unix pies as well.
Back to top
View user's profile Send private message 
Keisha

Joined: 18 Nov 2014
Posts: 465

PostPosted: Fri 05 Jan 2018, 23:31    Post subject:  

ac2011 wrote:
...The AMD A series is vulnerable to #1. Fix for that is recompiled binaries...
ac2011 wrote:
"Variant 1 (CVE-2017-5753), “bounds check bypass.”...affects specific sequences within compiled applications, which must be addressed on a per-binary basis."...You're right about retpoline...I'm not clear what changes would be required in binaries if not mitigating instructions, though.

Hmm...some further information which seems to challenge your conclusions:
https://access.redhat.com/articles/3311301
Quote:

CVE-2017-5753 (variant #1/Spectre) is a Bounds-checking exploit during branching. This issue is fixed with a kernel patch. Variant #1 protection is always enabled; it is not possible to disable the patches. Red Hat’s performance testing for variant #1 did not show any measurable impact.

CVE-2017-5715 (variant #2/Spectre) is an indirect branching poisoning attack that can lead to data leakage. This attack allows for a virtualized guest to read memory from the host system. This issue is corrected with microcode, along with kernel and virtualization updates to both guest and host virtualization software. This vulnerability requires both updated microcode and kernel patches. Variant #2 behavior is controlled by the ibrs and ibpb tunables (noibrs/ibrs_enabled and noibpb/ibpb_enabled), which work in conjunction with the microcode.

CVE-2017-5754 (variant #3/Meltdown) is an exploit that uses speculative cache loading to allow a local attacker to be able to read the contents of memory. This issue is corrected with kernel patches. Variant #3 behavior is controlled by the pti tunable (nopti/pti_enabled).

Careful reading of the above seems to suggest that AMD systems, which we already know are invulnerable to Spectre #2 and Meltdown #3, will not be vulnerable to Spectre #1 either provided a kernel is used which has been given the referenced patchset.

And Intel systems won't be vulnerable either, provided the kernel has been patched against all three exploits *and* Intel can supply the promised microcode, which so far as of this writing is vaporware, to mitigate Spectre #2.

So, after Red Hat supplies the necessary kernel patches and Intel supplies microcode for its own CPU's, patching of application software will be unnecessary.

That still leaves the AMT/SPS/ME remote management vulnerabilities. Which AMD can be protected against and Intel still can not.

And of course it still leaves the fact that Intel CPU's suffer slowdown when given the patch against Meltdown, #3. Apparently Amazon Web Services customers are already noticing it:
https://www.theregister.co.uk/2018/01/04/amazon_ec2_intel_meltdown_performance_hit/

Amazon is adding more physical machines --well, actually, more physical *cores*-- to some customers' virtual machines to compensate for slowdowns due to the Meltdown #3 mitigation (the pti enablement).

I wonder if Amazon and other cloud providers will seek compensation from Intel for the extra electricity cost, and reduction in number of total customers each cloud installation can serve, that this cockup on Intel's part will entail?

I see a rocky road ahead for Intel and a lot of new business for AMD.

_________________
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.” --Bruce Lee
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Sat 06 Jan 2018, 08:04    Post subject:  

Keisha wrote:

Hmm...some further information which seems to challenge your conclusions:


Those were Google's conclusions, not mine. Again from the Google link about variant #1: "Mitigation requires analysis and recompilation so that vulnerable binary code is not emitted. Examples of targets which may require patching include the operating system and applications which execute untrusted code."

So either Google or Red Hat is wrong, since "applications which execute untrusted code" includes web browsers amongst other things, not just the kernel.

I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 955

PostPosted: Sat 06 Jan 2018, 14:28    Post subject:  

ac2011 wrote:
Keisha wrote:

Hmm...some further information which seems to challenge your conclusions:


Those were Google's conclusions, not mine. Again from the Google link about variant #1: "Mitigation requires analysis and recompilation so that vulnerable binary code is not emitted. Examples of targets which may require patching include the operating system and applications which execute untrusted code."

So either Google or Red Hat is wrong, since "applications which execute untrusted code" includes web browsers amongst other things, not just the kernel.

I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.


This is speculation. A browser script might not have the necessary features to execute the attack. I presume the attack hasn't been demonstrated via a browser script or google wouldn't have made that claim.

Then again if the attacker could hijack the browser then maybe my assumptions are void.
Back to top
View user's profile Send private message 
Keisha

Joined: 18 Nov 2014
Posts: 465

PostPosted: Sat 06 Jan 2018, 19:15    Post subject:  

ac2011 wrote:
[Those were Google's conclusions, not mine...So either Google or Red Hat is wrong,...
Sorry for blaming the messenger. Yes, there is a stark contradiction implied there, isn't there...

Intel's shareholders probably will proceed with the legal actions which are already going forward, and those suits might ultimately combine and morph into some kind of class-action, which I presume Intel would settle out of court, with the shareholders getting new stock warrants perhaps. Maybe, just maybe, the individual buyers at retail of desktops and laptops with Intel inside will end up getting some type of small refund payout and/or rebate on their next Intel purchase.

However, my guess is, Amazon and Google and Microsoft and all the other rackmount server farm cloud providers etc. won't do anything drastic, e.g. won't become plaintiffs in giant lawsuits against Intel. After all, the cloud providers and Intel are mutually dependent on each other, and the Federal government would take any steps necessary to prevent Intel from being driven out of business, for reasons of national security.

Instead, my guess is, Dell and HP and the other hardware makers who supply the government and big cloud providers with large roomsful of rackmount hardware will quietly use public reaction to this fiasco as a bargaining chip to strike deals with Intel for future CPU's at reduced prices.

The cloud providers (including Google) will naturally attempt to bring pressure on Intel to compensate them for the higher electric bills needed to implement the Meltdown remedy, and for whatever damage to reputation and resultant loss of customer bases is due to the Spectre vulnerabilities of Intel CPU's.

If all this speculation above is on the mark, then the whitepapers by Google's Point Zero Team are not to be taken seriously, but are instead just a PR favor being done for Intel, a gesture of goodwill given by Google, an opening gambit of "noblesse oblige," in what promises to be an entertaining process of negotiation.

Or it could be that the whitepapers were in fact produced at the behest of Intel. Maybe it's decided to get rid of the AMT/SPS/ME ("IME") remote management technology altogether and is using this "disgrace" as a cover to initiate a new marketing campaign to sell everybody a forthcoming new generation of "less prone to government intrusion" CPU's?

Or maybe to ditch x86 and amd_64 altogether?

ac2011 wrote:
I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.
I just bought an Atom box too Laughing .

I've already convinced my boss to have the IT guy look at dual Epyc boxes.

Another possibility might be rumored forthcoming offerings from Lenovo based on Chinese-designed, Chinese-made CPU's built on MIPS64 architecture, which said architecture appears to be not subject to the OOOE type of attack --hmm, maybe there's a reason why China decided to license MIPS64 and develop its own CPU's...

I'll keep my dual-E5-2696v3-Xeon uber-spreadsheet-crusher though, until such time as Intel announces that no, it can't really come up with the promised new microcode update to prevent Spectre #2 attacks. If Intel throws in the towel on that one, or if the new microcode seriously slows my day-to-day processing down like the Meltdown #3 defense slows down high-transaction-volume datacenter database access...then Intel is history, and AMD (or Loongsong?) here I come Shocked

_________________
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.” --Bruce Lee
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2323

PostPosted: Sat 06 Jan 2018, 21:07    Post subject:  

As the vulnerability is more widely known/understood, in the interim between browsers being patched (FF 57.4 I believe has been patched for AMD protection), using a addon such as useragent might be a reasonable choice in the interim and spoof your operating system/browser. At least that way if a potential exploit is being deployed against known systems/browsers it may misdirect/mitigate the risk.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 4 [59 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0796s ][ Queries: 14 (0.0154s) ][ GZIP on ]