pure functional

[stas]

Кстати, а что думают функциональщики про spectre и meltdown? По-моему, это самое суровое и жизненное обьяснение отличия pure functional от кода с side effects, которое я встречал до сих пор. Правда, непонятно, какая в этом практическая польза.

Comments

[gb0]

А где можно посмотреть на массовую машинерию для исполнения pure functional code, чтобы она не была оберткой вокруг фон-неймановской ЭВМ с регистрами, кэшами, общим ОЗУ для кода и данных, и тд?

[stas]

Отож :)

[irene221b]

Так это же будет гол в свои ворота! Можно написать самую pure functional лямбду, а компилятор все равно внутрь вставит ту же самую неонку, с оптимизациями и спекуляциями.
Или я не уловила тонкий сарказм?

[gb0]

Мож кто расскажет, например, что для начала нужно отказаться от массового тииражирования фон-неймановских ЭВМ. Код отдельно, данные отдельно, и это решит 99% всех проблем с локальной безопасностью. Вобщем, даешь переход на ADSP-21992, а хаскель мы туда потом подтянем.

[stas]

Компилятор тоже не боги пишут. Раз уж реорганизовывать рабкрин, так последовательно.

[stas]

Сбросим фон-Неймана с корабля современности? Не, ну а чо, я не против, хватит жить законом, данным Адамом и Евою, пусть будет движуха. Я б удовольствием посмотрел. Только потянут ли?

[beldmit]

Мне кажется, это скорее про протечку абстракций.

[juan_gandhi]

ФП имеет смысл на определенных уровнях. Функциональных машин нет; приходится моделировать на имеющемся железе. И на определенном уровне архитектуры (типа "вот вам микросервисы") ФП тоже не вписывается (ну или пока что).

[vlad_m]

Meltdown/spectre не зависят от языка/компилятора/ОС.
Они используют утечку, происходящую в процессоре на микропрограммном уровне.

[gb0]

От ОС немного зависит – какой-нить DOS или Cisco IOS Classic и ломать не надо (всем все можно, изоляции ноль), а в ОС с ломаемой изоляцией – изоляцию между процессами и ядром можно усилить (патчи уже вышли).

Без разницы

[malobukov]

Программа, написанная на любом языке программирования (функциональном или императивным), в итоге компилируется или интерпретируется в инструкции, которые выполняются тем же самым процессором. Поскольку уязвимость в процессоре, то и эксплуатировать её можно из любого языка.

По крайней мере теоретически. Возможно, что на практике это не одинаково легко (может таймеров нужного разрешения нет или ещё какие ограничения).

[stas]

Я в курсе.

[stas]

Ну в каком-то смысле да, но одно из преимуществ PF, как оно продаётся, именно в том, что такого не должно происходить. Конечно, там обычно разговор о параллелизме и на другом уровне, но принцип тот же. Одно дело что-то типа rowhammer, где против лома нет приёма - а тут дело другое, тут проблема не в протечке на другой уровень, а в неправильном учёте side effects. Вот и интересно, могут ли люди, которые говорят, что они знают, как с этим бороться, что-нибудь интересное предложить.

[stas]

А почему нет? Т.е. я не спрашиваю на уровне "в каждом айфоне", но насчёт каких-то экспериментальных образцов? Раньше вон пролог-машины строили, лисп-машины... Конечно, нифига не вышло, но пытались же.

[beldmit]

Против Rowhammer мне попадалось уже N+1 приёмов, и каждый раз находят что-то новое. Но вообще утечка абстракций тут на уровне самого процессорного кеша как явления.

[juan_gandhi]

Да было бы любопытно, конечно.

[http://users.livejournal.com/sorcerer-/]

Думаем, что они никакого отношения к не имеет. По крайней мере в варианте недо-языков типа хаскеля.
А данные уязвимости отличная иллюстрация как раз того куда приводит борьба за перформанс сингл треда в 2018 году. Когда уже даже последнему дебилу должно быть понятно, что x86 - это дорога в никуда.

[stas]

Ну, допустим. И вопрос - где дорога в куда?

[stas]

Процессорный кеш как явление вполне часть этой абстракции, если говорить об уровне микрокода, управляющего работой CPU. Это всё равно как, скажем, какая-нибудь аппликация хранила бы пароли в файле /tmp/very-secret в открытом тексте с разрешением на чтение всем. Это вполне в порядке того, что должно было быть учтено в самом дизайне.

[http://users.livejournal.com/sorcerer-/]

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

[stas]

Ну так я понимаю, что для GPU даже единого стандарта нет, не говоря уж о более высокой поддержке. А с security при этом там дела не лучше, думается. Ну и то - как, интересно, обеспечивать это с массовой мультитредностью и ручным управлением кешами, если то же самое не умеют делать с немассовой?

[jsn]

Ну не, GPU -- это скучная дорога куда. Весёлая дорога куда -- это Mills, но, к сожалению, нет никаких оснований считать, что его в обозримом времени таки построят.

[jsn]

Мне всё-таки непонятно, что имеется в виду в этом посте. На таком уровне, на котором контроль сайд-эффектов в случае meltdown/spectre поможет, он никакой функциональности не требует -- достаточно в обычном компиляторе (например, Си) убивать кодогенератором speculative (фенсы ставить, branch predictor обманывать, и т.д.). Понятно так же, почему это отвратительное решение.

[cjelli]

В этом смысле гипервизор (например, VMware) оказывается очень полезным.

[http://users.livejournal.com/sorcerer-/]

Да все умеют, просто тормоза. Любое секьюрити для цпу - это тормоза в сингл треде. Ибо задача: скрыть лейтенси памяти, которая (относительно лейтенси АЛУ) выросла в 200(!) раз, за последние 30 лет.
Ессно в современном ЦПУ столько костылей из-за этого, что чисто физически его хрен засекьюришь.