Я пробовал смотреть 3D фильмы в VR и меня сразу же укачало от трясущейся камеры, так что вариант только для телеков.
В VR же можно вывести 3д-картинку на виртуальный же экран на удобном расстоянии. Получается ровно как если бы телевизор был на стене, только без телевизора и стены.
Я пробовал так смотреть в самолёте — всё довольно неплохо, если не считать, что Quest 3 с SSD тратит больше энергии, чем забирает из зарядки, а этот самый SSD обжигает ногу на которой лежит.
Проникновение Spectre в оперативную память через обучение предсказателя ветвлений (картинка)
Из диаграммы складывается такое впечатление, что в программу внедряется какой-то исполняемый код с шпионом, который и выполняется в пространстве этого процесса. Но Spectre всё-таки действует только в рамках своего процесса и никак не влияет на другие.
В целом, диаграмма ну очень непонятная. По идее, «Задача X» это и есть ваш процесс в котором вы манипулируете предсказателем ветвлений, но кто такой тогда красный Spectre справа?
Пробравшись, например, в серверы банков, Spectre может достать из оперативной памяти
Если вы банк и на ваших серверах исполняется произвольный бинарник, то кажется что-то пошло очень сильно не так и исправляется это совсем не борьбой со спекулятивными вычислениями.
Если же этот бинарник вы сами туда положили, то скорее стоит переработать методы защиты от Supply Chain-атак. Пожалуй, Spectre тут это не самая большая из ваших проблем.
Если же у вас всё хорошо с защитой цепочки поставок, но Spectre всё равно оказался в ваших бинарниках, то это может означать лишь то, что вы сами его реализовали и сами его собрали. Тогда действительно компиляция в режиме защищенных вычислений вам поможет, да.
Короче, в случае dedicated серверов за физически охраняемой решеткой и тотальным код-ревью, Spectre практически никак не играет роли. Этот класс узязвимостей опасен в основном на shared-платформах, где выполняется множество разных процессов, и не всем из них можно доверять. Например, компьютер пользователя.
У процессоров Эльбрус уязвимости Spectre нет на аппаратном уровне, но она проявляется на уровне компилятора
Но ведь буквально в начале описывается, что это аппартаная уязвимость, да и на протяжении всего текста аналогично: «это глубинная аппаратная уязвимость». Что значит «проявляется на уровне компилятора»?
Без оптимизации компилятора уязвимость не проявляется, потому что компилятор не будет генерировать спекулятивное чтение из памяти.
Я бы скорее ожидал ровно противоположного — с включенными оптимизациями компилятор не станет генерировать код, который заведомо не исполняется. А без оптимизаций он сгенерирует ровно то что и было написано — включая любые чтения из памяти.
Проверяли ли вы, что без оптимизаций уязвимость проверяется на заведомо уязвимых процессорах? Подозреваю, что здесь неправильно поставлен эксперимент и с выключенными оптимизациями уязвимость вообще никогда не воспроизводится вашим кодом (например, из-за проблем с достоверным замером времени исполнения инструкций).
Наиболее важные особенности этого режима в том, что он контролирует обращения за границами объектов, использование неинициализированных переменных и создание новых указателей и конверсию указателей.
Это реализовано на уровне компилятора или на аппаратном уровне? Если первое, то можно ли переписать весь ваш эксплоит на ассемблер и обойти все проверки? Всё-таки вряд ли вы будете контроллировать компиляцию зловредного кода =)
Если второе, то почему вы переключаете флаги компилятора? Кажется для демонстрации влияния защиты нужно переключать только защиту, и ничего больше. Иначе эксперимент какой-то некорректный выходит.
И программные заплатки, увы, не панацея, потому что не только не дают полной защиты, но и снижают производительность системы.
Я всё-таки буду предполагать что ваш режим защищенных вычислений всё-таки работает на уровне компилятора. Тогда чем же он не «программная заплатка»?
Наиболее важные особенности этого режима в том, что он контролирует обращения за границами объектов, использование неинициализированных переменных и создание новых указателей и конверсию указателей.
…и разве всё это не снижает производительность системы?
можно закрыть только переходом на другую архитектуру процессоров и отказом от спекулятивных вычислений
Но как же тогда в процессорах Apple Silicon (который M1, M2, M3) всё-таки Spectre пропатчили? Там же старый-добрый ARM в качестве архитектуры и спекулятивные вычисления всё также присутствуют. Аналогично с новыми поколениями Intel, AMD.
Intel, AMD, ARM, Microsoft, Linux и даже Mac выпустили патчи, которые отчасти закрывают уязвимость Spectre.
Нетехнический наброс, но корректнее было бы вместо Mac написать Apple, всё-таки Mac это лишь линейка продуктов, как, скажем «Intel Core».
Сначала удивился, что в джаве есть целый кеш для простых чисел. Потом перешёл по ссылке и увидел, что это всего лишь кеш объектов Integer (которые boxed).
Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
Использую API, для моих целей (пару раз в неделю реализовать какой-то код по чёткому ТЗ) более чем хватает и выходит на порядок дешевле, чем платить 20$/mo (я трачу около 2$/mo). Почти никаких лимитов, а если подобрать хороший UI, то ещё и очень удобно (например, можно редактировать текст предыдущих вопросов/ответов). Лично я использую openrouter.ai.
Если у вас вдруг есть юзернеймы, то почти всегда почти точно будет какой-то функционал, который потребует по этим самым юзернеймам находить саму сущность пользователя в базе.
Если вас не атакуют, то почти всегда почти точно количество регистраций будет пренебрежимо мало по сравнению с числом легальных действий. Банально потому что пользователь регистрируется лишь однажды, а пользуется приложением часто.
Отсюда простой вывод — у вас уже должен быть general-purpose механизм поиска юзернейма в базе. Чертовски хорошо отлаженный, потому что от него зависит работа примерно всего. Который умеет как-то адекватно жить с ограничениями на количество подключений и решает множество других проблем. Возможно даже с кешированием.
Опять-таки, если вас не атакуют, то почти всегда почти точно юзернеймы будут только валидными. А поскольку регистрации составляют ничтожный объём от всей нагрузки — поддерживать только для них фильтр Блума будет накладно. Вы же помните, что всякий дополнительный индекс — ускоряет некоторые операции чтения, но замедляет все операции записи? Не считая того, что в данном случае он банально тратит ресурсы, увеличивает latency и раздувает общую сложность системы.
К слову о кешировании — почти точно ваш Redis не будет источником правды, а будет лишь кэшировать данные из чего-то более классического (и с более приятными гарантиями). И тут в полной мере встаёт вопрос «а как?». Если мы хотим не просто хранить список имён, то задача поддержания кэша в актуальном состоянии — чертовски нетривиальная с множеством разных компромиссов и тонкостей. Кажется немного опрометчивым советовать в статье для самых новичков добавить в систему кэширующий слой (особенно когда не все соки выжаты из БД).
Нет, это всё-таки проблема гугла. Их задача — принести конверсию рекламодателю, чтобы тот, в свою очередь, принес гуглу деньги. Сама по себе реклама ценности не несёт.
Но я почти уверен, что если бы на денежных метриках не сказывались меры по борьбе с адблоком, гугл бы не продолжал тратить на это свои ресурсы и репутацию.
В идеальном мире, гугл бы с радостью перестал показывать рекламу тем, кто ничего не покупает, если бы это не сказалось на конверсии в других группах (и справедливо стал бы брать больше денег за оставшиеся показы). Как, например, перестал показывать рекламу в России за неимением в этом регионе релевантных рекламных роликов, которые бы могли принести конверсию.
Кажется, сейчас этот сценарий с лихвой решается открытием счета без карты. Переводы можно делать любые, обслуживание нулевое, разве что только переводы через СБП получать на счёт нельзя.
В данном случае мы перебираем «высоту» и имеем две попытки. Статья по ссылке содержит вывод ответа для этого простого случая (такой же как и по ссылке в Академии, но в другой форме).
А вот описать решение для серверов уже найти веселее, особенно за бросков =)
UnRAR source code may be used in any software to handle RAR archives without limitations free of charge, but cannot be used to develop RAR (WinRAR) compatible archiver and to re-create RAR compression algorithm, which is proprietary.
Лицензия запрещает использовать код unrar для создания rar, а людям хочется уметь создавать архивы тоже.
Яндекс видимо решил стабильно держаться в топе Хабра: сначала инцидент с NTP, теперь вот это. Интересно почитать как так вышло, что задело все зоны доступности
метрики должны быть на все генерирующие трафик (читай все io операции) компоненты.
К слову, в статье есть график с подписью «динамика числа отправляемых колонками NTP-запросов». Вопрос тут в том, почему на него никто не обратил внимание, но в статье пишут что банально уведомления не были настроены.
Не самый высокий приоритет был когда редкие технические продвинутые пользователи попадали на первую линию поддержки и писали «а у меня что-то станция часто запросы делает, это ок?».
Из текста, когда багу всё-таки обнаружили, её почти сразу пофиксили (пока ещё не осознавая масштабы проблемы) и медленно выкатывали (релизный цикл видимо порядка недели), а когда на хабре написали про большой факап всея рунета и популярно объяснили масштаб беды, предприняли альтернативные, но более рискованные меры.
ИМХО, это вполне себе высокий приоритет — в воскресенье применять правку конфига катить на 100% устройств — учитывая что дождаться обычной выктаки фикса оставалось всего около трёх дней.
Я бы лично настаивал на том чтобы докатить по стандартному флоу и без доп.рисков, нежели тратить свой выходной на то чтобы найти и придумать альтернативу, собрать фикс, выкатить, а утром понедельника рисковать увидеть новости в духе «Алисы по всей России перестали показывать время, миллионы будильников не сработали». Чай ещё три дня ддоса погоды рунету не сделают.
Да. Привычный hashmap внезапно превращается из замечательной коллекции с O(1) доступом в O(N). Это запросто приводит к O(N^2) от входных данных (контроллируемых злоумышленником) и резко усиливает эффективность атаки. Например, представьте что вам приходит массив некоторых сущностей и вы всегда проверяете, что у них всех различный ID.
Более того, в случае хэшмапы нельзя использовать криптографические функции, иначе ваш сервис ляжет и без зловредной нагрузки =)
PhantomData не позволяет как-то сделать множество мутабельных ссылок. В main() важна только сигнатура new(), которая гласит «захватывает мутабельную ссылку и возвращает объект с временем жизни не больше чем эта ссылка». Ну и ссылка будет захвачена до тех пор, пока живёт этот объект. Сам объект или функция new() тут уже никак не анализируется.
Учитывая количество уязвимых устройств — достаточно на них массово зарегистрировать принтер «Save To PDF» и ждать случайных срабатываний. Кто-нибудь, да выберет не тот пункт в менюшке.
Суть атаки в том, что добавление принтера в систему происходит без участия пользователя. Социальная инженерия нужна только чтобы запустить задание печати на этом принтере — только тогда выполняется произвольный код.
Не без этого, но всё-таки он скорее хотел привлечь внимание к уязвимости, потому что трёхнедельная переписка с разработчикам никаких плодов не дала.
не очень понимает, как оценивать CVSS score
Поэтому и ссылается на инженеров из RedHat, именно которые и нарисовали цифру 9.9. Откуда они это взяли — тот ещё вопрос, но видимо по каким-то формальным критериям сильно выстрелило.
В VR же можно вывести 3д-картинку на виртуальный же экран на удобном расстоянии. Получается ровно как если бы телевизор был на стене, только без телевизора и стены.
Я пробовал так смотреть в самолёте — всё довольно неплохо, если не считать, что Quest 3 с SSD тратит больше энергии, чем забирает из зарядки, а этот самый SSD обжигает ногу на которой лежит.
Из диаграммы складывается такое впечатление, что в программу внедряется какой-то исполняемый код с шпионом, который и выполняется в пространстве этого процесса. Но Spectre всё-таки действует только в рамках своего процесса и никак не влияет на другие.
В целом, диаграмма ну очень непонятная. По идее, «Задача X» это и есть ваш процесс в котором вы манипулируете предсказателем ветвлений, но кто такой тогда красный Spectre справа?
Если вы банк и на ваших серверах исполняется произвольный бинарник, то кажется что-то пошло очень сильно не так и исправляется это совсем не борьбой со спекулятивными вычислениями.
Если же этот бинарник вы сами туда положили, то скорее стоит переработать методы защиты от Supply Chain-атак. Пожалуй, Spectre тут это не самая большая из ваших проблем.
Если же у вас всё хорошо с защитой цепочки поставок, но Spectre всё равно оказался в ваших бинарниках, то это может означать лишь то, что вы сами его реализовали и сами его собрали. Тогда действительно компиляция в режиме защищенных вычислений вам поможет, да.
Короче, в случае dedicated серверов за физически охраняемой решеткой и тотальным код-ревью, Spectre практически никак не играет роли. Этот класс узязвимостей опасен в основном на shared-платформах, где выполняется множество разных процессов, и не всем из них можно доверять. Например, компьютер пользователя.
Но ведь буквально в начале описывается, что это аппартаная уязвимость, да и на протяжении всего текста аналогично: «это глубинная аппаратная уязвимость». Что значит «проявляется на уровне компилятора»?
Я бы скорее ожидал ровно противоположного — с включенными оптимизациями компилятор не станет генерировать код, который заведомо не исполняется. А без оптимизаций он сгенерирует ровно то что и было написано — включая любые чтения из памяти.
Проверяли ли вы, что без оптимизаций уязвимость проверяется на заведомо уязвимых процессорах? Подозреваю, что здесь неправильно поставлен эксперимент и с выключенными оптимизациями уязвимость вообще никогда не воспроизводится вашим кодом (например, из-за проблем с достоверным замером времени исполнения инструкций).
Это реализовано на уровне компилятора или на аппаратном уровне? Если первое, то можно ли переписать весь ваш эксплоит на ассемблер и обойти все проверки? Всё-таки вряд ли вы будете контроллировать компиляцию зловредного кода =)
Если второе, то почему вы переключаете флаги компилятора? Кажется для демонстрации влияния защиты нужно переключать только защиту, и ничего больше. Иначе эксперимент какой-то некорректный выходит.
Я всё-таки буду предполагать что ваш режим защищенных вычислений всё-таки работает на уровне компилятора. Тогда чем же он не «программная заплатка»?
…и разве всё это не снижает производительность системы?
Но как же тогда в процессорах Apple Silicon (который M1, M2, M3) всё-таки Spectre пропатчили? Там же старый-добрый ARM в качестве архитектуры и спекулятивные вычисления всё также присутствуют. Аналогично с новыми поколениями Intel, AMD.
Нетехнический наброс, но корректнее было бы вместо Mac написать Apple, всё-таки Mac это лишь линейка продуктов, как, скажем «Intel Core».
Сначала удивился, что в джаве есть целый кеш для простых чисел. Потом перешёл по ссылке и увидел, что это всего лишь кеш объектов Integer (которые boxed).
Как-будто, для этой задачи нужен очень специфичный рейд вида «записывать на быстрый диск два блока, пока на медленный пишется один», чтобы поддерживать среднюю скорость в три блока. Причём со временем соотношение скоростей будет меняться, так что придётся хранить кучу метаданных сверху.
Интересно, существуют ли уже подобные файловые системы .
Использую API, для моих целей (пару раз в неделю реализовать какой-то код по чёткому ТЗ) более чем хватает и выходит на порядок дешевле, чем платить 20$/mo (я трачу около 2$/mo). Почти никаких лимитов, а если подобрать хороший UI, то ещё и очень удобно (например, можно редактировать текст предыдущих вопросов/ответов). Лично я использую openrouter.ai.
Если у вас вдруг есть юзернеймы, то почти всегда почти точно будет какой-то функционал, который потребует по этим самым юзернеймам находить саму сущность пользователя в базе.
Если вас не атакуют, то почти всегда почти точно количество регистраций будет пренебрежимо мало по сравнению с числом легальных действий. Банально потому что пользователь регистрируется лишь однажды, а пользуется приложением часто.
Отсюда простой вывод — у вас уже должен быть general-purpose механизм поиска юзернейма в базе. Чертовски хорошо отлаженный, потому что от него зависит работа примерно всего. Который умеет как-то адекватно жить с ограничениями на количество подключений и решает множество других проблем. Возможно даже с кешированием.
Опять-таки, если вас не атакуют, то почти всегда почти точно юзернеймы будут только валидными. А поскольку регистрации составляют ничтожный объём от всей нагрузки — поддерживать только для них фильтр Блума будет накладно. Вы же помните, что всякий дополнительный индекс — ускоряет некоторые операции чтения, но замедляет все операции записи? Не считая того, что в данном случае он банально тратит ресурсы, увеличивает latency и раздувает общую сложность системы.
К слову о кешировании — почти точно ваш Redis не будет источником правды, а будет лишь кэшировать данные из чего-то более классического (и с более приятными гарантиями). И тут в полной мере встаёт вопрос «а как?». Если мы хотим не просто хранить список имён, то задача поддержания кэша в актуальном состоянии — чертовски нетривиальная с множеством разных компромиссов и тонкостей. Кажется немного опрометчивым советовать в статье для самых новичков добавить в систему кэширующий слой (особенно когда не все соки выжаты из БД).
Нет, это всё-таки проблема гугла. Их задача — принести конверсию рекламодателю, чтобы тот, в свою очередь, принес гуглу деньги. Сама по себе реклама ценности не несёт.
Но я почти уверен, что если бы на денежных метриках не сказывались меры по борьбе с адблоком, гугл бы не продолжал тратить на это свои ресурсы и репутацию.
В идеальном мире, гугл бы с радостью перестал показывать рекламу тем, кто ничего не покупает, если бы это не сказалось на конверсии в других группах (и справедливо стал бы брать больше денег за оставшиеся показы). Как, например, перестал показывать рекламу в России за неимением в этом регионе релевантных рекламных роликов, которые бы могли принести конверсию.
Кажется, сейчас этот сценарий с лихвой решается открытием счета без карты. Переводы можно делать любые, обслуживание нулевое, разве что только переводы через СБП получать на счёт нельзя.
Но, скажем, Selectel вполне решил рискнуть: https://docs.selectel.ru/en/cloud/servers/create/create-gpu-server/#available-gpus =)
Очень классическая задача про броски яиц с небоскреба, но в урезанной формулировке: https://changyaochen.github.io/egg-drop-problem/
В данном случае мы перебираем «высоту» и имеем две попытки. Статья по ссылке содержит вывод ответа для этого простого случая (такой же как и по ссылке в Академии, но в другой форме).
А вот описать решение для
серверов уже найти веселее, особенно за 
бросков =)
Лицензия запрещает использовать код unrar для создания rar, а людям хочется уметь создавать архивы тоже.
Яндекс видимо решил стабильно держаться в топе Хабра: сначала инцидент с NTP, теперь вот это. Интересно почитать как так вышло, что задело все зоны доступности
К слову, в статье есть график с подписью «динамика числа отправляемых колонками NTP-запросов». Вопрос тут в том, почему на него никто не обратил внимание, но в статье пишут что банально уведомления не были настроены.
Не самый высокий приоритет был когда редкие технические продвинутые пользователи попадали на первую линию поддержки и писали «а у меня что-то станция часто запросы делает, это ок?».
Из текста, когда багу всё-таки обнаружили, её почти сразу пофиксили (пока ещё не осознавая масштабы проблемы) и медленно выкатывали (релизный цикл видимо порядка недели), а когда на хабре написали про большой факап всея рунета и популярно объяснили масштаб беды, предприняли альтернативные, но более рискованные меры.
ИМХО, это вполне себе высокий приоритет — в воскресенье применять правку конфига катить на 100% устройств — учитывая что дождаться обычной выктаки фикса оставалось всего около трёх дней.
Я бы лично настаивал на том чтобы докатить по стандартному флоу и без доп.рисков, нежели тратить свой выходной на то чтобы найти и придумать альтернативу, собрать фикс, выкатить, а утром понедельника рисковать увидеть новости в духе «Алисы по всей России перестали показывать время, миллионы будильников не сработали». Чай ещё три дня ддоса погоды рунету не сделают.
Да. Привычный hashmap внезапно превращается из замечательной коллекции с O(1) доступом в O(N). Это запросто приводит к O(N^2) от входных данных (контроллируемых злоумышленником) и резко усиливает эффективность атаки. Например, представьте что вам приходит массив некоторых сущностей и вы всегда проверяете, что у них всех различный ID.
Более того, в случае хэшмапы нельзя использовать криптографические функции, иначе ваш сервис ляжет и без зловредной нагрузки =)
PhantomData не позволяет как-то сделать множество мутабельных ссылок. В main() важна только сигнатура new(), которая гласит «захватывает мутабельную ссылку и возвращает объект с временем жизни не больше чем эта ссылка». Ну и ссылка будет захвачена до тех пор, пока живёт этот объект. Сам объект или функция new() тут уже никак не анализируется.
Пример работает потому что первая ссылка (slot) из-за non lexical lifetimes уничтожается раньше конца блока, чтобы не допустить нарушения правила. Если попытаться её всё-таки заставить существовать одновременно с another_ref, то всё рассыпается: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e10d0e0640175ff2f74aace396915ecd
Я тоже так сначала прочитал, но по тексту это только одна плашка и в итоге было установлено 32*6=192ГБ памяти
Учитывая количество уязвимых устройств — достаточно на них массово зарегистрировать принтер «Save To PDF» и ждать случайных срабатываний. Кто-нибудь, да выберет не тот пункт в менюшке.
Суть атаки в том, что добавление принтера в систему происходит без участия пользователя. Социальная инженерия нужна только чтобы запустить задание печати на этом принтере — только тогда выполняется произвольный код.
Не без этого, но всё-таки он скорее хотел привлечь внимание к уязвимости, потому что трёхнедельная переписка с разработчикам никаких плодов не дала.
Поэтому и ссылается на инженеров из RedHat, именно которые и нарисовали цифру 9.9. Откуда они это взяли — тот ещё вопрос, но видимо по каким-то формальным критериям сильно выстрелило.
Так уже есть Skype for Business — как раз-таки on-premise для компаний с AD