А причем тут интеловские процессоры? Я специально спросил про остановку пайплана на AMD процессорах. Очень странно вы аргументируете свою позицию. Вы сделали вполне конкретное утверждение о том, что процессоры AMD прерывают работу команд на конвеере, а привести ссылку на документацию не можете. Правда ли есть доступная документация описывающее это или вам просто кажется, что это так?
Я видел это заявление AMD, но это заявление мало что реально объясняет. Было бы неплохо, если бы все начали свои догадки предъявлять как догадки, а не как факты, но да ладно.
Частота обновления конкретной строки кеша (какого бы то ни было, TLB или кеша данных) при «нормальной работе Linux/Android» не показатель. Конкретные результаты будут зависеть от нагрузки конкретных приложений, и все что нужно для эксплуатации уязвимости, так это получить достаточно большой квант времени в течении, которого приложение может практиковать любую порнографию практически монопольно забивая кеши данными, что бы добиться нужного эффекта. Не понимаю, как из ваших измерений может следовать невозможность эксплуатации TLB вместо кеша данных.
В этом случае TLB должен уметь держать отображения для 256 страниц и если положить туда больше, то начать сбрасывать старые записи. Очень странно что это число никак не зависит от модели процессора. Например, у меня d/i TLB может держать только 64 записи, а L2 TLB 1536 записей, как видите ни одно из них не равно 256.
И когда они начнуться, что компании которые поддерживают большую инфраструктуру вдруг перестанут ее поддерживать? Или что отказ от обновлений как-то остановит взломы? Каким образом шумиха вдруг магическим образом сведет на нет потребность в вычислительной мощности?
Вы говорите про вероятность, покажите пожалуйста как вы эту вероятность считали? Если вы ее не считали, то стоит говорить не «вероятность меньше», а «мне кажется, что так проще».
Далее касательно относительного влияния TLB и кеша данных. Если вы не верите мне на слово, что это возможно, то вот вам статься другого человека: futuretech.blinkenlights.nl/misc/cpumemory.pdf. В разделе «3.3.2 Measurements of Cache Effects» измеряются эффекты различных кешей на скорость доступа к памяти (включая кеши данных и TLB). Конкретно к данному вопросу отношение имеет график 3.12.
Это только чать правды, TLB кеш имеет ограниченный размер, так что просто обратившись по достаточно большому количеству других адресов вы его переполните, что даст вам нужный эффект.
Просто так взять и притормозить довольно проблематично. Компании с большой инфраструктурой (и кажется, что именно такие компании и покупают большую часть CPU), должны ее поддерживать, соответственно просто остановиться не могут.
Индивидуальные пользователи могут подождать с покупкой, но в какой-то момент и им придется покупать железо. Они могут попробовать AMD вместо Intel, но часть из описанных уязвимостей применима и к AMD, а про те же что «не применимы» деталей почему не так много (фраза «из-за архитектурных различий» не очень то информативна), может оказаться что еще просто не нашли как.
А часть пользователей просто не будут особо париться обо всяких уязвимостях, так что их они даже не притормозят.
Блок TLB не имеет программного (микропрограммного) управления, как обычный кеш. Из него невозможно удалить запись, либо принудительно внести/модифицировать какую-либо запись.
Очень странное заявление. Зачем вы вообще это добавили в статью, если прямым текстом ниже говорите, что сбросить TLB таки можно. Более того, если бы это было нельзя сделать, то мы бы имели на руках другую серьезную проблему, на этот раз связанную с корректностью исполняемых программ.
Все патчи уязвимостей Spectre и Meltdown предложенные производителями ПО это и делают, перезагружая в обработчике исключения GP регистр CR3.
Не просто перегружают, а записывают туда адреса других таблиц страниц. Более того, когда есть возможность TLB стараются сохранить по крайней мере частично (спасибо PCID). Просто сбросить TLB кеш не достаточно (читай бесполезно).
Первым делом нужно в программе создать буфер размером 2 мегабайта, причем в этот буфер нельзя писать/читать до проведения атаки и он должен располагаться на границе 4К блока. Этот размер принципиален, в буфере должны разместиться ровно 256 страниц по 4К (специфика пейджинговой адресации).
Во-первых, размер 2Mb не принципиален (уж не говоря о том, что 256 * 4Kb = 1Mb). 256 страниц нужно только если вы хотите по одному байту сливать за раз, но это не единственно возможный вариант. Во-вторых, если вы не будете ничего писать или читать из этой памяти, то ОС может вообще не создавать отображения для нее, так что при первой проверке вы рискуете измерить Page Fault и ленивую аллокацию для всех страниц, а не просто TLB miss/hit, что будет менее надежно.
Чтобы объяснить почему TLB может быть более важным фактором чем кеш данных, достаточно было оставить комментарий к оригинальной статье указывающий на то, что запись в кеше данных экономит одно обращение к памяти, а запись в TLB 3-4 (на x86 в планах 5), значит и эффект гораздо заметнее. Ваша аггрессия не соответсвует ни объему информации, которую вы собрали в статью, ни точности.
Я не понял как вышенаписанное оспаривает то что использование анализаторов для поиска ошибок, которые могла бы убрать спецификация языка — костыль.
Все проблемы, которые могут находить статические анализаторы могут находить и компиляторы, но это не значит, что все это нужно пихнуть в компилятор и спецификацию языка:
— это сделает спецификацию языка очень большой и сложной для понимания;
— это сделает компилятор сложным и подверженным ошибкам, а компилятор и стандартная библиотека являются источниками доверия;
— не каждый анализ нужен каждому пользователю компилятора.
Не к фундаментально, а к тому что анализаторы это костыли.
Есть фундаментальное решение проблемы — Model Checking который строго формально доказывает корректность или находит пример ошибки. Но это только если вы его сможете применить конечно...
Так же и с Rust вы можете сколько угодно его прославлять, но если задача требует использования unsafe, то вы вступаете в мир где Rust уже и не так-то безопасен. И тут вам на помощь приходят "костыли" как вы их назвали.
Если вы размажете unsafe по всему коду и будет он размазан. Если unsafe запретить, то некоторые вещи сделать будет нельзя, а если не запрещать, то все к ревью сводится. Короче голова всеравно своя быть должна и в C++ и в Rust, и где угодно.
А ещё выше речь шла о том, что всякие анализаторы это костыли не решающие проблему фундаментально. А теперь оказывается, что фундаментально и не надо? В таком случае анализаторы ещё по живут.
Но unsafe там тем нее менее оставили, и если он там есть, значит им кто-то воспользуется, а если им кто-то воспользуется, то кто-то обязательно ошибется, так что проблема как не была фундаментально решена так и осталась.
Вы сами игнорируете аргументы. Давайте на время забудем про них.
Вы утверждали, что я продвигаю b-tree, как серебрянную пулю и в качестве аргумента привели мое утверждение, где прямым текстом сказано обратное, а теперь предлагаете забыть про аргументы? Вы серьезно?
А никто с этим и не спорит
Вы сделали утверждение, что бинарные деревья поиска в памяти лучше b-tree безотносительно чего бы то ни было (прямо тут) вас поправили, а вы вместо того чтобы на этом успокоиться стали привелкать аргументы вроде, а там вот дяди умные сделали значит так правильно! При этом почему умные дяди приняли то или иное решение вы только гадаете. Вы только и делаете что спорите, причем спорите не аргументированно.
Правильно. Пока у процессора и памяти нет операций по мгновенному сравнению всех N вершин, любое дерево отличное от бинарного потребует столько же либо больше операций сравнения и будет менее эффективным.
И что? Из этого разве следует, что бинарное дерево как минимум не хуже b-tree по производительности? И почему вы опять лихо отбрасываете в сторону такие вещи как кеш и TLB (про которые я уже неоднократно вам упоминал)? Более того, даже большее количество сравнений само по себе не значит меньшую скорость работы.
Это в идеальном сферическом вакууме, а на практике, любое не бинарное дерево потребует количество операций такое же как в эквивалентном бинарном. Ну не умеет пока железо и память работать сразу с узлами B-tree целиком. Что бы не придумали количество операций сравнения всегда будет либо столько же, либо больше чем в эквивалентном бинарном.
Нет, b-tree идеально сбалансированное дерево поска без всяких вакуумов, тем более сферических. И опять же напомню, хотя зря наверно, что речь ведь не только о количестве сравнений, но о производительности на реальном железе (да-да том самом железе, где есть кеш и TLB, если повезет).
Я, просто, не согласен с вами в том что в std::map используется бинарное дерево лишь потому, что стандарт стар.
Вы не согласны со мной? А где я такое утверждал, чтобы вы со мной были не согласны? Более того я вам говорил уже несколько раз про проблему с итераторами (и при этом ни разу ни слова не сказал про чей бы то ни было возраст).
Также, B-tree будет иметь значительный оверхед по памяти, о чем вы тактично умалчиваете.
Ну да? А вы это видели? Опять же b-tree будет иметь оверхед по памяти (о котором я оказывается тактично умалчиваю) безотносительно чего бы то ни было?
Вообще у меня складываеится впечатление, что вы посмотрели, что в std::map используется бинарное дерево поиска, а потом уже на основании того, что std::map же умные дяди сделали, стали подтягивать всякую разную (и не всегда корректную) аргументацию, чтобы оправдать это решение.
Далее касательно относительного влияния TLB и кеша данных. Если вы не верите мне на слово, что это возможно, то вот вам статься другого человека: futuretech.blinkenlights.nl/misc/cpumemory.pdf. В разделе «3.3.2 Measurements of Cache Effects» измеряются эффекты различных кешей на скорость доступа к памяти (включая кеши данных и TLB). Конкретно к данному вопросу отношение имеет график 3.12.
Индивидуальные пользователи могут подождать с покупкой, но в какой-то момент и им придется покупать железо. Они могут попробовать AMD вместо Intel, но часть из описанных уязвимостей применима и к AMD, а про те же что «не применимы» деталей почему не так много (фраза «из-за архитектурных различий» не очень то информативна), может оказаться что еще просто не нашли как.
А часть пользователей просто не будут особо париться обо всяких уязвимостях, так что их они даже не притормозят.
Не просто перегружают, а записывают туда адреса других таблиц страниц. Более того, когда есть возможность TLB стараются сохранить по крайней мере частично (спасибо PCID). Просто сбросить TLB кеш не достаточно (читай бесполезно).
Во-первых, размер 2Mb не принципиален (уж не говоря о том, что 256 * 4Kb = 1Mb). 256 страниц нужно только если вы хотите по одному байту сливать за раз, но это не единственно возможный вариант. Во-вторых, если вы не будете ничего писать или читать из этой памяти, то ОС может вообще не создавать отображения для нее, так что при первой проверке вы рискуете измерить Page Fault и ленивую аллокацию для всех страниц, а не просто TLB miss/hit, что будет менее надежно.
Чтобы объяснить почему TLB может быть более важным фактором чем кеш данных, достаточно было оставить комментарий к оригинальной статье указывающий на то, что запись в кеше данных экономит одно обращение к памяти, а запись в TLB 3-4 (на x86 в планах 5), значит и эффект гораздо заметнее. Ваша аггрессия не соответсвует ни объему информации, которую вы собрали в статью, ни точности.
— это сделает спецификацию языка очень большой и сложной для понимания;
— это сделает компилятор сложным и подверженным ошибкам, а компилятор и стандартная библиотека являются источниками доверия;
— не каждый анализ нужен каждому пользователю компилятора.
Прям таки никакие анализаторы не помогут? Ну прям ни капельки?
Не к фундаментально, а к тому что анализаторы это костыли.
Есть фундаментальное решение проблемы — Model Checking который строго формально доказывает корректность или находит пример ошибки. Но это только если вы его сможете применить конечно...
Так же и с Rust вы можете сколько угодно его прославлять, но если задача требует использования unsafe, то вы вступаете в мир где Rust уже и не так-то безопасен. И тут вам на помощь приходят "костыли" как вы их назвали.
А я разве говорил что нельзя? Я просто указал на то, что это зависит от инженера, а не от компилятора.
Если вы размажете unsafe по всему коду и будет он размазан. Если unsafe запретить, то некоторые вещи сделать будет нельзя, а если не запрещать, то все к ревью сводится. Короче голова всеравно своя быть должна и в C++ и в Rust, и где угодно.
А ещё выше речь шла о том, что всякие анализаторы это костыли не решающие проблему фундаментально. А теперь оказывается, что фундаментально и не надо? В таком случае анализаторы ещё по живут.
Вы сделали утверждение, что бинарные деревья поиска в памяти лучше b-tree безотносительно чего бы то ни было (прямо тут) вас поправили, а вы вместо того чтобы на этом успокоиться стали привелкать аргументы вроде, а там вот дяди умные сделали значит так правильно! При этом почему умные дяди приняли то или иное решение вы только гадаете. Вы только и делаете что спорите, причем спорите не аргументированно.
И что? Из этого разве следует, что бинарное дерево как минимум не хуже b-tree по производительности? И почему вы опять лихо отбрасываете в сторону такие вещи как кеш и TLB (про которые я уже неоднократно вам упоминал)? Более того, даже большее количество сравнений само по себе не значит меньшую скорость работы.
Нет, b-tree идеально сбалансированное дерево поска без всяких вакуумов, тем более сферических. И опять же напомню, хотя зря наверно, что речь ведь не только о количестве сравнений, но о производительности на реальном железе (да-да том самом железе, где есть кеш и TLB, если повезет).
Вы не согласны со мной? А где я такое утверждал, чтобы вы со мной были не согласны? Более того я вам говорил уже несколько раз про проблему с итераторами (и при этом ни разу ни слова не сказал про чей бы то ни было возраст).
Ну да? А вы это видели? Опять же b-tree будет иметь оверхед по памяти (о котором я оказывается тактично умалчиваю) безотносительно чего бы то ни было?
Вообще у меня складываеится впечатление, что вы посмотрели, что в std::map используется бинарное дерево поиска, а потом уже на основании того, что std::map же умные дяди сделали, стали подтягивать всякую разную (и не всегда корректную) аргументацию, чтобы оправдать это решение.