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

Discussion in 'Hardware Components and Aftermarket Upgrades' started by hmscott, Jan 2, 2018.

  1. hmscott

    hmscott Notebook Nobel Laureate

    Reputations:
    3,852
    Messages:
    14,105
    Likes Received:
    16,801
    Trophy Points:
    931
    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."

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

    [​IMG]

    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...
     
    Last edited: Jan 18, 2018 at 9:29 AM
    Robbo99999, tiliarou, Ashtrix and 7 others like this.
  2. don_svetlio

    don_svetlio Notebook Virtuoso

    Reputations:
    249
    Messages:
    3,380
    Likes Received:
    1,671
    Trophy Points:
    231
    Suddenly, Ryzen mobile seems a lot more appealing....
     
  3. TANWare

    TANWare Just This Side of Senile, I think. Moderator

    Reputations:
    2,167
    Messages:
    8,531
    Likes Received:
    3,168
    Trophy Points:
    431
    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. :)
     
  4. hmscott

    hmscott Notebook Nobel Laureate

    Reputations:
    3,852
    Messages:
    14,105
    Likes Received:
    16,801
    Trophy Points:
    931
    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
    "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. "
    [​IMG]
    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:
    intel minimum required stock positions.JPG
    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
     
    Last edited: Jan 2, 2018
  5. Mr. Fox

    Mr. Fox Undefiled BGA-Hating Elitist

    Reputations:
    19,837
    Messages:
    30,481
    Likes Received:
    38,706
    Trophy Points:
    931
    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.

    [​IMG]
    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.
     
    Last edited: Jan 3, 2018
    Ashtrix, pressing, KY_BULLET and 7 others like this.
  6. saturnotaku

    saturnotaku Notebook Prophet

    Reputations:
    3,285
    Messages:
    6,530
    Likes Received:
    1,824
    Trophy Points:
    331
    How does the old saying go - never interrupt your enemy when he is making a mistake?
     
    alexhawker, Papusan, Vasudev and 3 others like this.
  7. Mr. Fox

    Mr. Fox Undefiled BGA-Hating Elitist

    Reputations:
    19,837
    Messages:
    30,481
    Likes Received:
    38,706
    Trophy Points:
    931
    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.
     
  8. Raiderman

    Raiderman Notebook Evangelist

    Reputations:
    242
    Messages:
    476
    Likes Received:
    993
    Trophy Points:
    106
    Regardless, it doesnt sound good for Intel
     
  9. Mr. Fox

    Mr. Fox Undefiled BGA-Hating Elitist

    Reputations:
    19,837
    Messages:
    30,481
    Likes Received:
    38,706
    Trophy Points:
    931
    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.
     
  10. ajc9988

    ajc9988 Death by a thousand paper cuts

    Reputations:
    1,083
    Messages:
    4,464
    Likes Received:
    6,134
    Trophy Points:
    581
    This isn't artificial. In fact, it suggests due to Intel playing fast and loose with security, they artificially inflated performance.
     
    Ashtrix, Papusan, Dr. AMK and 2 others like this.
Loading...

Share This Page