iDesperado wrote: 05 Jan 2018 15:12 а в IBM Power "branch prediction, and out-of-order execution" точно как у интел реализованно ?
как же в IBM Power баг затесался ?
Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.f_evgeny wrote: 05 Jan 2018 16:08Не совсем так. То, что память ядра маппится в пространство польователя, впоне нормально. Но, это когда MMU работает нормально. А в данной реализации работы MMU + кэш есть рейс кондишен, при котором данные из защищенных областей памяти можно прочитать из кэша. Причем тут не только возможность чтения, это одновременно и неправильные данные пользователя при считывании из памяти.zVlad wrote: 04 Jan 2018 20:28Это не совсем баг, как я понимаю. Это неудачный выбор механизма переключения в кернел для выполнения защисцченной функции. Неудачный в смысле что содержимое кернел становится частью пользовательского пространства. Этот способ был выбран чтобы иметь производительность выше за счет секьюрири. теперь придется жертвовать производительностью. Могли бы пожертвовать и сразу.
Добавил: А если MMU не работает, то это я даже и не знаю с чем сравнить.
там и не будет, будет на IBM Z Security PortalzVlad wrote: 05 Jan 2018 16:33 Затесался ли? И если да то как? Я IBM Power не интересуюсь, если честно. Гадать не буду.
Вот линк к security bulletin's от IBM:
https://www.ibm.com/blogs/psirt/
Пока что на ней нет ничего касаемо System z.
Да неважно, что там в Вмндовс или Линукс. Баг в процессоре, и даже не в микрокоде. Баг в том, как я понимаю, что в кэш грузится память до проверки разрешенности чтения а проверка производится в при чтении, и когда мы пытаемся прочитать адрес, который нам запрещен, то происходит исключение, но считанное в кэш значение можно прочитать.zVlad wrote: 05 Jan 2018 16:41 Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.
Вообще то там не одна, а три разных причины. Мы, похоже, о разных говорим. Та, о которой Вы говорите, это микрокодовая. Я же в данном случае имел в виду другое:f_evgeny wrote: 05 Jan 2018 17:25Да неважно, что там в Вмндовс или Линукс. Баг в процессоре, и даже не в микрокоде. Баг в том, как я понимаю, что в кэш грузится память до проверки разрешенности чтения а проверка производится в при чтении, и когда мы пытаемся прочитать адрес, который нам запрещен, то происходит исключение, но считанное в кэш значение можно прочитать.zVlad wrote: 05 Jan 2018 16:41 Согласен с тем что память ядра мапится в пространство пользователя это нормально. Это есть и в zOS тоже. Но в Windows это как-то связано с вызовом системных функций и есть, кaк я понимаю, разные способы имплементации этих вызовов (по крайней мере описания что я читал ссылаюстаы на вызов системной функции перед тем как все становится плохо). Вызов системных функций на System z осуществляется командой SVC и обеспечивает полную изоляцию пользователя от ядра.
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.
Появится увидим и там и там. Пока не появилось.iDesperado wrote: 05 Jan 2018 17:25там и не будет, будет на IBM Z Security PortalzVlad wrote: 05 Jan 2018 16:33 Затесался ли? И если да то как? Я IBM Power не интересуюсь, если честно. Гадать не буду.
Вот линк к security bulletin's от IBM:
https://www.ibm.com/blogs/psirt/
Пока что на ней нет ничего касаемо System z.
https://www.ibm.com/it-infrastructure/z ... -integrity
Да про одно и то же говорим.zVlad wrote: 05 Jan 2018 17:38
Вообще то там не одна, а три разных причины. Мы, похоже, о разных говорим. Та, о которой Вы говорите, это микрокодовая. Я же в данном случае имел в виду другое:
P.S. Pardon, от облаков на базе Intel....This could become a significant issue for any business running websites and other software through cloud systems....
Так это 99.9% до текущего момента. На оптеронах, ARM и спарках ничтожно мало.
Значит надо переводить облака на System z - самую надежную и непробиваемую платформу.
Давно пора.zVlad wrote: 05 Jan 2018 20:29 Значит надо переводить облака на System z - самую надежную и непробиваемую платформу.
в облаках патч уже стоит, а system z дырявое решето. причем смотрите, suse и редхат патч для z/linux уже выпустили, но IBM тормозит их распространение. красивая иллюстрация на сколько безопасность system z ниже любой другой платформы.zVlad wrote: 05 Jan 2018 20:29 Значит надо переводить облака на System z - самую надежную и непробиваемую платформу.
https://meltdownattack.com/meltdown.pdfPalych wrote: 05 Jan 2018 19:54 Я может чего-то не догоняю, но сколько полезной информации можно вынуть из случайного куска чужой памяти?
Или это не случайный кусок?
Meltdownallows an adversary who can run code on the vulnerable
processor to obtain a dump of the entire kernel
address space, including any mapped physical memory
Насколько я ничего понимаю, кусок не случайный. По крайней мере по тем примерам, которые есть, просто читается ячейка памяти по заданному адресу. Не искал, но думаю, с таким инструментом можно многое узнать. Не очень быстро работает, правда, но для многих вещей, думаю достаточно.Palych wrote: 05 Jan 2018 19:54 Я может чего-то не догоняю, но сколько полезной информации можно вынуть из случайного куска чужой памяти?
Или это не случайный кусок?
И вроде в маках есть ASLR (memory scrambling) - он поможет в таких ситуациях?
