Акела промахнулся! В смысле, Интел обосрался

[zVlad]

Ха-ха - это обьективно?

А что мне плакать что ли?

[Flash-04]

Зачем же?

[Flash-04]

Никто не застрахован от багов.

Меня больше напрягает, что в каждом интеловском чипсете есть отдельный комп (процессор, память, сетевая карта и даже своя OS) который невидим снаружи и имеет выход в сеть.
Я про intel management engine.

Ну дык и там баги недавно находили.

[Pantigalt]

И что, найден от компании Apple, в котором написано "if(ГодВыпускаТелефона < 2017) ОтключитьВнутреннийКэш()"?

Apple призналось что отключило распараллеливание потоков для некоторых процессов. То есть убрали оптимизацию.

[zVlad]

Никто не застрахован от багов.

....

Это не совсем баг, как я понимаю. Это неудачный выбор механизма переключения в кернел для выполнения защисцченной функции. Неудачный в смысле что содержимое кернел становится частью пользовательского пространства. Этот способ был выбран чтобы иметь производительность выше за счет секьюрири. теперь придется жертвовать производительностью. Могли бы пожертвовать и сразу.

[helg]

Меня больше напрягает, что в каждом интеловском чипсете есть отдельный комп (процессор, память, сетевая карта и даже своя OS) который невидим снаружи и имеет выход в сеть.
Я про intel management engine.

Тот самый Дмитрий Скляров нашёл как этот ME отключать. Но официально его арестовали совсем не за это.

[Serguei666]

Так это фича, называется "economy mode", в iOS она есть и я ей активно пользуюсь
А дохлую батарею лучше поменять

Почему тогда Apple извинилась

"Извинилась" - это "We apologize" в этой статье https://www.apple.com/iphone-battery-and-performance/ ?

и чтобы загладить предложила $50 скидки на замену батареи?

Что "загладить"? Рациональный Power management? Это не нужно заглаживать, за это нужно говорить спасибо.
А скидки предложили чтобы ничего не смыслящие в технике люди перестали создавать отрицательный паблисити

Кстати, режим экономии это не торможение, а отключение ненужных приложений/сервисов.
И есть разница, когда сам включаешь режим экономии и когда тел никого не спрашивая и не предупреждая начинает тормозить.

Там написано "чтобы избежать спонтанного выключения". Так что лучше пусть медленно работает, чем не работает вообще

[Serguei666]

Никто не застрахован от багов.

Меня больше напрягает, что в каждом интеловском чипсете есть отдельный комп (процессор, память, сетевая карта и даже своя OS) который невидим снаружи и имеет выход в сеть.
Я про intel management engine.

Если напрягает, то зачем покупать Intel?

[iDesperado]

хи-хи, редхат говорит с meltdown не только интел лажанул: Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).
https://access.redhat.com/security/vuln ... eexecution

[Dmitry67]

Ха-ха-ха. Сочуствую, коллеги.

А вот теперь повторно заслушаем Влада

[Flash-04]

Ая-яй!

[zVlad]

Ха-ха-ха. Сочуствую, коллеги.

А вот теперь повторно заслушаем Влада

В самой ссылке от RedHat нет никаких деталей про IBM-ские CPU, вот что на IBM сайте про IBm POWER Family есть:

https://www.ibm.com/blogs/psirt/potenti ... er-family/

Ищу дальше про IBM System Z. Если кто найдет раньше, плиз, дайте знать.

[tessob]

Ну вот, опять призвали древнее зло... )))

[iDesperado]

This is done with help of Linux Kernel fixes on the Intel/AMD x86_64 and
IBM zSeries architectures. On x86_64, this requires also updates of the
CPU microcode packages, delivered in seperate updates.

For IBM Power and zSeries the required firmware updates are supplied
over regular channels by IBM.

https://www.suse.com/de-de/support/upda ... 0180011-1/

[zVlad]

Я просмотрел разделы "Machine Alerts", "Hiper Alerts", и "Red Alerts" на IBM Resource Link и ничего похожего на обсуждаемые проблемы не нашел.

я допускаю что в zLinux-ax (RedHat, SuSe) есть проблемы выявленные в этот раз и эти проблему cross-platform, но чтобы проблемы CPU от Intel, AMD, ARM и т.п. могли бы иметь аналоги в zCPU это мне представляется невероятным. Несмотря на наличие в zCPU таких механизмов как branch prediction, and out-of-order execution. Они есть, но они реализованны иначе, по своему.
Кроме того в OS System z (zOS, zVM) ничего подобного как доступ к данным ядра из пользовательского пространства быть не может точно. Последняя подобного рода проблема была в VM/370 и заключалась в том что неочищенные frame (страницы реальной памяти) назначенные страницам памяти виртуальной машины могли содержать данные от других использований этих frame, но это было в 80-e.

