Siden den 3. januar 2018 har der været en masse modstridende og muligvis alarmerende oplysninger offentliggjort om den spekulative henrettelsesside -kanalsårbarheder også kendt som Meltdown og Spectre, der påvirker de fleste moderne processorer i varierende grad. Især Meltdown-udnyttelsen (CVE-2017-5754) påvirker kun Intel-processorer. Beskyttelse af dine systemer mod disse sårbarheder involverer en række trin for de fleste systemer afhængigt af det miljø, som SQL Server kører i, og hvilken funktionalitet, der bruges.
Det vejledende princip er, at sikkerhedshensyn bør tilsidesætte præstationsbekymringer. At ignorere disse sikkerhedssårbarheder og ikke foretage den nødvendige patching på grund af mulige præstationsproblemer ville være en stor fejltagelse (og muligt juridisk ansvar) for de fleste organisationer. Der er allerede blevet publiceret forskning om nye variationer af Meltdown og Spectre, så denne type problemer vil ikke forsvinde snart. Derudover har sikkerhedsleverandører rapporteret beviser for Spectre/Meltdown-angreb i naturen.
Desværre er det blevet mere og mere komplekst og forvirrende at beslutte, hvad du faktisk skal gøre ved dine systemer for at beskytte dem mod disse sårbarheder, efterhånden som tiden er gået, med skiftende oplysninger om sårbarheden, der udgives af Intel og AMD, og med både CPU-mikrokode og operativsystem. plastre frigives og kort efter trækkes tilbage.
Ydeevnepåvirkning af patching
Afhængigt af din serverhardware, operativsystem, arbejdsbyrde og hvilke patches du ender med at installere, er det sandsynligt, at du vil se en negativ effekt på ydeevnen fra disse afbødende foranstaltninger. Microsofts Terry Myerson har et ret detaljeret indlæg om dette emne, mens Netflix's Brendan Gregg har nogle detaljerede resultater om Linux. Brandon Lee har lavet nogle syntetiske benchmark-tests i et VMware-miljø her.
Den gode nyhed er, at de fleste ydelsesregressioner, der er et resultat af denne patch-indsats, kan reduceres med korrekt konfiguration og justering af arbejdsbelastning i SQL Server. Brug af overvågningsprodukter som SentryOne's SQL Sentry kan hjælpe dig med at identificere de præstationsflaskehalse, der findes i dit miljø.
For mange organisationer vil det at blive fuldt opdateret på deres implementerede SQL Server-build (som en bivirkning af patching til Spectre/Meltdown) løse mange andre problemer og potentielt forbedre deres ydeevne nok til at hjælpe med at kompensere for eventuelle præstationsregressioner, de ser fra det komplette sæt af Spectre/Meltdown patches. Læsning af rettelseslisten for hver SQL Server CU afslører normalt en række præstationsrelaterede rettelser, der kan have en væsentlig indvirkning på ydeevnen for SQL Server.
Moderne Intel-processorer har PCID- og INVPCID-understøttelse, hvilket væsentligt reducerer ydeevnepåvirkningen af Meltdown-operativsystempatchen. Dette betyder, at du får Windows OS-understøttelse til PCID-ydeevneoptimering i Intel Xeon E5-2600 v3 produktfamilie (Haswell-EP) og senere processorer sammen med Intel Xeon E7 v3 produktfamilien (Haswell-EX) og senere processorer.
Hvis dine Intel-processorer er ældre end Haswell-mikroarkitekturen (som blev udgivet i Q3 2014 til to-socket-servere), giver dette dig så meget desto mere grund til at planlægge en hardwareopgradering. Jeg har skrevet om hvordan du bruger Microsoft CoreInfo til nemt at tjekke om din processor har PCID og INVPCID support. Jeg har også lavet nogle syntetiske benchmark-tests på et nyere Intel Kaby Lake-system.
Microsoft har en ny Windows Analytics-funktion, som du kan bruge til at kontrollere Spectre/Meltdown-patch-statussen for alle dine maskiner. Microsoft har også et PowerShell-modul, som du kan bruge til at kontrollere den overordnede patch-status (fra et Windows- og hardwareperspektiv), som jeg diskuterede her. Hvis du vil lave en hurtig og nem kontrol af et klientoperativsystem for en slutbruger (eller din mor) uden at skulle håndtere PoSH, kan du downloade og køre InSpectre-værktøjet (med en nem GUI) for at tjekke patchen status for dit operativsystem og din processormikrokode.
Tjek din SQL Server-instans
Til sidst skal du kontrollere status for din SQL Server-patch. Jeg har udviklet et T-SQL-script, der vil tjekke din SQL Server-instans for at se, om du har installeret de relevante SQL Server-patches eller ej. Dette script fungerer på SQL Server 2008 til og med SQL Server 2017 for lokale forekomster eller for Azure IaaS-forekomster. Dette er ikke designet til at fungere på Azure SQL Database. Du kan downloade den her.
En mulig fordel ved dette problem er, at det kan give dig mere begrundelse for at få din organisation til at få dine SQL Server-forekomster opdaterede med deres Service Pack og kumulative opdateringer, hvilket Microsoft alligevel udtrykkeligt anbefaler.
Spectre/Meltdown Mitigation Steps
Her er de afhjælpende trin, du kraftigt bør overveje at tage:
- Installer den relevante patch til operativsystemet fra Microsoft (hvis tilgængelig)
- Tilgængelig til Windows Server, version 1709, Windows Server 2016, Windows Server 2012 R2 og Windows Server 2008 R2
- Ikke tilgængelig endnu for Windows Server 2012 eller Windows Server 2008 (pr. 15. februar 2018)
- Foretag de nødvendige konfigurationsændringer (registreringsindstillinger) for at aktivere operativsystembeskyttelse på serveroperativsystemer
- Hvis du kører på en Hypervisor, skal du installere de relevante Hypervisor-patches
- VMware vSphere, Workstation og Fusion-opdateringer tilføjer Hypervisor-Assisted Guest Remediation for spekulativt eksekveringsproblem
- Installer den relevante SQL Server-patch fra Microsoft
- Tilgængelig til SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012 SP4, SQL Server 2008 R2 SP3 og SQL Server 2008 SP4
- Ikke tilgængelig for SQL Server 2005 eller tidligere
- Installer en BIOS-opdatering (som har en CPU-mikrokodeopdatering) fra din serverleverandør (hvis tilgængelig)
- Dette afhænger af, hvilken processor du bruger, sammen med dit miljø og din funktion
- Disse BIOS-opdateringer er i øjeblikket ikke tilgængelige for de fleste servere (de blev oprindeligt udgivet til nogle nyere servere og derefter trukket tilbage)
- Vurder, hvilke SQL Server-udvidelsesfunktioner, du muligvis bruger, og hvilke yderligere begrænsningstrin, du muligvis skal tage. Disse omfatter:
- SQL CLR-samlinger
- R- og Python-pakker, der kører gennem den eksterne script-mekanisme eller kører fra det selvstændige R/Machine Learning-studie på den samme fysiske maskine som SQL Server
- SQL Agent-udvidelsespunkter kører på den samme fysiske maskine som SQL Server (ActiveX-scripts)
- Ikke-Microsoft OLE DB-udbydere, der bruges i sammenkædede servere
- Ikke-Microsoft Extended Stored Procedures
- COM-objekter udført på serveren (adgang til via sp_OACreate)
- Programmer udført via xp_cmdshell