"Подарочек" на новый год. Закрытие уязвимости приведет к падению производительности.

corner	# 4 года, 8 месяцев назад
Темы: 6 Сообщения: 773 Участник с: 21 июля 2011	sirocco На лоре пишут: падение есть, но при записи на ssd где-то с 180 до 130. Думаю, это может касаться весьма специфичных задач На SSD `desktop\|test$ sudo tune2fs -l /dev/sdb2 \| grep "Block size" Block size: 4096 desktop\|test$ dd if=/dev/zero of=testdata bs=4096 count=1000000 1000000+0 records in 1000000+0 records out 4096000000 bytes (4.1 GB, 3.8 GiB) copied, 2.70361 s, 1.5 GB/s`

# 4 года, 8 месяцев назад

Сообщения: 773

Участник с: 21 июля 2011

sirocco
На лоре пишут:
падение есть, но при записи на ssd где-то с 180 до 130.

Думаю, это может касаться весьма специфичных задач
На SSD


desktop|test$ sudo tune2fs -l /dev/sdb2 | grep "Block size"
Block size:               4096
desktop|test$ dd if=/dev/zero of=testdata bs=4096 count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 2.70361 s, 1.5 GB/s

Morisson	# 4 года, 8 месяцев назад
Темы: 18 Сообщения: 1408 Участник с: 11 января 2017

vasek	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Сегодня делать было нечего и то же решил потестить свой ноут, но решил это сделать по другому, делал замеры IPC (insn per cycle - количество инструкций, выполняемых процессором в среднем за каждый свой такт). Вообщем, чем больше это число, тем лучше - больше времени выполняется полезная работа. UPD - а так как kernel space отделят от user space, то при каждом переключении между этими spaces, процессору придется постоянно выгружать/очищать свой кэш (в основном данных и TLB), а значит меньше времени будет выполняться полезная работа, т.е. будет меньше значение IPC. Тестил при двух значениях параметра pti (Control user/kernel address space isolation) - on/off, брал среднее из 3-х значений, но разброс был незначительный. Без нагрузки - IPC = 0,27 - 0,28 (в обоих случаях) 1. Чистый расчет (запустил расчет последовательности простых чисел) Разницы в значениях IPC не заметил 2. Написал легкий скриптик - последовательная загрузка/выгрузка нескольких модулей (cpu не грузит, но частые обращения к kernel space) pti=on - IPC = 0,5 pti=off - IPC = 0,53 UPD - в данном случае разница порядка 6% 3. dd if=/dev/zero of=testfile bs=512 count=8000000 Время здесь замерять нет смысла, общее время около 10с, а разница в обоих случаях в пределах погрешности 1-2с pti=on - IPC = 0,93 pti=off - IPC = 1,16 UPD - в данном случае разница порядка 20% Так оно и оказалось, как пишут, для среднего пользователя особого падения производительности не будет, при расчетах тем более, а в остальном все зависит от запускаемых приложений. Для меня, думаю, это нормально Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Сегодня делать было нечего и то же решил потестить свой ноут, но решил это сделать по другому, делал замеры IPC (insn per cycle - количество инструкций, выполняемых процессором в среднем за каждый свой такт). Вообщем, чем больше это число, тем лучше - больше времени выполняется полезная работа.
UPD - а так как kernel space отделят от user space, то при каждом переключении между этими spaces, процессору придется постоянно выгружать/очищать свой кэш (в основном данных и TLB), а значит меньше времени будет выполняться полезная работа, т.е. будет меньше значение IPC.
Тестил при двух значениях параметра pti (Control user/kernel address space isolation) - on/off, брал среднее из 3-х значений, но разброс был незначительный.
Без нагрузки - IPC = 0,27 - 0,28 (в обоих случаях)

1. Чистый расчет (запустил расчет последовательности простых чисел)
Разницы в значениях IPC не заметил

2. Написал легкий скриптик - последовательная загрузка/выгрузка нескольких модулей (cpu не грузит, но частые обращения к kernel space)
pti=on - IPC = 0,5
pti=off - IPC = 0,53
UPD - в данном случае разница порядка 6%

3. dd if=/dev/zero of=testfile bs=512 count=8000000
Время здесь замерять нет смысла, общее время около 10с, а разница в обоих случаях в пределах погрешности 1-2с
pti=on - IPC = 0,93
pti=off - IPC = 1,16
UPD - в данном случае разница порядка 20%
Так оно и оказалось, как пишут, для среднего пользователя особого падения производительности не будет, при расчетах тем более, а в остальном все зависит от запускаемых приложений. Для меня, думаю, это нормально

