Поправянето на грешката води до намаляване на производителността на системите с до 30%, сочат тестове
Фундаментална грешка във всички съвременни процесори на Intel, пуснати в последните 10 години, застави разработчиците на Linux и Windows спешно да пренаписват големи части от кода, за да затворят
уязвимостта.
Пълните подробности за уязвимостта са под ембарго, докато не бъде пусната кръпка, което се очаква да стане към средата на 2018 г., заедно с новото ядро на Linux и ежемесечното обновление на
сигурността на Windows. Възможно е проблемът вече да е решен още в ядрото 4.14.11, като се има предвид големия размер на инкременталния пач, пише TechNews.bg.
Към момента е известно, че преодоляването на хардуерния проблем може да доведе до спад в производителността на приложенията за Intel процесори с 5 до 30% и дори с 63% за някои задачи. По-новите
чипове на Intel имат възможности да намалят спада на производителността при прилагане на очакваните кръпки.
От AMD уверяват, че в техните процесори липсва подобна уязвимост, но такава вероятно е налична и в чиповете с архитектура ARM 64, според публикацията по проблема в theregister.co.uk. На обновление
подлежат не само Windows и Linux за x86, но и епълската macOS.
Същността на уязвимостта е, че при спекулативно изпълнение на код, процесорите на Intel не проверяват сигурността на инструкциите, които четат сегменти от паметта. А това позволява на всяко
потребителско приложение да получи достъп до паметта на ядрото и по този начин да прочете затворени данни от рода на криптиращи ключове и пароли. Описаният проблем представлява голяма опасност и за
системите за виртуализация.
За решаване на проблема разработчиците прибегнали до пълно разделяне на паметта на ядрото и паметта на потребителските процеси. Подобно решение обаче води до сериозен спад в производителността,
заради постоянната необходимост от замяна на указателите на паметта.
Разработчиците на ядрото на Linux на шега предлагали абревиатури за новите модели за разделяне на паметта на ядрото и потребителските процеси: User Address Separation (*_uass) и Forcefully Unmap
Complete Kernel With Interrupt Trampolines (fuckwit_*), но в крайна сметка избрали по-отговорното Kernel Page Table Isolation (kpti_*).
Специалисти от GRSecurity са тествали кръпките и съобщават за огромен спад в производителността на системите. Техните наблюдения се потвърждават и от разработчиците на PostgreSQL, които установили
за намаляване на производителността на системата с 23%.
