Beveiligingsonderzoekers vonden begin 2018 kwetsbaarheden in processors, die de naam Spectre meekregen. Inmiddels zijn hier diverse oplossingen voor uitgerold, maar die blijken ook voor flink lagere prestaties te zorgen in Linux-systemen. Nu is er een optie bijgekomen om de oplossingen uit te schakelen, meldt ZDNet.
In diverse benchmarks werd duidelijk dat Linux 4.20 flink moet inleveren op zijn prestaties door de oplossingen voor Spectre. Zo gaven de testresultaten van Phoronix aan dat een Intel Core i9-7980XE er sinds de Linux 4.20-kernel er 1,28 keer langer over doet in de Rodina 2,4 heterogenous compute benchmark suite. En in de DaCapo benchmark is een keldering van bijna 50 procent zichtbaar.
Diverse systeem- en netwerkadministrators hebben in het afgelopen jaar het Linux-project dan ook gevraagd voor opties om de beschermingen uit te schakelen. Velen stellen dat de dreiging theoretisch is en eenvoudig in de hand kan worden gehouden met goede perimeter-beschermingen. Zelfs Linus Torvalds vroeg om een vertraging in de deployment van sommige oplossingen die de prestaties verlagen.
Opties
Het team achter de Linux kernel heeft hier positief op gereageerd en rolt langzaamaan opties uit om een deel van de problematische oplossingen uit te schakelen. Sinds Linux Kernel 4.15 is het bijvoorbeeld mogelijk om de ingebouwde oplossingen voor de Spectre v2-kwetsbaarheid uit te schakelen met de “nospectre_v2” kernel command line parameter.
Systeemadministratoren wilden echter ook een manier om te zorgen dat de oplossingen helemaal niet aan gingen, waardoor er drie nieuwe parameters bij zijn gekomen in recente kernel-releases. De laatste optie om de oplossingen uit te schakelen en uitgeschakeld te houden, is de toevoeging van de PR_SPEC_DISABLE_NOEXEC control in de kernel.
Deze optie voorkomt dat child-processen beginnen in een staat waarin de beschermingen voor Spectre v4 nog steeds geactiveerd zijn, ook al zijn ze gedeactiveerd in het parent-proces. Experts stellen dat sommige processen geen Spectre-oplossingen nodig hebben en dat de impact op de prestaties belangrijker is dan die op de beveiliging, zeker in gesloten systemen waar malafide code niet geïntroduceerd kan worden.