Checking Your SQL Server Instance for Spectre/Meltdown Patches

If you are running SQL Server 2008 through SQL Server 2017, you should be thinking about what you should be doing to protect your systems from the Meltdown and Spectre vulnerabilities. Microsoft has a number of KB articles that address this issue from several different perspectives. This is a good starting list:

SQL Server Guidance to protect against speculative execution side-channel vulnerabilities (SQL Server)

Windows Server guidance to protect against speculative execution side-channel vulnerabilities (Windows Server)

Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities (Windows Client)

The basic guidance is that depending on the environment where you are running SQL Server (on-premises or not, virtualized or not, in a cloud IaaS VM or not) and whether you are using any open extensibility interfaces or not (things like some types of CLR assemblies, some types of linked servers, etc.), you are going to want to strongly consider patching several layers of your system. These may include:

  • Operating System patches
  • Registry changes
  • SQL Server patches
  • BIOS/UEFI updates
  • Possible changes in how/whether you use any open extensibility interfaces in SQL Server

The Microsoft guidance about SQL Server gives some pretty clear scenarios and guidelines for making the decision on what to patch or change.


Checking Your Operating System and Hardware

Once you have decided what to patch, the next issue is checking your patch and update status at all of these different layers of the system. Microsoft has a PowerShell script that lets you check the patch status of your operating system and your processor microcode (for Intel processors).

This Microsoft KB article explains this in more detail and has a link to download the PowerShell Module for operating systems prior to Windows Server 2016.

Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities

If you want to do a quick and easy check of a client operating system for an end-user (or your Mom) without having to deal with PoSH, you can download and run the InSpectre utility (with an easy GUI) to check the patch status of your operating system and your processor microcode.


Checking SQL Server

Finally, you need to check your SQL Server patch status. I have developed (and had a number of people help test) a T-SQL script that will check your SQL Server instance to see whether you have installed the relevant SQL Server patches or not. This script will work on SQL Server 2008 through SQL Server 2017 for on-premises instances or for Azure IaaS instances. This is not designed to work on Azure SQL Database. You can download it here.

Please let me know if you have any suggestions about this. I also want to thank the people who have tested this script and given me feedback!




Checking Your Intel Processor Features Regarding the Meltdown Exploit

By now, you have probably heard plenty about the Spectre and Meltdown exploits that affect many modern processors. The Meltdown exploit (CVE-2017-5754) in particular only affects Intel processors.

Microsoft has already patched most of their client and server operating systems to mitigate against Meltdown. Depending on the exact model of Intel processor you are using, the Microsoft operating system patch will take advantage of processor support for two specific features and instructions which help minimize the performance impact of the operating system patch for Meltdown by using kernel page-table isolation.

These two instructions are process-context identifiers (PCID) and invalidate process-context identifiers (INVPCID). If your Intel processor supports both of these instructions, then the patched version of Windows will take advantage of that to give you better performance than you would otherwise get without those two instructions.

I have previously written about how to use PowerShell to check your Meltdown and Spectre mitigation status in Windows. Using that PowerShell module will give you a complete view of your Meltdown and Spectre mitigation status.

If your Intel processor supports both PCID and INVPCID, then you will see this message at the bottom of the PowerShell results:

Windows OS support for PCID performance optimization is enabled: True [not required for security]

Another way to check what features that your processor supports (whether it is AMD or Intel) is the Coreinfo v3.31 tool from Microsoft. You need to download the zip file, and then unzip it and copy the coreinfo.exe file to where you want it.

You can then simply use a command prompt to run Coreinfo –f > CoreInfoResults.txt to dump the core feature information for the processor to a text file in the same directory as the coreinfo.exe file as you see in Figure 1.


image

Figure 1: Running Coreinfo with the –f flag and saving the results to a text file


If your Intel processor supports the PCID feature and the INVPCID instruction, you will see an asterisk in the result (which is towards the bottom of the file), as you see below:

PCID            *    Supports PCIDs and settable CR4.PCIDE
INVPCID       *    Supports INVPCID instruction

If your Intel processor does not support either or both of the PCID feature and the INVPCID instruction, you will see a dash in the result, as you see below:

PCID            –   Supports PCIDs and settable CR4.PCIDE
INVPCID       –   Supports INVPCID instruction