Но поживем, как говорится, увидим. До нашей конторы точно должна быть доведена инфа если что такое на самом деле обнаружено будет. Мы ж кастомеры IBM по System z. пока ничего мне не известно и, как говорилось выше, IBM Resource Link с алертами я просмотрел - так нет ничего.

Если что станет мне известно я сразу же сообщу здесь.

[iDesperado]

а в IBM Power "branch prediction, and out-of-order execution" точно как у интел реализованно ?
как же в IBM Power баг затесался ?

[helg]

https://habrahabr.ru/post/346026/

Да уж. Покупаю виртуалку у провайдера, с неё снимаю пароли соседних виртуалок, с паролями захожу на них - и добавляю JS с экслоитом на их вебы. После этого беру всё что хочу с машин клиентов, которые зашли на эти вебы.

Интересно, что если в виртуалку нет захода по паролю, а есть только по ключу, то означенный метод не работает. Потому что ни в какой момент нигде в памяти сервера не образуется никакого объекта, который, будучи украденным, может использоваться для захода на сервер.

Пожалуй, пора уже разрешить на виртуалки вход только по ключу.

[f_evgeny]

Никто не застрахован от багов.

....

Это не совсем баг, как я понимаю. Это неудачный выбор механизма переключения в кернел для выполнения защисцченной функции. Неудачный в смысле что содержимое кернел становится частью пользовательского пространства. Этот способ был выбран чтобы иметь производительность выше за счет секьюрири. теперь придется жертвовать производительностью. Могли бы пожертвовать и сразу.

Не совсем так. То, что память ядра маппится в пространство польователя, впоне нормально. Но, это когда MMU работает нормально. А в данной реализации работы MMU + кэш есть рейс кондишен, при котором данные из защищенных областей памяти можно прочитать из кэша. Причем тут не только возможность чтения, это одновременно и неправильные данные пользователя при считывании из памяти.
Добавил: А если MMU не работает, то это я даже и не знаю с чем сравнить.

[zVlad]

а в IBM Power "branch prediction, and out-of-order execution" точно как у интел реализованно ?
как же в IBM Power баг затесался ?

Затесался ли? И если да то как? Я IBM Power не интересуюсь, если честно. Гадать не буду.

Вот линк к security bulletin's от IBM:

https://www.ibm.com/blogs/psirt/

Пока что на ней нет ничего касаемо System z.

[zVlad]

Никто не застрахован от багов.

....

Это не совсем баг, как я понимаю. Это неудачный выбор механизма переключения в кернел для выполнения защисцченной функции. Неудачный в смысле что содержимое кернел становится частью пользовательского пространства. Этот способ был выбран чтобы иметь производительность выше за счет секьюрири. теперь придется жертвовать производительностью. Могли бы пожертвовать и сразу.

Не совсем так. То, что память ядра маппится в пространство польователя, впоне нормально. Но, это когда MMU работает нормально. А в данной реализации работы MMU + кэш есть рейс кондишен, при котором данные из защищенных областей памяти можно прочитать из кэша. Причем тут не только возможность чтения, это одновременно и неправильные данные пользователя при считывании из памяти.
Добавил: А если MMU не работает, то это я даже и не знаю с чем сравнить.

Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.

[iDesperado]

Затесался ли? И если да то как? Я IBM Power не интересуюсь, если честно. Гадать не буду.

Вот линк к security bulletin's от IBM:

https://www.ibm.com/blogs/psirt/

Пока что на ней нет ничего касаемо System z.

там и не будет, будет на IBM Z Security Portal
https://www.ibm.com/it-infrastructure/z ... -integrity

[f_evgeny]

Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.

Да неважно, что там в Вмндовс или Линукс. Баг в процессоре, и даже не в микрокоде. Баг в том, как я понимаю, что в кэш грузится память до проверки разрешенности чтения а проверка производится в при чтении, и когда мы пытаемся прочитать адрес, который нам запрещен, то происходит исключение, но считанное в кэш значение можно прочитать.

[zVlad]

Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.

Да неважно, что там в Вмндовс или Линукс. Баг в процессоре, и даже не в микрокоде. Баг в том, как я понимаю, что в кэш грузится память до проверки разрешенности чтения а проверка производится в при чтении, и когда мы пытаемся прочитать адрес, который нам запрещен, то происходит исключение, но считанное в кэш значение можно прочитать.

Вообще то там не одна, а три разных причины. Мы, похоже, о разных говорим. Та, о которой Вы говорите, это микрокодовая. Я же в данном случае имел в виду другое:

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.