Ошибки не исчезают с опытом - они просто умнеют

redix	# 4 года, 8 месяцев назад
Темы: 34 Сообщения: 3433 Участник с: 11 марта 2013	Morisson, сорри за оффтоп, фирменная утилита OCZ - нативная, или запущена через вайн? In Tux We Trust

red	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	Так как есть продукты 3-х известных компаний Intel, AMD и ARM задался вопросом какие конкретно(по мнению компаний) платформы подвержены уязвимости (оставлю на всякий случай это здесь, может кому пригодится) Intel на странице Facts about Side-Channel Analysis and Intel Products на вопрос "Which Intel-based platforms are affected by or vulnerable to the issue?" перечислен список платформ ARM на странице Arm Processor Security Update перечислены уязвимые платформы радует то что Cortex-A53 не попал под раздачу, а это, к примеру, те же Raspberry Pi 3 Model B и Orange Pi PC 2 AMD для AMD конкретной информации не нашел, правда они и "пострадали" меньше всех есть только такая информация An Update on AMD Processor Security

red

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

Так как есть продукты 3-х известных компаний Intel, AMD и ARM задался вопросом какие конкретно(по мнению компаний) платформы подвержены уязвимости
(оставлю на всякий случай это здесь, может кому пригодится)

Intel
на странице Facts about Side-Channel Analysis and Intel Products на вопрос "Which Intel-based platforms are affected by or vulnerable to the issue?" перечислен список платформ

ARM
на странице Arm Processor Security Update перечислены уязвимые платформы
радует то что Cortex-A53 не попал под раздачу, а это, к примеру, те же Raspberry Pi 3 Model B и Orange Pi PC 2

AMD
для AMD конкретной информации не нашел, правда они и "пострадали" меньше всех
есть только такая информация An Update on AMD Processor Security

Haron_Prime	# 4 года, 8 месяцев назад
Темы: 28 Сообщения: 2109 Участник с: 08 июня 2014	кстати, сегодня в инете читал - яблочные наконец признались, что уязвимости затрагивают и их продукцию, что вполне логично https://support.apple.com/en-us/HT208394 Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad GitHub , BitBuket

Aivar	# 4 года, 8 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Сколько не читаю: вынь, линь, мак... Это типа бсдю, солярку и прочее не затронуло, ага... Под раздачу попала любая ось на вышеперечисленных платформах. AMD зацепило рикошетом, но пользователю оной от этого не легче.

Haron_Prime	# 4 года, 8 месяцев назад
Темы: 28 Сообщения: 2109 Участник с: 08 июня 2014	Да это-то понятно. Просто, несмотря на весь поднятый хайп, яблочные тупо отмалчивались, в отличии от мелкомягких и линуксоидов. Типа их это не касается. Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad GitHub , BitBuket

Morisson	# 4 года, 8 месяцев назад
Темы: 18 Сообщения: 1408 Участник с: 11 января 2017	redix, нативная. Есть в ауре + на сайте в архиве простой скрипт для 64 и 32х разрядных систем

corner	# 4 года, 8 месяцев назад
Темы: 6 Сообщения: 773 Участник с: 21 июля 2011	Haron_Prime Да это-то понятно. Просто, несмотря на весь поднятый хайп, яблочные тупо отмалчивались, в отличии от мелкомягких и линуксоидов. Типа их это не касается. Как я вижу, Apple сделала обновление с исправлением уязвимостей еще 8 декабря. Честно говоря, если бы не знал об уменьшении производительности, хотя у меня ничего не изменилось, я бы ничего незаметил. Как не замечаю и сейчас. Надо отдать должное, в логах декабрьских обновлений об этих уязвимостях ни слова не было

corner

# 4 года, 8 месяцев назад

Темы: 6

Сообщения: 773

Участник с: 21 июля 2011

Haron_Prime
Да это-то понятно. Просто, несмотря на весь поднятый хайп, яблочные тупо отмалчивались, в отличии от мелкомягких и линуксоидов. Типа их это не касается.

Как я вижу, Apple сделала обновление с исправлением уязвимостей еще 8 декабря.
Честно говоря, если бы не знал об уменьшении производительности, хотя у меня ничего не изменилось, я бы ничего незаметил.
Как не замечаю и сейчас.
Надо отдать должное, в логах декабрьских обновлений об этих уязвимостях ни слова не было