It is possible to for a processor to support PCID and not support INVPCID. My understanding from the Microsoft Powershell code is that you need both to get Windows OS support for the PCID performance optimization.

From what information that I have been able to dig up (and from also asking a source at Intel), PCID is supported in some Westmere family and most Sandy Bridge family processors, with server processors getting support before client processors. According to Intel documentation, INVPCID support was introduced in the Haswell family processors.

This means you will get Windows OS support for the PCID performance optimization in Intel Xeon E5-2600 v3 product family (Haswell-EP) and later processors, along with the Intel Xeon E7 v3 product family (Haswell-EX) and later processors.

In my mind, this is even more justification for a new server or hopefully a complete data platform upgrade, where you get a brand new server running Windows Server 2016, along with SQL Server 2017. If you are thinking along the same lines, SQLskills can help you plan and implement an upgrade and migration.


Update: 1-12-2018

I ran CoreInfo on every Intel client machine that I own (a total of 16 machines, which is way too many)! The oldest is a 2008-vintage Intel Core2 Quad Q9550 (Yorkfield), which as expected, has neither PCID or INVPCID support. The next oldest is a 2009-vintage Intel Core i7-720QM (Clarksfield) which also has neither PCID or INVPCID support. I don’t have any Nehalem or Westmere machines.

After that, my oldest machine is a Q1 2011-vintage Intel Core i7-2600K (Sandy Bridge), which has PCID support, but does not have INVPCID support. The situation is the same for a Q1 2012-vintage Intel Core i7-3770K (Ivy Bridge) which has PCID support, but does not have INVPCID support.

With a Q2 2013-vintage Intel Core i5-4670K (Haswell), we finally get both PCID and INVPCID support. My newest Intel machine has a Q4 2017-vintage Intel Core i7-8700K (Coffee Lake) which also has both PCID and INVPCID support.




SQL Server Diagnostic Information Queries for January 2018

This month, there are more minor updates to the all of the versions of the queries, primarily in the comments and documentation. There are also links for the Spectre/Meltdown hotfixes for SQL Server 2008 SP4 and SQL Server 2008 R2 SP3.

I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.

Rather than having a separate blog post for each version, I have just put the links for all eight major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.

Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2017, 2016, and 2014:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 Diagnostic Information Queries

SQL Server 2016 Blank Results Spreadsheet

SQL Server 2014 Diagnostic Information Queries

SQL Server 2014 Blank Results Spreadsheet

Here are links to the most recent versions of these scripts for SQL Server 2012 and older:

Since SQL Server 2012 and older are out of Mainstream support from Microsoft (and because fewer of my customers are using these old versions of SQL Server), I am not going to be updating the scripts for these older versions of SQL Server every single month going forward.  I started this policy a while ago, and so far, I have not heard any complaints.

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

SQL Server 2008 R2 Diagnostic Information Queries

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries

SQL Server 2005 Blank Results Spreadsheet

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results (and my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have quite a few comments and links in the script on how to interpret the results after each query.

After running each query, you need to click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet.

About half of the queries are instance specific and about half are database specific, so you will want to make sure you are connected to a database that you are concerned about instead of the master system database. Running the database-specific queries while being connected to the master database is a very common mistake that I see people making when they run these queries.

Note: These queries are stored on Dropbox. I occasionally get reports that the links to the queries and blank results spreadsheets do not work, which is most likely because Dropbox is blocked wherever people are trying to connect. I am not planning on moving these to Github any time soon.

I also occasionally get reports that some of the queries simply don’t work. This usually turns out to be an issue where people have some of their user databases in 80 compatibility mode, which breaks many DMV queries, or that someone is running an incorrect version of the script for their version of SQL Server.

It is very important that you are running the correct version of the script that matches the major version of SQL Server that you are running. There is an initial query in each script that tries to confirm that you are using the correct version of the script for your version of SQL Server. If you are not using the correct version of these queries for your version of SQL Server, some of the queries are not going to work correctly.

If you want to understand how to better run and interpret these queries, you should consider listening to my three related Pluralsight courses, which are SQL Server 2014 DMV Diagnostic Queries – Part 1SQL Server 2014 DMV Diagnostic Queries – Part 2 and SQL Server 2014 DMV Diagnostic Queries – Part 3. All three of these courses are pretty short and to the point, at 67, 77, and 68 minutes respectively. Listening to these three courses is really the best way to thank me for maintaining and improving these scripts…

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!