CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

Update 9/14/2018 - Summary of Intel microcode updates
Last Updated: 13 Sep 2018
https://support.microsoft.com/en-us/help/4093836/summary-of-intel-microcode-updates

Protect your Windows devices against Spectre and Meltdown
Last Updated: 11 Sep 2018
https://support.microsoft.com/en-au...your-windows-devices-against-spectre-meltdown

Update 8/14/2018 C/O Intel microcode revision guidance.PDF (August 8. 2018)

Update 7/2/2018 - Intel Updated the Microcode Update Guidance PDF
https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf
"...expand support for Intel processor microarchitectures ranging all the way back to 1st generation Core "Westmere," and "Lynnfield," and including "Sandy Bridge" and "Ivy Bridge" along the way, at various stages of roll-out (beta, pre-production, and production). This update probably features hardening against "Spectre" variant 4, and perhaps even RSRR (rogue system register read) variant 3A, chronicled in CVE-2018-3640"

Update 4/6/18 - Intel published a new guidance Update on Meltdown / Spectre fixes, Intel gives up fixing a bunch of older CPU's (one I still run), so be aware you may need to check the list for your older CPU's to see if Intel is not going to fix it, here is the Intel pdf download:
Intel Microcode Revision Guidance - April 2, 2018
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf

Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed
And won’t fix Meltdown nor Spectre for 10 product families covering 230-plus CPUs
By Simon Sharwood, APAC Editor 4 Apr 2018 at 01:15
https://www.theregister.co.uk/2018/04/04/intel_says_some_cpus_with_spectre_v2_cant_be_fixed/
http://forum.notebookreview.com/thr...patches-and-more.812424/page-91#post-10706116
---------------------------
Microsoft is now (3/13/2018) pushing out "stable" Intel microcode updates through Windows Update, applying them through the Windows OS Boot process - not updating your actual BIOS firmware - but inserting the update through the boot process. Details in this thread post #881:
http://forum.notebookreview.com/thr...patches-and-more.812424/page-89#post-10694956
---------------------------
March 6, 2018 Intel Microcode Revision Guidance
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf
---------------------------
Intel has updated the Microcode status again today, February 26, but I wouldn't get excited, as vendors need to integrate microcode changes in to a BIOS update for your specific motherboard.

And, given Intel's track record so far I wouldn't install BIOS updates until it's been out for a few weeks, to see if it gets pulled again.

Here is Intel's current Microcode status PDF, which appears like it is getting updated daily:

Microcode Revision Guidance
February 26 2018
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf


A Clear Guide to Meltdown and Spectre Patches
Jonathan Crowe Jan 2018
https://blog.barkly.com/meltdown-spectre-patches-list-windows-update-help

Updated 2/13/18 at 3:57pm ET with details on how IT pros can now track the vulnerability status for individual machines by using Windows Analytics.

Updated 1/22/18 at 5:36pm ET with confirmation Intel has advised customers not to apply firmware patches and wait for new update.

"Having trouble keeping up and making sense of all the Meltdown and Spectre patches being released? You're not alone. This guide will help."

Spoiler: Guide... check link above for latest updates...

Ever since news of Meltdown and Spectre — two massive CPU vulnerabilities affecting nearly every operating systems and device — hit, vendors have been racing to release updates to mitigate the flaws.

Things haven't exactly gone smoothly, with several incompatibility muck ups causing a lot of finger-pointing and frustration. To help clear things up, we've put together a quick guide that walks through the major updates to operating systems and browsers, explaining how they address Meltdown and/or Spectre, what they specifically don't address, and any known compatibility or performance issues that have been reported.

Use the links below to skip ahead:

• OS updates
  • Windows updates
  • macOS updates
  • Linux updates
• Browser updates
• Firmware updates

For even more info, Bleeping Computer has put together a good list of official advisories, notices, patches, and updates organized by vendor.

Meltdown and Spectre Overview
Before we dive in, here's a quick recap of what Meltdown and Spectre are all about. For more in-depth details see our post, The Meltdown and Spectre CPU Bugs, Explained.

Meltdown (CVE-2017-5754)
Meltdown is a CPU vulnerability that allows a user mode program to access privileged kernel-mode memory. It affects all out-of-order Intel processors released since 1995 with the exception of Itanium and pre-2013 Atoms. A list of vulnerable ARM processors and mitigations is listed here. No AMD processors are affected by Meltdown.

Of the two bugs, Meltdown is the easier one to fix, and can largely be addressed with operating system updates.

Spectre (CVE-2017-5753, CVE-2017-5715)
Spectre isn't so much a specific vulnerability as it's a new class of attack. It's enabled by the unintended side effects of speculative execution (something processors do to speed things up by predicting what instructions they're about to recieve and executing them ahead of time).

There are two flavors of Spectre — variant 1 (bounds check bypass, CVE-2017-5753) and variant 2 (branch target injection, CVE-2017-5715). Both can potentially allow attackers to extract information from other running processes (ex: stealing login cookies from browsers).

Intel, ARM, and AMD processors are all reportedly affected by Spectre to some degree, and it poses significant patching problems. While operating system and browser updates have helped mitigate the risk of Spectre to some degree, experts agree the only true fix is a hardware update. As such, Spectre is likely to remain an issue for years to come.

Source: SANS / Rendition Infosec. See the full presentation here

It's important to note that both vulnerabilities put information disclosure at risk. Neither are remote execution vulnerabilities — in other words, they don't allow attackers to run malware.

OS updates
Windows updates
Microsoft's process for releasing Windows updates addressing Meltdown and Spectre has been a bumpy road, marred by high-profile incompatibility issues with third-party antivirus (AV) software and AMD processors. In some cases, delivery of the latest security update has been restricted or suspended.

More details and direct download links to the updates below:

• Windows 10
  • version 1507 — KB4056893 (issued 1/3/18)
  • version 1511 — KB4056888 (issued 1/3/18)
  • version 1607 — KB4056890 (issued 1/3/18)
  • version 1703 — KB4056891 (issued 1/3/18)
  • version 1709 — KB4056892 (issued 1/3/18)

• Windows 8 and Windows Server 2012
  • Windows 8.1 and Server 2012 R2— KB4056898 (issued 1/3/18)
  • No patches available for Windows Server 2012 non-R2 version
• Windows 7 and Windows Server 2008
  • Windows 7 SP1 and Server 2008 R2 SP1 — KB4056897 (Security only, issued 1/3/18)
  • Windows 7 SP1 and Server 2008 R2 SP1 — KB4056894 (Monthly rollup, issued 1/4/18)
  • No patches available for Windows Server 2008 non-R2 version

What they address:

• Spectre variant 1, bounds check bypass (CVE-2017-5753)

• Meltdown, rogue data cache load (CVE-2017-5754)
  UPDATE (1/17/18): As readers have pointed out, it appears Windows patches for 32-bit systems (x86-based systems) do not provide Meltdown mitigations.
• Per Microsoft: "The existing 32 bit update packages listed in this advisory fully address CVE-2017-5753 and CVE-2017-5715, but do not provide protections for CVE-2017-5754 at this time. Microsoft is continuing to work with affected chip manufacturers and investigate the best way to provide mitigations for x86 customers, which may be provided in a future update."

What they don't address:

• Spectre variant 2, branch target injection (CVE-2017-5715) — firmware updates are required to fully address Spectre variant 2.

Known issues:

• AV compatibility issues: During tests, Microsoft discovered that a compatibility issue with "a small number of antivirus software products" was causing system crashes. As a result, the company has made delivery of the Windows security updates linked to above contingent on the presence of a special registry key, which it has instructed all AV vendors to add to customer devices only after they've confirmed their products are compatible.
  
  This deserves reiterating — Microsoft will not deliver the Windows update unless the following registry key exists (more details here):

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”
Data="0x00000000”

This has created a lot of confusion, especially since the response from AV vendors has varied, with some setting the registry key for their customers and others recommending users set it, themselves, manually. The situation only gets more complicated considering many organizations have more than one AV solution installed.

Update: Microsoft has clarified that Windows Defender Antivirus, System Center Endpoint Protection, and Microsoft Security Essentials are compatible with the update and do set the required registry key.

That means as long as you have one of these built-in Microsoft protections enabled the registry key should be set automatically — no further, manual action should be necessary.

