Sedan den 3 januari 2018 har det publicerats en hel del motstridiga och möjligen alarmerande information om den spekulativa avrättningssidan -kanalssårbarheter även kända som Meltdown och Spectre som påverkar de flesta moderna processorer i varierande grad. Meltdown-missbruket (CVE-2017-5754) påverkar i synnerhet bara Intel-processorer. Att skydda dina system från dessa sårbarheter innebär ett antal steg för de flesta system beroende på miljön som SQL Server körs i och vilken funktionalitet som används.
Den vägledande principen är att säkerhetsproblem ska åsidosätta prestationsproblem. Att ignorera dessa säkerhetsbrister och inte göra den nödvändiga korrigeringen på grund av möjliga prestandaproblem skulle vara ett stort misstag (och eventuellt juridiskt ansvar) för de flesta organisationer. Det har redan publicerats forskning om nya varianter av Meltdown och Spectre, så den här typen av problem kommer inte att försvinna när som helst snart. Dessutom har säkerhetsleverantörer rapporterat bevis på Spectre/Meltdown-attacker i det vilda.
Tyvärr har det blivit allt mer komplext och förvirrande allt eftersom tiden har gått att bestämma vad du faktiskt ska göra med dina system för att skydda dem mot dessa sårbarheter, med ändrad information om sårbarheten som släpps av Intel och AMD, och med både CPU-mikrokod och operativsystem plåster som släpps och sedan kort senare dras tillbaka.
Performanspåverkan av patchning
Beroende på din serverhårdvara, operativsystem, arbetsbelastning och vilka patchar du installerar, är det troligt att du kommer att se negativ prestandapåverkan från dessa begränsningsåtgärder. Microsofts Terry Myerson har ett ganska detaljerat inlägg om detta ämne, medan Netflixs Brendan Gregg har några detaljerade resultat på Linux. Brandon Lee har gjort några syntetiska benchmark-tester i en VMware-miljö här.
Den goda nyheten är att de flesta prestandaregressioner som är ett resultat av denna korrigeringsansträngning kan minskas med korrekt konfiguration och justering av arbetsbelastningen i SQL Server. Att använda övervakningsprodukter som SentryOnes SQL Sentry kan hjälpa dig att identifiera de prestandaflaskhalsar som finns i din miljö.
För många organisationer kommer det att lösa många andra problem och potentiellt förbättra deras prestanda tillräckligt för att kompensera för eventuella prestandaregressioner som de ser från den kompletta uppsättningen Spectre/Meltdown patchar. Att läsa korrigeringslistan för varje SQL Server CU avslöjar vanligtvis ett antal prestandarelaterade korrigeringar som kan ha en betydande prestandapåverkan för SQL Server.
Moderna Intel-processorer har stöd för PCID och INVPCID, vilket avsevärt minskar prestandapåverkan från Meltdown-operativsystempatchen. Det betyder att du får Windows OS-stöd för PCID-prestandaoptimering i produktfamiljen Intel Xeon E5-2600 v3 (Haswell-EP) och senare processorer, tillsammans med produktfamiljen Intel Xeon E7 v3 (Haswell-EX) och senare processorer.
Om dina Intel-processorer är äldre än Haswell-mikroarkitekturen (som släpptes under Q3 2014 för två-sockets servrar), ger detta dig desto större anledning att planera för en hårdvaruuppgradering. Jag har skrivit om hur du använder Microsoft CoreInfo för att enkelt kontrollera om din processor har stöd för PCID och INVPCID. Jag har också gjort några syntetiska benchmark-tester på ett nyare Intel Kaby Lake-system.
Microsoft har en ny Windows Analytics-funktion som du kan använda för att kontrollera Spectre/Meltdown patch-status för alla dina maskiner. Microsoft har också en PowerShell-modul som du kan använda för att kontrollera den övergripande patchstatusen (ur ett Windows- och hårdvaruperspektiv) som jag diskuterade här. Om du vill göra en snabb och enkel kontroll av ett klientoperativsystem för en slutanvändare (eller din mamma) utan att behöva ta itu med PoSH, kan du ladda ner och köra InSpectre-verktyget (med ett enkelt GUI) för att kontrollera patchen status för ditt operativsystem och din processormikrokod.
Kontrollera din SQL Server-instans
Slutligen måste du kontrollera din SQL Server-patchstatus. Jag har utvecklat ett T-SQL-skript som kontrollerar din SQL Server-instans för att se om du har installerat de relevanta SQL Server-korrigeringarna eller inte. Det här skriptet kommer att fungera på SQL Server 2008 till och med SQL Server 2017 för lokala instanser eller för Azure IaaS-instanser. Detta är inte utformat för att fungera på Azure SQL Database. Du kan ladda ner den här.
En möjlig fördel med det här problemet är att det kan ge dig mer motivering för att få din organisation att få dina SQL Server-instanser aktuella med deras Service Pack och kumulativa uppdateringar, vilket är vad Microsoft uttryckligen rekommenderar ändå.
Spectre/Meltdown Mitigation Steps
Här är de begränsningssteg du bör överväga att vidta:
- Installera relevant operativsystempatch från Microsoft (om tillgängligt)
- Tillgänglig för Windows Server, version 1709, Windows Server 2016, Windows Server 2012 R2 och Windows Server 2008 R2
- Ännu inte tillgängligt för Windows Server 2012 eller Windows Server 2008 (från och med 15 februari 2018)
- Gör nödvändiga konfigurationsändringar (registerinställningar) för att aktivera operativsystemskyddet på serveroperativsystem
- Om du kör på en Hypervisor, installera de relevanta Hypervisor-korrigeringarna
- VMware vSphere, Workstation och Fusion-uppdateringar lägger till Hypervisor-Assisted Guest Remediation för spekulativa exekveringsproblem
- Installera den relevanta SQL Server-patchen från Microsoft
- Tillgänglig för SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012 SP4, SQL Server 2008 R2 SP3 och SQL Server 2008 SP4
- Inte tillgängligt för SQL Server 2005 eller tidigare
- Installera en BIOS-uppdatering (som har en CPU-mikrokoduppdatering) från din serverleverantör (om tillgänglig)
- Detta beror på vilken processor du använder, tillsammans med din miljö och funktionsanvändning
- Dessa BIOS-uppdateringar är för närvarande inte tillgängliga för de flesta servrar (de släpptes från början för vissa nyare servrar och drogs sedan tillbaka)
- Utvärdera vilka SQL Server-utbyggnadsfunktioner du kan använda och vilka ytterligare begränsningssteg du kan behöva vidta. Dessa inkluderar:
- SQL CLR-sammansättningar
- R- och Python-paket som körs genom den externa skriptmekanismen eller körs från den fristående R/Machine Learning-studion på samma fysiska maskin som SQL Server
- SQL Agent-utvidgningspunkter som körs på samma fysiska dator som SQL Server (ActiveX-skript)
- Icke-Microsoft OLE DB-leverantörer som används i länkade servrar
- Icke-Microsoft Extended Stored Procedures
- COM-objekt körda på servern (åtkomst via sp_OACreate)
- Program körda via xp_cmdshell