Over the last couple of days, you have probably heard quite a bit of chatter and speculation about some newly disclosed ways to attack various processors. The initial reports were that only Intel processors were affected, but some sources indicate that some AMD and ARM processors are also vulnerable.<\/span><\/p>\n Security researchers at Graz University (who were involved with the initial discovery of these issues) have put up a site, complete with cute logos<\/a>, with some useful information about these two exploits. <\/span>The most detailed information so far about the attack methods comes from Google Project Zero, as shown here: <\/span>Reading privileged memory with a side-channel<\/span><\/a>. Their testing shows some limited vulnerability for some older AMD processors.<\/span><\/p>\n AMD is pretty adamant that their processors are not vulnerable to these exploits, as shown by this statement from AMD\u2019s Tom Lendacky:<\/span><\/p>\n \u201cAMD processors are not subject to the types of attacks that the kernel Linus Torvalds also seems pretty confident that AMD is not affected, as witnessed by his comments in a recent code check-in<\/a>:<\/span><\/p>\n \u201cExclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead”<\/span><\/p>\n<\/blockquote>\n Paul Alcorn has a pretty good write-up about this issue here<\/a>. Yesterday, Phoronix published some early benchmark results against a patched version of Linux that were pretty alarming for some use cases (synthetic IO benchmarks and PostgreSQL database performance).<\/span><\/p>\n Redhat has published some information about the performance impact of OS fixes on several different workload types. The most notable is what they define as<\/span><\/p>\n \u201cMeasureable: 8-19% – Highly cached random memory, with buffered I\/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions are impacted between 8-19%. Examples include OLTP Workloads (tpc), sysbench, pgbench, netperf (< 256 byte), and fio (random I\/O to NvME)\u201d<\/font><\/p>\n<\/blockquote>\n More details about these findings and some mitigation methods for RHEL are available in these links:<\/font><\/p>\n Speculative Execution Exploit Performance Impacts – Describing the performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715<\/a><\/font><\/p>\n Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables <\/font><\/a><\/p>\n<\/blockquote>\n It seems like the various fixes for these issues are going to hit database and virtualization performance harder than most other use cases. I wonder whether it will be possible for Intel to at least partially fix the issue with a stepping change on any Intel processors that are still in production (i.e. they make an actual hardware fix using the same existing processor design) that lets them send out replacement processors that work in some existing servers.<\/span><\/p>\n If you are old enough to remember the <\/span>old Pentium FDIV bug in 1994<\/span><\/a>, Intel initially tried to minimize the issue, saying that it was very rare. Then, they tried to make people prove that they were hitting the bug by running an Intel utility. Finally, they caved in to bad PR and ended up sending out replacement CPUs to a lot of people, no questions asked, which cost them $475 million back in the day. I remember swapping out my CPU, because I was a geek back then too!<\/span><\/p>\n Early this morning, Microsoft published this KB article: <\/span>SQL Server Guidance to protect against speculative execution side-channel vulnerabilities<\/span><\/a>. According to Microsoft<\/span>, the following versions of SQL Server are impacted when running on x86 and x64 processor systems: SQL Server 2008, SQL Server 2008R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017.<\/span><\/p>\n Microsoft has already issued two Cumulative Updates that include fixes to help mitigate this issue (along with the other important hotfixes included in each CU).<\/span><\/p>\n Cumulative Update 3 for SQL Server 2017<\/span><\/a><\/p>\n Cumulative Update 7 for SQL Server 2016 SP1<\/span><\/a><\/p>\n<\/blockquote>\n I suspect that there will be an out of band CU or hotfix for SQL Server 2014 SP2 relatively soon, since it is still in Mainstream support. Even though SQL Server 2012 and older are out of Mainstream support, Microsoft will probably develop and release hotfixes for those releases relatively soon since this is a security issue.<\/span><\/p>\n Microsoft has also started pushing out an out of band OS update for Windows 10 (KB4056892<\/a>) that is meant to mitigate this issue. There are similar updates for most other supported Microsoft operating systems. Here is the current information for Windows Server:<\/span><\/p>\n Windows Server guidance to protect against speculative execution side-channel vulnerabilities<\/font><\/a><\/p>\n<\/blockquote>\n Here is Microsoft\u2019s current security advisory advice:<\/span><\/p>\n ADV180002 | Guidance to mitigate speculative execution side-channel vulnerabilities<\/a><\/span><\/p>\n<\/blockquote>\n Microsoft has also released this statement about how they have been handling this for Microsoft Azure<\/span><\/p>\n Securing Azure customers from CPU vulnerability<\/a><\/span><\/p>\n<\/blockquote>\n Here is what I plan on doing over the next couple of weeks as this starts to shake out:<\/span><\/p>\n Here is what I think you should be doing:<\/span><\/p>\n Plan on getting your database servers patched as soon as possible, which will include OS patches, SQL Server patches, and possible firmware or BIOS\/UEFI updates as they become available. <\/span><\/p>\n Be ready to do some workload and query tuning as necessary if your workload performance is negatively affected by these various patches and updates.<\/span><\/p>\n Think harder about upgrading to new hardware, a newer version of your OS, and a newer version of SQL Server that is still fully supported.<\/span><\/p>\n For personal and client workstation systems, you should be checking to see if there are any firmware or BIOS\/UEFI updates that become available, both for these issues and as a general best practice. <\/span><\/p>\n Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities<\/a><\/font><\/p>\n<\/blockquote>\n I am collecting some resources about this issue from the server vendors as shown in the links below:<\/font><\/p>\n Cisco<\/font><\/p>\n CPU Side-Channel Information Disclosure Vulnerabilities<\/a><\/font><\/p>\n<\/blockquote>\n Dell<\/font><\/p>\n Microprocessor Side-Channel Attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754): Impact on Dell EMC products (Dell Enterprise Servers, Storage and Networking)<\/font><\/p>\n<\/blockquote>\n Microprocessor Side-Channel Attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754): Impact on Dell products<\/a> (This is for client hardware)<\/font><\/p>\n<\/blockquote>\n Fujitsu<\/font><\/p>\n CPU hardware vulnerable to side-channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754)<\/a><\/p>\n<\/blockquote>\n HPE<\/font><\/p>\n Side Channel Analysis Method allows information disclosure in Microprocessors (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754)<\/a><\/font><\/p>\n<\/blockquote>\n Huawei<\/font><\/p>\n Security Notice – Statement on the Media Disclosure of the Security Vulnerabilities in the Intel CPU Architecture Design<\/a><\/font><\/p>\n<\/blockquote>\n IBM<\/font><\/span><\/p>\n Potential CPU Security Issue<\/a><\/font><\/span><\/p>\n<\/blockquote>\n Lenovo<\/font><\/p>\n Reading Privileged Memory with a Side Channel<\/a><\/font><\/p>\n<\/blockquote>\n\n
\npage table isolation feature protects against. The AMD microarchitecture
\ndoes not allow memory references, including speculative references, that
\naccess higher privileged data when running in a lesser privileged mode
\nwhen that access would result in a page fault.
\nDisable page table isolation by default on AMD processors by not setting
\nthe X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
\nis set.\u201d<\/span><\/p>\n<\/blockquote>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
<\/font><\/p>\n\n
\n
\n
\n
\n
\n
\n
\n