Big caveat: If you are using third party software that Microsoft offically recognizes as AV, it is important to note that, by default, Windows Defender and Microsoft Security Essentials will turn themselves off. That means the registry key won't be added unless you or your AV actively do it.

All that said, here is a flow chart that can help you determine your situation:


Windows users who aren't using a third party antivirus and don't have Windows Defender or Microsoft Security Essentials enabled will need to set the registry key themselves, manually. To help, Bleeping Computer has put together a .reg file that automates that task here. Note: They also issue a warning to make absolutely sure you're not running an AV that isn't compatible with the update before using it.

If you are using an AV and haven't received the Windows patch yet, you are advised to wait until your AV vendor either issues an update that sets the registry key for you or specifically recommends that you do so, yourself.

• AMD compatibility issues: As first reported at the Verge, Microsoft has received numerous reports of PCs running AMD processors not booting after installing the latest Windows security update. After investigating, the company confirmed there were issues, and temporarily stopped delivering the update to AMD devices. Affected users needed to visit Microsoft's support site for instructions on getting their machines back up and running.
  
  Update (1/18/18): Microsoft has announced it will resume rolling out patches for AMD devices running Windows 7 SP1 and Windows Server 2008 R2 SP1, Windows 8.1 and Windows Server 2012 R2, and Windows 10, version 1709. Updates for four versions of Windows 10 — 1511, 1607, and 1703 — are still paused. As are updates for Windows Server 2016 and Windows 10 Enterprise.
  
  
• Group or MDM policy configuations may be disabling updates: According to Microsoft, if you have Group or MDM policy settings configured to disable preview builds, your machines may not be receiving updates (see what those settings are here). To fix that, Microsoft recommends temporarily changing Group/MDM policy settings to "Not Configured" and changing them back once the updates have been installed.
  
  
• Performance impact: As with the other operating systems, patches addressing Meltdown and Spectre are expected to take a non-insignificant toll. In a blog post, Microsoft Executive VP Terry Myerson explains the impact of these fixes can vary depending on the version of Windows running and the age of the machine:
  • Windows 10 on 2016-era PCs with Skylake, Kabylake, or newer CPU: Single-digit slowdowns, which most users won't notice.
    
    
  • Windows 10 on 2015-era PCs with Haswell or older CPU: Slowdown can be more significant. Some users may notice a decrease in performance.
    
    
  • Windows 8 or Windows 7 on 2015-era PCs with Haswell or older CPU: Most users will likely notice a decrease in system performance.
    
    
  • Windows Server (any CPU): Mitigations to isolate code within a Windows Server intance results in a more significant performance impact. According to Myerson, "This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment."

Enabling protections for Windows Server
Microsoft has also advised Windows Server customers that they need to take the additional step of adding the following registry keys in order to enable patch protections.

To enable the fix:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

If this is a Hyper-V host and the firmware updates have been applied: fully shutdown all Virtual Machines (to enable the firmware related mitigation for VMs you have to have the firmware update applied on the host before the VM starts).

Restart the server for changes to take effect.

To disable this fix:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the server for the changes to take effect.

(There is no need to change MinVmVersionForCpuBasedMitigations.)

Microsoft also notes that for Hyper-V hosts, live migration between patched and unpatched hosts may fail. The company also points to an alternative protection mechanism you can use on hosts that don't have updated firmware yet.

Additional guidance from Microsoft:

• Tips for helping IT pros apply OS updates
• Tips for updating Windows Server

Verifying new Windows protections are enabled:
To help confirm whether updates have been implemented correctly Microsoft has provided a PowerShell script that system administrators can run to test Meltdown and Spectre mitigations.

The following command will install the PowerShell module:

PS > Install-Module SpeculationControl

Note: There are a couple of requirements for running this command. First, you'll need to be running PowerShell with admin privileges and may need to adjust execution policy. Also, the Install-Module command was introduced to PowerShell in version 5.0. Most Windows 7 machines will not have this version, due to the upgrades being optional and unrelated to security. Any machine with an outdated version of PowerShell can still run the Get-SpeculationControlSettings function below, however, as long as you can obtain the contents of the script and run it ad-hoc.

Once installed, the following command will run the test to check your system:

PS > Get-SpeculationControlSettings

The output will look something like this:



Results for Spectre protections

The first grouping — "Speculation control settings for CVE-2017-5715 [branch target injection] — refer to protections in place for the Spectre vulneralbility. If the value for "Windows OS support for branch target injection mitigation is present" is "True" then the Windows Security update has been successfully installed.

The other red lines in that section simply confirm that more complete mitigation for Spectre requires firmware updates, which Intel says it's in the process of rolling out. According to the company, updates for more than 90 percent of its processor products should be introduced by the end of next week.

Results for Meltdown protections

The second grouping — "Speculation control settings for CVE-2017-5754 [rogue data cache load] — refer to protections in place for the Meltdown vulneralbility. If you see the following results and no red lines then you've confirmed the Windows Security update has been successfully implemented and the machine is protected:

Hardware requires kernel VA shadowing: True

Windows OS support for kernel VA shadow is present: True

Windows OS support for kernel VA shadow is enabled: True

Windows OS support for PCID optimization is enabled: True
Test results confirming successful mitigation of the Meltdown vulnerability

If you see any red lines in this section then that means the update has not been successfully applied. For more details on interpreting the PowerShell script output, Microsoft has a full results key here.

macOS High Sierra 10.13.2 Supplemental Update and iOS 11.2.2 update.

What they address:

• Meltdown (CVE-2017-5754)
• Spectre (CVE-2017-5753 and CVE-2017-5715) to some extent

What they dont' address:

• Spectre (CVE-2017-5753 and CVE-2017-5715) to some extent
  While Apple says its latest updates to macOS, iOS, and Safari help mitigate the risk of Spectre being exploited, the company acknowleges it will be continuing to develop and test further mitigations.

No reported issues

Linux updates
After being left out of the loop, Linux developers are making significant progress on patches, even if they're not particularly happy about being put in this position. The latest update of the stable Linux kernel (4.14.13) includes patches designed to mitigate Meltdown with Kernel Page Table Isolation (KPTI). More comprehensive patches (including fixes for ARM64 processors) will be available in 4.15, scheduled for release in two weeks.

Patches have also been added to the 4.4 and 4.9 stable kernel trees.

Canonical has released a second update for Ubuntu 16.04 LTS Xenial users after the first caused boot issues. You can find the new update with Linux kernel image 4.4.0-109 here.

What they address:

• • Meltdown (CVE-2017-5754)

What they dont' address:

• • Spectre (CVE-2017-5753 and CVE-2017-5715)
    No patches are available for Spectre yet, but work is underway to implementRetpoline, a technique introduced by Google for dealing with the speculative execution issue Spectre relies on. Testing is currently being conducted to assess potential performance impact.

Known issues:

• • Patches haven't been released for machines running ARM64 processors: They are expected to be supported with the release of 4.15 in a couple of weeks.
  • Patches bricking Ubuntu 16.04 computers: According to Bleeping Computer, boot issues have been reported by a large number of Ubuntu users running the Xenial 16.04 series after updating to kernel image 4.4.0-108. New updates with kernel image 4.4.0-109 have since been released which address the issue.
  • Performance impact: Based on initial testing, performance penalties for the patches are expected to range from single to double digits, depending primarily on how much interaction applications/workloads have with the kernel. You can find more details in benchmark studies conducted by Phoronix and Red Hat.

Checking Linux for Spectre and Meltdown vulnerability:
A simple script has been developed to help determine whether Linux kernel installations are still vulnerable to Meltdown and Spectre after applying patches. You can find it along with installation instructions here.

Browser updates
According to researchers, the most likely exploitation of Spectre appears to be web-based attacks using JavaScript (say in a malicious ad) to leak information, session keys, etc. cached in the browser. As such, Google, Mozilla, Apple, and Microsoft have all either issued or schedule new updates for their browsers to reduce that risk.

What browser updates address:

• Spectre (CVE-2017-5753 and CVE-2017-5715) to some extent

What browser updates dont' address:

• Meltdown (CVE-2017-5754)
  You'll need to apply OS updates to mitigate Meltdown.

Chrome
Google has announced it will be including mitigations for Spectre starting with Chrome 64, which will be released on or around January 23. In the meantime, Chrome users are advised to turn on site isolation, which can help prevent a site from stealing data from another site.

