Telegram Group & Telegram Channel
Всё было сложно сесть и написать

Сейчас в солнечной калифорнии на саммите перформанса в гугле и было сложно сесть и написать что-то.

Unrelated to everything, хочется поговорить о уязвимостях как Inception и Zenbleed. Уязвимости интересные просто для чтения, но TL;DR мы сейчас можем читать где-то по 40-50 байт других процессов в секунду и хоть это не близко до того, чтобы эксплуатировать такие вещи на больших пространствах, забавно, что мы начинаем понимать как ломать branch predictors таким образом, чтобы красть какие-то данные.

Всё это имеет плохие последствия, если кто-то научится это эксплуатировать, также кажется, что ещё немного рисёрча и возможно уже не получится решить эту проблему всякими chicken bits в процессоре, а придётся делать настоящий pipeline flush в branch predictors. Всё это очень серьёзно скажется на перфе процессоров. Скорее всего 20-30% в среднем.

Моё мнение после общения с людьми из индустрии, что мы слишком далеко ушли в сложности в branch predictors и порой это сказывается на сложности дизайна. Самая большая проблема в этом, как ни странно, -- люди. Люди пишут код для него, плохо проверяют на безопасность, потому что рисёрч только сейчас начинает понимать, что мы написали.

Очень смешное решение предложил мой коллега -- запретить людям писать branch predictors на следующие несколько лет. С чем в целом, я согласен. Потому что формальные методы ещё не сильно выросли в этой науке, а кажется люди уже не справляются понять всеобщую картину.

Как с помощью software улучшить ситуацию? Собирать с profile guided optimizations, они хорошо унесут холодные блоки в даль от видимости. Проблема в том, что profile guided optimization (PGO) для людей как-то не сильно будет популярно, максимум так могут сделать компании. Тем не менее, такой подход простит несовершенство branch predictor, который, например, для Arm процессоров похуже, но становится неплохим, когда бинарный файл скомпилирован с PGO.

Надо как-то убирать людей из дизайна безопасносности в таких системах, люди должны только описывать, что значит безопасность и дальше использовать методы верификации. Я лично вижу в этом повторение истории с Pentium FDIV. Возможно в параллельной вселенной я бы этим позанимался.



group-telegram.com/experimentalchill/252
Create:
Last Update:

Всё было сложно сесть и написать

Сейчас в солнечной калифорнии на саммите перформанса в гугле и было сложно сесть и написать что-то.

Unrelated to everything, хочется поговорить о уязвимостях как Inception и Zenbleed. Уязвимости интересные просто для чтения, но TL;DR мы сейчас можем читать где-то по 40-50 байт других процессов в секунду и хоть это не близко до того, чтобы эксплуатировать такие вещи на больших пространствах, забавно, что мы начинаем понимать как ломать branch predictors таким образом, чтобы красть какие-то данные.

Всё это имеет плохие последствия, если кто-то научится это эксплуатировать, также кажется, что ещё немного рисёрча и возможно уже не получится решить эту проблему всякими chicken bits в процессоре, а придётся делать настоящий pipeline flush в branch predictors. Всё это очень серьёзно скажется на перфе процессоров. Скорее всего 20-30% в среднем.

Моё мнение после общения с людьми из индустрии, что мы слишком далеко ушли в сложности в branch predictors и порой это сказывается на сложности дизайна. Самая большая проблема в этом, как ни странно, -- люди. Люди пишут код для него, плохо проверяют на безопасность, потому что рисёрч только сейчас начинает понимать, что мы написали.

Очень смешное решение предложил мой коллега -- запретить людям писать branch predictors на следующие несколько лет. С чем в целом, я согласен. Потому что формальные методы ещё не сильно выросли в этой науке, а кажется люди уже не справляются понять всеобщую картину.

Как с помощью software улучшить ситуацию? Собирать с profile guided optimizations, они хорошо унесут холодные блоки в даль от видимости. Проблема в том, что profile guided optimization (PGO) для людей как-то не сильно будет популярно, максимум так могут сделать компании. Тем не менее, такой подход простит несовершенство branch predictor, который, например, для Arm процессоров похуже, но становится неплохим, когда бинарный файл скомпилирован с PGO.

Надо как-то убирать людей из дизайна безопасносности в таких системах, люди должны только описывать, что значит безопасность и дальше использовать методы верификации. Я лично вижу в этом повторение истории с Pentium FDIV. Возможно в параллельной вселенной я бы этим позанимался.

BY Experimental chill


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/experimentalchill/252

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

In addition, Telegram's architecture limits the ability to slow the spread of false information: the lack of a central public feed, and the fact that comments are easily disabled in channels, reduce the space for public pushback. Asked about its stance on disinformation, Telegram spokesperson Remi Vaughn told AFP: "As noted by our CEO, the sheer volume of information being shared on channels makes it extremely difficult to verify, so it's important that users double-check what they read." But Kliuchnikov, the Ukranian now in France, said he will use Signal or WhatsApp for sensitive conversations, but questions around privacy on Telegram do not give him pause when it comes to sharing information about the war. He floated the idea of restricting the use of Telegram in Ukraine and Russia, a suggestion that was met with fierce opposition from users. Shortly after, Durov backed off the idea. Now safely in France with his spouse and three of his children, Kliuchnikov scrolls through Telegram to learn about the devastation happening in his home country.
from fr


Telegram Experimental chill
FROM American