Firefox
Mozilla has already issued Firefox version 57.0.4, which helps address Spectre by disabling or reducing Firefox's internal timer functions and disabling the SharedArrayBuffer feature. Firefox users can take additional precaution by enabling site isolation, as well.

Safari
Apple has released Safari 11.0.2 to specifically mitigate the effects of Spectre.

IE and Edge
Microsoft has made changes to both Internet Explorer 11 and Microsoft Edge to mitigate Spectre. In addition to removing support for SharedArrayBuffer from Edge, it has made changes to reduce the precision of several time sources to make successful attacks more difficult.

Firmware updates
OS and browser updates only partially mitigate Meltdown and Spectre. Organizations need to be prepared for UEFI firmware and BIOS updates, as well. When and whether updates will be pushed out will vary from vendor to vendor, adding another layer of complexity and uncertainty to patching. In some cases, admins may have to proactively check for updates from their PC makers periodically over the next few days or weeks.

Intel
Update 1/12/18: Intel has released new Linux Processor microcode data files that can be used to add Meltdown and Spectre mitigations without having to perform a BIOS update.

Intel went on record promising firmware updates for 90 percent of affected processors made in the past five years by January 15. So far, it looks as though these microcode fixes apply to a specific list of processors provided here.

The microcode updates can be downloaded directly from Intel, and Bleeping Computer has provided instructions and a video example to help walk admins through the install process here. It should be noted that some issues have already been reported with the updates, specifically around unwanted reboots. While Intel initially confirmed machines with Broadwell and Haswell CPUs were experiencing that issue, later the company said machines running newer processors were affected, too (more details below).

Windows users need to wait until Microsoft finishes testing the microcode and releases an additional update.

Known issues:

• Older Broadwell and Haswell CPUs experiencing sudden reboots: Intel is already confirming the company has received reports of glitches resulting from the firmware update on systems running Intel Broadwell and Haswell CPUs.
  
  
• UPDATE (1/18/18): Machines with newer CPUs also experiencing sudden reboots: Intel has since confirmed the firmware update is causing machines with Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake processors to suffer unwanted reboots, too.
  
  
• UPDATE (1/22/18): Intel now recommending customers NOT apply firmware update: The company has reportedly discovered the root cause of the Broadwell and Haswell boot issues, and is testing an updated patch. In the meantime, it isrecommending customers stop deployment of the current patch to avoid reboots and other "unpredictable system behavior."
• Performance impact: Statements regarding the potential performance impact of those updates have been inconsistent, but the company has most recently said the patches are slowing processors down by six percent in certain situations.Update (1/18/18): Intel has shared more details on performance impact based on specific workloads in a chart you can find here.

AMD
Update 1/12/18: AMD has officially acknowledged that its processors are vulnerable to both variants of Spectre, but not Meltdown. While the company says OS patches are enough to mitigate Spectre variant 1, it will be rolling out optional microcode updates this week, starting with fixes for Ryzen and EPYC processors.

Known issues:

• Windows OS update compatibility issues: As first reported at the Verge, Microsoft has received numerous reports of PCs running AMD processors not booting after installing the latest Windows security update. After investigating, the company confirmed there are issues — specifically with AMD Opteron, Athlon, and AMD Turion X2 Ultra families — and temporarily stopped delivering the update to AMD devices. AMD says it is working with Microsoft to resolve the issue. In the meantime, affected users need to visit Microsoft's support site for instructions on getting their machines back up and running.
  
  Update (1/18/18): Microsoft has announced it will resume rolling out patches for AMD devices running Windows 7 SP1 and Windows Server 2008 R2 SP1, Windows 8.1 and Windows Server 2012 R2, and Windows 10, version 1709. Updates for four versions of Windows 10 — 1511, 1607, and 1703 — are still paused. As are updates for Windows Server 2016 and Windows 10 Enterprise.

IBM
According to IBM, firmware patches for POWER7+, POWER8, and POWER9 platforms are all currently available via FixCentral. The company says Power7 patches will be available February 7. In addition, it estimates IBM i operating system patches (also available via FixCentral) will finish rolling out on February 12, and AIX patches will be available starting January 26.

Closing note
For now, the generally recommended course of action is not to panic and instead take the time to properly assess, test, and carefully implement OS and firmware updates as they are made available — especially since there have been a variety of widespread compatibility issues already.

Information around Meltdown and Spectre is still being circulated, debated, and processed, so there is likely much more to come. We'll be following closely and providing updates as they become available.

-----------------------------------------------------------------
Everything On The Meltdown + Spectre CPU Flaws! Rev. 3.0
Posted by Dr. Adrian Wong Date: February 17, 2018
https://www.techarp.com/articles/meltdown-spectre-cpu-flaws/
-----------------------------------------------------------------
Speculation Control Validation PowerShell Script
This is described in the blog topic: "Windows Server guidance to protect against the speculative execution side-channel vulnerabilities."
https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050#content
-----------------------------------------------------------------
How to Check and Update Windows Systems for the Meltdown and Spectre CPU Flaws
How can you check the status of the patches?
https://www.bleepingcomputer.com/ne...stems-for-the-meltdown-and-spectre-cpu-flaws/
-----------------------------------------------------------------
Mitigation: 3 Practical Things to Do Now
Step 1: Verify if new Windows protections are enabled
https://blog.barkly.com/meltdown-and-spectre-mitigation

https://www.catalog.update.microsoft.com/Search.aspx?q=2018-01

Vendor support links, thanks to @Carcozep :

Lenovo Spectre and Meltdown Advisory

HP Spectre and Meltdown Advisory

HP Enterprise Spectre and Meltdown Advisory Spreadsheet

Gigabyte Spectre and Meltdown BIOS Updates

Dell Consumer Spectre and Meltdown Advisory

Dell Enterprise Spectre and Meltdown Advisory

Additional vendor links list from Intel, there is also an FAQ and introductory info, but I thought the links to vendors treatment of the issues would be most helpful.

Side-Channel Analysis Facts and Intel Products
Facts about The New Security Research Findings and Intel Products
https://www.intel.com/content/www/u...side-channel-analysis-and-intel-products.html

Other NBR threads tracking various aspects:

uCode fix for Spectre, HT bug fix and Meltdown
http://forum.notebookreview.com/threads/ucode-fix-for-spectre-ht-bug-fix-and-meltdown.806451/

Haswell Microcode 23 released. Spectre vulnerability patched, 9% slowdown :-(
http://forum.notebookreview.com/thr...ectre-vulnerability-patched-9-slowdown.812642



----------Original post, additional links added at the end...
tl;dr:
There is presently an embargoed security bug impacting apparently all contemporary CPU architectures [the last 10 years of Intel CPU releases] that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine.

Intel CPU Bug Cannot Be Fixed With Microcode Update | Cripples Performance Up To 30 Percent
Published on Jan 2, 2018


'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
Other OSes will need an update, performance hits loom
By John Leyden and Chris Williams 2 Jan 2018 at 19:29
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
https://forums.theregister.co.uk/forum/1/2018/01/02/intel_cpu_design_flaw/#c_3383617

"There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. "
...
"Microsoft's Azure cloud – which runs a lot of Linux as well as Windows – will undergo maintenance and reboots on January 10, presumably to roll out the above fixes.

Amazon Web Services also warned customers via email to expect a major security update to land on Friday this week, without going into details.

There were rumors of a severe hypervisor bug – possibly in Xen – doing the rounds at the end of 2017. It may be that this hardware flaw is that rumored bug: that hypervisors can be attacked via this kernel memory access cockup, and thus need to be patched, forcing a mass restart of guest virtual machines."

Spoiler: Details...

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 the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – specifically, PCID – to reduce the performance hit.

Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated – the flaw is in the Intel x86 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or buy a new processor without the design blunder.

Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue.

However, some details of the flaw have surfaced, and so this is what we know.

Impact
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka ****WIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.

How can this security hole be abused?
At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs.

At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.

Specifically, in terms of the best-case scenario, it is possible the bug could be abused to defeat KASLR: kernel address space layout randomization. This is a defense mechanism used by various operating systems to place components of the kernel in randomized locations in virtual memory. This mechanism can thwart attempts to abuse other bugs within the kernel: typically, exploit code – particularly return-oriented programming exploits – relies on reusing computer instructions in known locations in memory.

If you randomize the placing of the kernel's code in memory, exploits can't find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching.

However, it may be that the vulnerability in Intel's chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

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.

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to perform, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.

That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.

The specifics of the vulnerability have yet to be confirmed, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it's more serious than a KASLR bypass.

Also, the updates to separate kernel and user address spaces on Linux are based on a set of fixes dubbed the KAISER patches, which were created by eggheads at Graz University of Technology in Austria. These boffins discovered [ PDF] it was possible to defeat KASLR by extracting memory layout information from the kernel in a side-channel attack on the CPU's virtual memory system. The team proposed splitting kernel and user spaces to prevent this information leak. Their work was reviewed by Anders Fogh, who wrote this interesting blog post in July.

That article described his attempts to read kernel memory from user mode by abusing speculative execution. Although Fogh was unable to come up with any working proof-of-concept code, he noted:

My results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode.

It appears the KAISER work is related to Fogh's research, and as well as developing a practical means to break KASLR by abusing virtual memory layouts, the team may have proved Fogh right – that speculative execution on Intel x86 chips can be exploited to access kernel memory.

Shared systems
The bug will impact big-name cloud computing environments including Amazon EC2, Microsoft Azure, and Google Compute Engine, said a software developer blogging as Python Sweetness in this heavily shared and tweeted article on Monday:

There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures that implement virtual memory, requiring hardware changes to fully resolve.

Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November.

In the worst case the software fix causes huge slowdowns in typical workloads.

There are hints the attack impacts common virtualisation environments including Amazon EC2 and Google Compute Engine...

Microsoft's Azure cloud – which runs a lot of Linux as well as Windows – will undergo maintenance and reboots on January 10, presumably to roll out the above fixes.

Amazon Web Services also warned customers via email to expect a major security update to land on Friday this week, without going into details.

There were rumors of a severe hypervisor bug – possibly in Xen – doing the rounds at the end of 2017. It may be that this hardware flaw is that rumored bug: that hypervisors can be attacked via this kernel memory access cockup, and thus need to be patched, forcing a mass restart of guest virtual machines.

A spokesperson for Intel was not available for comment.

AMD not affected by kernel changes for Intel:

[PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
Tue, 26 Dec 2017 23:43:54 -0600
https://lkml.org/lkml/2017/12/27/2

[patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)
Mon, 04 Dec 2017 15:07:06 +0100
https://lkml.org/lkml/2017/12/4/709

[PATCH] x86/doc: add PTI description
Mon, 18 Dec 2017 14:04:13 -0800
https://lkml.org/lkml/2017/12/18/1523

Kernel page-table isolation merged
[Posted December 30, 2017 by corbet]
https://lwn.net/Articles/742404/

"Linus has merged the kernel page-table isolation patch set into the mainline just ahead of the 4.15-rc6 release. This is a fundamental change that was added quite late in the development cycle; it seems a fair guess that 4.15 will have to go to -rc8, at least, before it's ready for release."

See comments...KPTI is going to need to be back ported as far back as people are running older releases affected by the Intel CPU bug...affecting all distro's...

Background:

Kernel address space layout randomization
By Jake Edge October 9, 2013
https://lwn.net/Articles/569635/


The mysterious case of the Linux Page Table Isolation patches
[Various errors and updates are addressed in Quiet in the peanut gallery]
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

"tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer."

Spoiler: Details...

"I don’t really care much for security issues normally, but I adore a little intrigue, and it seems anyone who would normally write about these topics is either somehow very busy, or already knows the details and isn’t talking, which leaves me with a few hours on New Years’ Day to go digging for as much information about this mystery as I could piece together.

Beware this is very much a connecting-the-invisible-dots type affair, so it mostly represents guesswork until such times as the embargo is lifted. From everything I’ve seen, including the vendors involved, many fireworks and much drama is likely when that day arrives.

LWN

The trail begins with LWN’s current state of kernel page-table isolation article posted on December 20th. It’s apparent from the tone that a great deal of urgent work by the core kernel developers has been poured into the KAISER patch series first posted in October by a group of researchers from TU Graz in Austria.

The purpose of the series is conceptually simple: to prevent a variety of attacks by unmapping as much of the Linux kernel from the process page table while the process is running in user space, greatly hindering attempts to identify kernel virtual address ranges from unprivileged userspace code.

The group’s paper describing KAISER, KASLR is Dead: Long Live KASLR, makes specific reference in its abstract to removing all knowledge of kernel address space from the memory management hardware while user code is active on the CPU.

Of particular interest with this patch set is that it touches a core, wholly fundamental pillar of the kernel (and its interface to userspace), and that it is obviously being rushed through with the greatest priority. When reading about memory management changes in Linux, usually the first reference to a change happens long before the change is ever merged, and usually after numerous rounds of review, rejection and flame war spanning many seasons and moon phases.

The KAISER (now KPTI) series was merged in some time less than 3 months.

Recap: ASLR

On the surface, the patches appear designed to ensure Address Space Layout Randomization remains effective: this is a security feature of modern operating systems that attempts to introduce as many random bits as possible into the address ranges for commonly mapped objects.

For example, on invoking /usr/bin/python, the dynamic linker will arrange for the system C library, heap, thread stack and main executable to all receive randomly assigned address ranges:

$ bash -c ‘grep heap /proc/$$/maps’
019de000-01acb000 rw-p 00000000 00:00 0 [heap]
$ bash -c 'grep heap /proc/$$/maps’
023ac000-02499000 rw-p 00000000 00:00 0 [heap]

Notice how the start and end offset for the bash process heap changes across runs.

The effect of this feature is that, should a buffer management bug lead to an attacker being able to overwrite some memory address pointing at program code, and that address should later be used in program control flow, such that the attacker can divert control flow to a buffer containing contents of their choosing, it becomes much more difficult for the attacker to populate the buffer with machine code that would lead to, for example, the system() C library function being invoked, as the address of that function varies across runs.

This is a simple example, ASLR is designed to protect many similar such scenarios, including preventing the attacker from learning the addresses of program data that may be useful for modifying control flow or implementing an attack.

KASLR is “simply” ASLR applied to the kernel itself: on each reboot of the system, address ranges belonging to the kernel are randomized such that an attacker who manages to divert control flow while running in kernel mode cannot guess addresses for functions and structures necessary for implementing their attack, such as locating the current process data, and flipping the active UID from an unprivileged user to root, etc.

Bad news: the software mitigation is expensive

The primary reason for the old Linux behaviour of mapping kernel memory in the same page tables as user memory is so that when the user’s code triggers a system call, fault, or an interrupt fires, it is not necessary to change the virtual memory layout of the running process.

Since it is unnecessary to change the virtual memory layout, it is further unnecessary to flush highly performance-sensitive CPU caches that are dependant on that layout, primarily the Translation Lookaside Buffer.

With the page table splitting patches merged, it becomes necessary for the kernel to flush these caches every time the kernel begins executing, and every time user code resumes executing. For some workloads, the effective total loss of the TLB lead around every system call leads to highly visible slowdowns: @grsecurity measured a simple case where Linux “du -s” suffered a 50% slowdown on a recent AMD CPU.

34C3

Over at this year’s CCC, you can find another of the TU Graz researchers describing a pure-Javascript ASLR attack that works by carefully timing the operation of the CPU memory management unit as it traverses the page tables that describe the layout of virtual memory. The effect is that through a combination of high precision timing and selective eviction of CPU cache lines, a Javascript program running in a web browser can recover the virtual address of a Javascript object, enabling subsequent attacks against browser memory management bugs.

So again, on the surface, we have a group authoring the KAISER patches also demonstrating a technique for unmasking ASLR’d addresses, and the technique, demonstrated using Javascript, is imminently re-deployable against an operating system kernel.

Recap: Virtual Memory

In the usual case, when some machine code attempts to load, store, or jump to a memory address, modern CPUs must first translate this virtual address to a physical address, by way of walking a series of OS-managed arrays (called page tables) that describe a mapping between virtual memory and physical RAM installed in the machine.

Virtual memory is possibly the single most important robustness feature in modern operating systems: it is what prevents, for example, a dying process from crashing the operating system, a web browser bug crashing your desktop environment, or one virtual machine running in Amazon EC2 from effecting changes to another virtual machine on the same host.

The attack works by exploiting the fact that the CPU maintains numerous caches, and by carefully manipulating the contents of these caches, it is possible to infer which addresses the memory management unit is accessing behind the scenes as it walks the various levels of page tables, since an uncached access will take longer (in real time) than a cached access. By detecting which elements of the page table are accessed, it is possible to recover the majority of the bits in the virtual address the MMU was busy resolving.

Evidence for motivation, but not panic

We have found motivation, but so far we have not seen anything to justify the sheer panic behind this work. ASLR in general is an imperfect mitigation and very much a last line of defence: there is barely a 6 month period where even a non-security minded person can read about some new method for unmasking ASLR’d pointers, and reality has been this way for as long as ASLR has existed.

Fixing ASLR alone is not sufficient to describe the high priority motivation behind the work.

Evidence: it’s a hardware security bug

From reading through the patch series, a number of things are obvious.

First of all, as @grsecurity points out, some comments in the code have been redacted, and additionally the main documentation file describing the work is presently missing entirely from the Linux source tree.

Examining the code, it is structured in the form of a runtime patch applied at boot only when the kernel detects the system is impacted, using exactly the same mechanism that, for example, applies mitigations for the infamous Pentium F00F bug:



More clues: Microsoft have also implemented page table splitting

From a little digging through the FreeBSD source tree, it seems that so far other free operating systems are not implementing page table splitting, however as noted by Alex Ioniscu on Twitter, the work already is not limited to Linux: public NT kernels from as early as November have begun to implement the same technique.

Guesswork: Rowhammer

Digging further into the work of the researchers at TU Graz, we find When rowhammer only knocks once, an announcement on December 4th of a new variant of the Rowhammer attack:

In this paper, we present novel Rowhammer attack and exploitation primitives, showing that even a combination of all defenses is ineffective. Our new attack technique, one-location hammering, breaks previous assumptions on requirements for triggering the Rowhammer bug

As a quick recap, Rowhammer is a class of problem fundamental to most (all?) kinds of commodity DRAMs, such as the memory in the average computer. Through precise manipulation of one area of memory, it is possible to cause degradation of storage in a related (but otherwise logically distinct) area of memory. The effect is that Rowhammer can be used to flip bits of memory that unprivileged user code should have no access to, such as bits describing how much access that code should have to the rest of the system.

I found this work on Rowhammer particularly interesting, not least for its release being in such close proximity to the page table splitting patches, but because Rowhammer attacks require a target: you must know the physical address of the memory you are attempting to mutate, and a first step to learning a physical address may be learning a virtual address, such as in the KASLR unmasking work.

Guesswork: it effects major cloud providers

On the kernel mailing list we can see, in addition to the names of subsystem maintainers, e-mail addresses belonging to employees of Intel, Amazon and Google. The presence of the two largest cloud providers is particularly interesting, as this provides us with a strong clue that the work may be motivated in large part by virtualization security.

Which leads to even more guessing: virtual machine RAM, and the virtual memory addresses used by those virtual machines are ultimately represented as large contiguous arrays on the host machine, arrays that, especially in the case of only 2 tenants on a host machine, are assigned by memory allocators in the Xen and Linux kernels that likely have very predictable behaviour.

Favorite guess: it is a privilege escalation attack against hypervisors

Putting it all together, I would not be surprised if we start 2018 with the release of the mother of all hypervisor privilege escalation bugs, or something similarly systematic as to drive so much urgency, and the presence of so many interesting names on the patch set’s CC list.

One final tidbit, while I’ve lost my place reading through the patches, there is some code that specifically marked either paravirtual or HVM Xen as unaffected.

Invest in popcorn, 2018 is going to be fun

It’s totally possible this guess is miles off reality, but one thing is for sure, it’s going to be an exciting few weeks when whatever this thing is published."

Kernel page-table isolation (Wikipedia updating...)
https://en.wikipedia.org/wiki/Kernel_page-table_isolation

Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit In Windows And Linux
https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos

Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
index : kernel/git/torvalds/linux.git
https://git.kernel.org/pub/scm/linu.../?id=5aa90a84589282b87666f92b6c3c917c8080a9bf

Report: Intel CPUs suffer from major security flaw, fix could bring notable performance hit to macOS
https://9to5mac.com/2018/01/02/intel-cpu-bug-fix-slowdown-for-macs/

Report: Intel CPUs suffer from major security flaw, fix could bring notable performance hit to macOS
https://www.reddit.com/r/apple/comments/7nr280/report_intel_cpus_suffer_from_major_security_flaw/

Intel bug incoming (self.sysadmin)
submitted 19 hours ago * by dasunsrule32
https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

For Now At Least AMD CPUs Are Also Reported As "Insecure"
Written by Michael Larabel in AMD on 2 January 2018 at 09:16 PM EST.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

Speculation Control Validation PowerShell Script
This is described in the blog topic: "Windows Server guidance to protect against the speculative execution side-channel vulnerabilities."
https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050

Find out if your Windows PC is affected by Meltdown/Spectre vulnerabilities
by Martin Brinkmann on January 05, 2018 in Windows - Last Update: January 05, 2018
https://www.ghacks.net/2018/01/05/f...affected-by-meltdown-spectre-vulnerabilities/

"Microsoft created a PowerShell script that returns whether your Windows PC is still vulnerable or if you don’t have to worry about the vulnerabilities at all.

https://gallery.technet.microsoft.c...e36f0050/file/185106/1/SpeculationControl.zip

Here is what you need to do:

1. Load an elevated PowerShell prompt. Tap on the Windows-key, type PowerShell, hold down the Shift-key and the Ctrl-key and select the PowerShell entry to load it.
2. Type Install-Module SpeculationControl
3. You may get a prompt stating that “NuGet provider is required to continue.” Select Y to accept that.
4. You may get a prompt stating that you are installing an “untrusted repository.” Select Y to continue.
5. Type Import-Module SpeculationControl.
6. You may get an error stating that “running scripts” is disabled. If you do, type Set-ExecutionPolicy RemoteSigned. Repeat the command Import-Module SpeculationChannel.
7. Type Get-SpeculationControlSettings.

Tip: You can restore the default ExecutionPolicy setting by running the command Set-ExecutionPolicy Default.

The PowerShell script displays information about the vulnerability and available (installed) mitigations at this point."
View attachment 153585
"It is a bit hard to read, but true means that protection is available while false means that it is not. If you have installed yesterday’s Windows patch already, you should see some “true” listings there.

The script lists suggested actions to mitigation the issues that are still active. It is required to install a BIOS/firmware update to address those. How that is done depends on the manufacturer of the device.

Microsoft published additional information here."

Windows Server guidance to protect against speculative execution side-channel vulnerabilities
https://support.microsoft.com/en-us...-to-protect-against-the-speculative-execution

More links to follow...

 

Suddenly, Ryzen mobile seems a lot more appealing....

 

This does not look very promising for Intel. If there is a 30% drop in server performance then Epyc will get a huge boost.

Need more info first.

 

Intel's CEO Just Sold a Lot of Stock
Pay attention to these transactions.
Ashraf Eassa ( TMFChipFool)
Dec 19, 2017 at 5:10PM
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

Spoiler: Details...

"On Nov. 29, Brian Krzanich, the CEO of chip giant Intel ( NASDAQ:INTC), reported several transactions in Intel stock in a Form 4 filing with the SEC.

Most of the transactions involved Krzanich exercising employee stock options (these options allowed Krzanich to purchase Intel shares at prices significantly below where they are currently trading) and then immediately selling those shares that he bought at a discount on the open market. "

KRZANICH. IMAGE SOURCE: INTEL.

"There's nothing wrong with, or even unusual about, such transactions. Company executives, and even some employees, often receive either stock options and/or restricted stock units (RSUs) as part of their compensation packages, and at some point, the recipients of such compensation are going to want to turn it into cash.

Indeed, as explained here, insider selling isn't always a red flag.

However, there were two transactions that Krzanich reported in that Form 4 filing that I thought were more notable than typical stock option exercises and subsequent share sales.

Let's take a closer look.

Krzanich is keeping the bare minimum
Intel's corporate bylaws mandate a certain amount of stock ownership by executives and board members by the time they've been with the company for five years. Here are the amounts based on rank within the company:

Since Krzanich was appointed Intel CEO in May of 2013, he'll need to have 250,000 shares by May 2018 -- or about five months from now.

What's interesting, then, is that before Krzanich made any of the transactions that he reported in his most recently filed Form 4, he held 495,743 shares.

After the options exercises and subsequent sales (which left Krzanich's position unchanged at 495,743 shares), Krzanich then made two more transactions: a sale of 242,830 shares and a sale of 2,913 shares, with each transaction happening at an average price of $44.555, per the filing.

Those two transactions left Krzanich with exactly 250,000 shares -- the bare minimum that he's required to hold as CEO.

What does this mean?
Perhaps Krzanich sold those 245,743 shares valued at nearly $11 million at the time of the transactions to pay for a new house or buy a rare piece of artwork.

However, I find those explanations tenuous at best, particularly in light of the big windfall that he received when he exercised and sold all those stock options.

Instead, given that Krzanich seems to have sold all the shares he could save for those he is required by Intel's corporate bylaws to hold, the impression that I get is that Krzanich doesn't have a ton of faith in the potential for Intel stock to appreciate, perhaps driven by a lukewarm (or potentially even negative) view of the company's near- to medium-term business prospects.

After all, considering that Intel CFO Robert Swan reportedly said in a memo seen by The Oregonian that the company aims to boost its market capitalization to $300 billion (implying a share price north of $60) by 2021, wouldn't it have been wiser for Krzanich to hold those shares, collecting about a quarter of a million dollars per year in dividend payouts, before until they gained another $16 in value each, totaling nearly $4 million in additional value?

Indeed, considering that Krzanich claimed back in February that Intel's total addressable market is now on track to hit $220 billion by 2021, it seems strange that with all these growth opportunities ahead of Intel he'd choose to keep only the shares that he's required to by Intel's rules."

While at the same time...

Intel CEO to employees: 'We are going to take more risks'
Intel's Brian Krzanich wrote in a memo to employees on Tuesday that the company faces "an exciting challenge" in areas where it's an underdog.
The company's growth strategy is ultimately about data, he wrote.
Jordan Novet | @jordannovet
Published 7:00 PM ET Tue, 19 Dec 2017
https://www.cnbc.com/2017/12/19/intel-ceo-in-memo-we-are-going-to-take-more-risks.html

 

That's possibly bad news. I guess we will have to wait and see what the fallout actually looks like. Thankfully, I do not allow Windows Updates so I may not be affected by this hocus-pocus security baloney. My experience has been that Windows Updates can sometimes cause more harm than good. I am not convinced all of the blame rests on Intel. I think the Redmond Retards share at fair amount of the blame for their continued inappropriate influence and manipulation of what happens with hardware.

Not enough known at this time, but we do already know that Micro$lop is a thorn in the side of Linux as well. Their Satanic push for UEFI Class 3 security filth is a ball and chain to Linux as well as Windows fanboys. Since Linux is such an insignificant cog in the wheel of tech world, they get tossed to and fro by the same tidal wave of sewage from the Redmond Mafia. Linux has had to bow to the Bastard King like everyone else. Micro$loth is the modern pipeline to trash tech.

I won't be applying their "fix" - at least not until I am satisfied that it will not degrade my performance. That's more important than security as far as I am concerned. This might make AMD stuff look more attractive than it does today. How lucky for them, LOL.

 

How does the old saying go - never interrupt your enemy when he is making a mistake?

 

I also have to wonder how much of a winner would it make AMD if the primary way they get can finally get ahead in the performance race is based on an artificial metric driven by a frantic craze and childish clamor over a perceived need for a greater sense of security that imposes an artificial hit on performance? That's not a good way to get back on your feet and build a legacy based on excellent engineering. Everyone paying attention would know that it came about by the release of a screwed up Windows security patch.

 

Regardless, it doesnt sound good for Intel

 

Oh, you're absolutely right. And, you know the drive-by media is going to blow it out of proportion like they always do everything and play to the fears of those that spend all of their misguided OCD calories being stressed out about the digital boogieman possessing their PC.

 

This isn't artificial. In fact, it suggests due to Intel playing fast and loose with security, they artificially inflated performance.

 

Wow! Thats a bomb shell! So they were cutting corners when it came to security in order to enhance performance? Ouch!

 

For me, and a lot of others, there is no performance issue if there is no security. Now some devices security this may not be an issue and for that the patch is a non issue. For my PC, it definitely is an issue.

Even if developers placed usage access using higher performance and less secure methods Intel would have been familiar with it for years while not saying a word. This Is familiar tactic of Intel, securing performance advantage over even BullDozer. Most will look at what this does to current offerings and market share where this could have been another oppression of competition.

Assuming a worst case a 30% drop would mean a 5.2 overclock performing like a 3.66 would today. This would be a major hit to Intel performance but even a 15% hit would make a 5.2 perform like a 4.4 bring the playing field much closer. That being said a 5% hit would hurt but not immediately change the current landscape.

 

And this right here is the downside of proprietary IP. We all have no option but to trust the competence and honesty of mega corporations to invest money and personnel to find embarrassing bugs in products once released...


This situation is just like what is ironically called "Phase 4 trials" in therapeutics regulation (ironic because clinical trials only have 3 phases): when released onto the market, you have to monitor a drug if it performs as expected or whether some hidden risk of adverse effect exists, because you can't fully trust the approval procedure

 

I think that's a bit of a reach. (OK, a lot of a reach.) But, it's certainly a strategy that the plaintiff vulture attorneys will likely use as they clamor to make a buck off of litigating this thing. The numbers don't lie. Using the same rationale in the opposite direction one could say the performance will be artificially deflated after patching.

Edit: That is not meant as a personal thing. I know your background. I have good friends that practice law and I regret not following my parental advice as a young man and becoming an attorney when they offered to pay for it. There are good ones and bad ones, just like there are honest auto mechanics and dishonest auto mechanics.

We are going to have security holes forever and without end. It automatically comes with technology, and as long as there are evil people in the world that want to exploit holes for dishonorable self-serving purposes it is never, ever, going to stop. It just happens to be Intel that got caught with their pants down this time. Honestly, I'm surprised that it took so long. But, I am sure Micro$loth is more than happy to let them take a beating for it. And, I'm 99.9% sure there is probably an equally huge security issue somewhere in AMD architecture that hasn't been discovered. Not because AMD is bad at what they do, or because Intel is bad at what they do... just because there is always something somewhere. Kind of like how Mac OS X and Linux are less secure than Windows, and they have been for years; but, hacker theives are not going waste their time on exploits that represent a single-digit or very low double-digit and statistically irrelevant market share. There's nothing for them to gain by it... too much effort and too little reward for their evil deeds.

Bingo! That's it. Well said. And, I wonder what kind of tail they are going to pin on the AMD security donkey after the Intel security donkey has been beaten to death, LOL. The notion of security is to computer tech what the notion of the importance of big pharmaceuticals is to the medical science industry... the goose has to keep laying golden eggs squirting golden turds.

 

It could possibly be as AJC says also. That it was done intentionally to stifle competition, and maintain a performance edge over AMD. I trust every major corporation about as much as I do a sitting congressman, but Intel has been caught before, which makes their track record a little less reputable.

 

If you design your predictive branch to pre-fetch without waiting for permissions, you are telling it to ignore permissions and grant access, all which give a speed boost when having to do a kernel reference. That SPECIFICALLY is artificially inflating your numbers by disregarding security protocols that you damn well know your competitor is following. That is anti-competitive and that is why this is so bad!

Right now, I want to see the benchmarks after the fix comparing every AMD and Intel CPU dating back to the first introduction of this into their predictive branch. That is an FTC matter, not a securities matter. What @hmscott mentioned about the stock sales IS a securities matter (stockholders, not computer security).

This is about to get REAL good!

What are you talking about? Congressmen have been caught lying all the time. They sleep in the same bed!!! LOL@

EDIT: Look at congress's approval ratings!

 

heads up: Fix for intel hardware bug will lead to performance regressions
2018-01-02 22:23:54
https://www.postgresql.org/message-id/[email protected]
"Hi,

Upcoming versions of the linux kernel (and apparently also windows and others), will include new feature that apparently has been implemented with haste to work around an intel hardware bug.

https://lwn.net/SubscriberLink/741878/eaff7b24627c41a2/

The fix, split userland / kernel pagetables, is going to be merged in the next version of the linux kernel and is being backported to older point releases. The backports of a complex invasive new feature signals that this concerns a significant issue.

There's plenty speculation about details about what exactly the vulnerability is. Don't want to go into that here.

The fix will unfortunately cause performance regressions. Depending on the hardware version and kernel version (will not be backported for every version) hardware features (PCID / ASID) will be used to reduce the impact.

pti is the workaroud, page table isolation, which can be enabled/disabled via boot parameters. nopcid disables the use of the hardware feature that reduces the impact of workaround. PCID support

readonly pgbench (tpch-like), 16 clients, i7-6820HQ CPU (skylake):

pti=off:
tps = 236629.778328

pti=on:
tps = 220791.228297 (~0.93x)

pti=on, nopcid:
tps = 198959.801459 (~0.84x)

To get closer to the worst case, I've also measured:

pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):

pti=off:
tps = 420490.162391

pti=on:
tps = 350746.065039 (~0.83x)

pti=on, nopcid:
tps = 324269.903152 (~0.77x)

Note that real-world scenarios probably will see somewhat smaller impact, as this was measured over a loopback unix sockets which'll have smaller overhead itself than proper TCP sockets + actual network.

The rumor mill has it that details about the vulnerability will be un-embargoed in the next few days.

Greetings,
Andres Freund"

 

LOL, quoted from the Register comments...

Intel has been the Gold standard in processors, turns out it’s Copper Inside(TM).

 

"The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka ****WIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers."
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

 

What has me curious is how many future generations this will affect. It wouldn't be surprising if Ice Lake is affected by this.

 

If you read around, PCID and other features supposedly help. BUT, Skylake was shown to have a 17-23% hit in performance. Kaby has the exact same sets of features. As does Skylake-X. You would have to, then, do something to help Ice Lake, which may already have issues with staying competitive with Zen 2 7nm. So, we shall see!

 

Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes
Written by Michael Larabel in Software on 2 January 2018
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

"Over the past day you've likely heard lots of hysteria about a yet-to-be-fully-disclosed vulnerability that appears to affect at least several generations of Intel CPUs and affects not only Linux but also Windows and macOS. The Intel CPU issue comes down to leaking information about the kernel memory to user-space, but the full scope isn't public yet until the bug's embargo, but it's expected to be a doozy in the data center / cloud deployments. Due to the amount of interest in this issue, here are benchmarks of a patched kernel showing the performance impact of the page table isolation patches."

Results of performance tests from above article are on the 2nd page:
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

Linux Gaming Performance Doesn't Appear Affected By The x86 PTI Work
Written by Michael Larabel in Linux Kernel on 2 January 2018 at 09:06 PM EST
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

"With the recently published Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes, one of the common questions that came up is whether gaming performance is adversely affected by the x86 Page Table Isolation changes recently merged to the Linux kernel.

Linux gaming performance in initial testing doesn't appear to be affected. Then again, we personally didn't expect it to be much considering it's more isolated than some of the other syscall / context switching heavy workloads benchmarked. But for those concerned whether running the patched Linux kernel could lead to a drop in frame-rates, it doesn't appear to be when firing up some of the common Linux games on Steam.

For this quick testing was a Radeon RX Vega 64 running on the Intel Core i7 8700K "Coffee Lake" system with Linux 4.15:

The frame-rates were pretty much stable in the different Vulkan/OpenGL games tested. Likewise, in the earlier article applications like FFmpeg also weren't significantly impacted unlike some of the synthetic I/O benchmarks, etc.

 

For Now At Least AMD CPUs Are Also Reported As "Insecure"
Written by Michael Larabel in AMD on 2 January 2018 at 09:16 PM EST.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

"Right now with the big mysterious security vulnerability causing the rush of the x86 Page Table Isolation work that landed in the Linux kernel days ago, it's believed to be a problem only affecting Intel CPUs. But at least for now the mainline kernel is still treating AMD CPUs as "insecure" and is too taking a performance hit.

Besides my initial benchmarks of the performance impact as a result of this x86 workaround in the Linux 4.15 kernel, I've been working on various other tests since yesterday and one of them was just seeing what happens on AMD hardware.


Back on 26 December is when Tom Lendacky of AMD posted a patch to confirm this PTI problem shouldn't affect the company's processors -- at least with what information is currently known. Lendacky wrote, " 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."

But over one week later, that patch has yet to be merged to the mainline kernel. When booting the Linux 4.15 kernel on an AMD EPYC box, indeed, for now the AMD CPU is still treated with a bug of "insecure_cpu."

An immediate workaround at least until the AMD patch lands where PTI isn't applied to AMD CPUs is by booting the kernel with the nopti kernel command-line parameter. This can also be applied to Intel systems too on a patched kernel if wanting to regain the performance and are not too concerned about this vulnerability.

In affected benchmarks (those making use of a lot of system calls, context switches, etc), indeed AMD EPYC faces a performance penalty similar to Intel. I'll have more test data to share on Wednesday.

Hopefully more details on the underlying vulnerability come to light soon to really know if AMD CPUs have any chance of being affected and other details."

 

Sounds like in dealing with this, they just wanted to default it until more thoroughly explored. But, that is no bueno on the wait until they change that.

 

Well, that is good news if the noptl command will restore unpatched performance for those that are not concerned about this hype. I am thankful if it will be that simple to maintain control and autonomy to handle my personal property in whatever manner I deem to be appropriate. As far as I am concerned, not a big deal in the grand scheme of things. I do not use antivirus software either.

It will still be a big deal for Intel, primarily because the general public is going to be extra emo about it... guaranteed... especially with the special help and influence of the alarmist media that will milk the story drier than a popcorn fart.

It will be cute to see all of the talking head media muppets regurgitating technical mumbo jumbo they don't even comprehend. They seem to be really good at that, no matter what the subject matter happens to be.

 

Any word yet on when we can expect a Windows patch for this security hole? I'm interested to see if there's any performance hit, and thanks hmscott for your Linux gaming performance posting.

 

The later the better. I don't want no 'patch'.

 

Watch Jason Bourne 2016 , but it's not about one platform, all technology owners are the same and serve the same master. It will never stop as @Mr. Fox said. No one can force them to correct what they are doing, so it's our decision go with it or just leave it and try to find something else, BTW they didn't leave the open source alone, they already injected their poisons inside most of it.

 

Just because one company chooses to do things a certain way imposes no obligation for another to follow suit. Intel following AMD's lead would be kind of like the tail wagging the dog at this point in time. AMD had no horse in the CPU race until the release of Ryzen, and Intel was doing things as they are today when they were still a worthless nothing outfit in the CPU realm. Had they not been doing things in the manner they are coming under fire for now, AMD's CPU offerings before Ryzen would have still been miles apart from Intel because their pre-Ryzen CPU architecture was pure garbage.

Plus, I do not want them to play fairly. They should behave as cut-throat rivals and if they do not we will all suffer the consequences. I am very happy that they are finally in a bitter feud over the CPU performance crown and hope that it escalates even more. I wish AMD had the financial resources and technical skill to engage NVIDIA in the same manner. The bitter battle is what drives innovation and excellence for consumers, and they both need to behave as though they are in it to win it. Chivalry has no place in battle.

And, we should all be very thankful that Intel is under scrutiny now for this swiftly over-hyped security concern rather than AMD. Intel will likely end up damaged over it, but they should have the resources to make it through the fire and still come out breathing after the smoke has cleared. Had the tables been turned, this scenario would have most likely dealt an unrecoverable fatal blow to AMD. I think AMD would likely cease to exist and we would be left with Intel being the only processor manufacturer to serve the needs of the masses.

This latent security issue is not new. What is new is the phenomenon that for the first time in more than a decade, AMD threatens to take a portion of Intel's long-held market share and diminish their deadly monopoly. When you start doing the math and reflecting on recent events, it really begs the question, why is this only becoming a talked-about issue now and who is behind the hype?

 

Ughhh why?

 

Decreased performance?

 

I thought the bug fix is supposed to increase performance by doing tricks on the CPU

 

YOU DON'T GET IT. This exploit has been there for every iCORE processor, and possibly as early as the core duo. It dates back a decade to when AMD was competitive. If it shows to have effected the core duo, cut 30% off that, and AMD had the faster CPUs then. So your saying don't play fair means they left security open in order to win the performance battle, which cost AMD money to be able to compete while putting customers at risk! That isn't competition, that is crony capitalism! Anything for a dollar is why our planet has more plastic in the ocean than all forms of ocean life by mass. That is why we have superfund cleanups and corporations poisoning water supplies across the country. That is why we have billion dollar cleanup sites or land set aside as uninhabitable for centuries. There is a point at which competition IS BAD! This is one of them!

This may be an old issue, but it was found due to experts finding row hammer exploits and ways to manipulate the kernel access even with the randomized placement in ram. In other words, it is because published security papers dealing with it where it was a certainty have only been published in 2016 and 2017. But, due to the nature of it, it begs the question on how Intel did not know of the predictive branch executing before permissions. THAT, if shown at the end of the embargo to be true, is more egregious than you realize, putting banks, wall street, etc. in a position that their pants were down for a decade.

Now, another difference is a decade ago, people didn't understand security as well. A lot more do now, hence such the growth in that field for the past decade.

Also, do the math. If you show Skylake, with the fix, is 17-23% slower, even though it still beat AMD's offerings, and you find similar in Kaby and potentially coffee, then, if AMD delivers on 40% going to 7nm ( https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/5/) and Intel's 10nm is **** ( https://www.semiaccurate.com/2017/12/20/state-intels-10nm-process/ ; https://www.fool.com/investing/2017/07/26/the-price-of-intel-corporations-10-nanometer-failu.aspx; https://videocardz.com/74285/intels-latest-roadmap-shows-hedt-cascade-lake-x-coming-in-q4-2018 ; I can't find the one where the industry insider spoke of how bad it was atm) with this slowdown on top, Intel practically is handing the performance crown over next gen, in all likelihood. Maybe not on gaming, but on other areas that matter to servers and commercial clients, there is a chance.

So this should be viewed as a ship correction. It moves the industry back to where it should have been the entire time.

 

Welcome to the circus.

Oh, yeah... I do get it. And, you're too smart to be an AMD shill and play the "fair" card. People need to connect the dots. There is no such thing as "fair" in technology. We need to stop making excuses for the underdog.

I'm not losing any sleep over it. Just disable Windows Update (services.msc) to block any patch crap from being installed and continue on your merry way. I honestly don't give a rat's ass about the over-hyped security bug everyone is whining about. It has been present for years, but it wasn't until recently that anyone cared. There's got to be some kind of "special" story going on behind the scenes. Think about it... AMD was a do-nothing loser company for more than a decade. They show up with some amazing CPUs that finally give Intel a run for the money (but suck at overclocking), Intel responds immediately with better products, and now suddenly they are being ferociously ridiculed for pissing on AMD's parade. Once all the smoke has cleared, and everyone pulls their panties out of their butt-cracks it is going to be interesting to see what follows. There has to be a reason that a "security issue" that has been around for multiple generations was never a big deal until now. If you believe nobody knew about it until the last 60 days, I have some ocean beach property in Arizona that you might be interested in.

 

This isn't about fair, it is the same as exposing your customers to toxic waste. THERE IS A DIFFERENCE!!! Here, drink from this free molecule arsenic laced cup! Unlike you, most of this world NEEDS security. No special story, it was the development of security experts that found the exploit and this being a derivative of kernel security research published last spring. That doesn't make it a "russian" ploy by AMD to sabotage Intel.

AMD's issue was a CEO that shelved good tech at the company and sat on its laurels, then became cash strapped in the ATI acquisition which hurt further R&D, etc. There is a logical explanation for AMD. This shows Intel never had that performance but for creating a permission elevation attack at the hardware level. And the real question is whether it can be traced to any serious security exploits over that period of time now that it was discovered. That means millions upon millions, if not billions, in security audits might need spent depending on the details of this exploit. And the fact you hint that Intel and others knew about it SHOWS Intel is about to get hit with MASSIVE lawsuits on the issue!

 

For a gaming only system I do not think security of the kernel is paramount. For a lot of other PC usage scenarios it becomes much more important. The issue has existed forever but it seems now it has become more of an issue.

That people all of a sudden care means there may be an issue out there. We will have to wait for the embargo to lift. It seems the issue was well known by all involved but just not previously taken as a serious problem.

As an example this was true of Windows 7 gadgets. Everything was fine until it was not. This has been seen over and over again. So this is to be expected.

 

I swear this is becoming the funniest thread i have ever read on this forum.
How about we all wait for the embargo to end before speaking, accusing and making "hate" statements based on the words of some journalists and random peeps on the web?

 

Why wait? That is the purpose of these forums, is it not? To speculate, and discuss possible ramifications of hardware, software issues?
I think it is fun to speculate, but is usually over blown in the end, or swept under the carpet as to not be over blown.

 

The issues will be watered down and forgotten in same way as last two flaws from Intel. Be patient. Nothing has really changed. New flaws will come. And we are on it again

 

Yes, discussing is completely fine to me but the content of last two pages is appaling. Most of what was written is random hate that was generated on the rumor that there will be a perfomance hit and that this was done to compete against another company. What's next? Will we get on "earth is flat" level? From what i read we're pretty close to that.

I just wish i could read more interestimg content and less ranting on intel or amd because someone woke up with a distorted view.

 

LOL, you must be new here. We are good at trashing big corporations, like Intel, AMD, Microslop, etc. IMO, and this isnt bashing, Intels track record as of late has been anything, but good. Some of the sketchy things they have done in the past has given me a fairly dim view of them. From the CEO selling off all the stocks he could legally, to waiting until after the Christmas holiday to announce this, makes it stink more than the deposit I left in the bathroom this morning.

 

Not that new but i understood the spirit of this forum after a year and i do like the ranting but sometimes, like this one, it just makes it impossible to read a topic. Going easy on the rant and focusing on the technical parts of this new flaw would be better imho.

 

I still like Windows Gadgets and the only reason I don't use them is the selection is too small to be interesting.

"Security" is a gigantic money maker in tech world. Everyone hypes it to the max and plays on the fears of the paranoid and ignorant. This paranoia is one of the primary reasons Micro$loth has been able to find any Kool-Aid drinkers for Windows 10.

Sure, identity theft and fraud are serious problems, but there is no magic bullet and as long as there is money to be made being a crook or wearing the white hat to serve as the protector of the innocent (and stupid) there will be a perceived need for the security wheel to keep on churning as they pull the arm on the digit slot machine. It is the same principle as big pharmaceuticals in medical science. Nobody gets better, everyone needs the new drug to keep them from dying, and the real crooks are the guys wearing the white hats.

Yes they will. Absolutely. Along with "very serious" flaws from AMD, NVIDIA, Micro$loth and other vendors. Those flaws, fabricated or not, make lots of money by offering solutions and they all need them to keep the axles greased and the cash cow pooping out golden cow patties.

 

This delicate situation is worth it’s weight in Gold for Micro$haft. Push out working patches for WinCrap X, but make the performance noticeably worse if you run older Win 7. Maybe we will finally see fast increased market shares for Win X for first time in long time

 

There was still as site somewhere, where you could get many gadgets. I will see if I can find it.

 

https://overclock3d.net/news/cpu_ma...pus_are_being_reported_as_insecure_on_linux/1
https://patchwork.kernel.org/patch/10133447/
" Update - An AMD patch for the Linux Kernel is now available here. Another workaround to prevent PTI from applying to AMD CPUs is to boot the kernel with the nopti command line parameter. We are currently hearing conflicting reports regarding this patch's merger with the mainline Linux Kernel. "

 

Yes, there is. They are all old and dated last time I checked. Nobody is developing new gadgets as far as I know. I used to love them.

 

My dad and I were discussing that last night and questioning if they would even patch the Win 7 kernel or not.

 

Have M$ any other choice?

 

Technically, the original Win 7 service period is over. They extended the long-term service branch. So, technically, security updates don't end until 2020 (see https://www.pcmag.com/article2/0,2817,2475079,00.asp). Funny enough, regular service updates end for Windows 8 on Jan. 9 of this year. So they will likely patch it, but only because of previous press statements, otherwise, if this was 2020, they would say **** off and upgrade.