Обсуждение:Meltdown (уязвимость безопасности)

Эта статья имеет рейтинг C-класса по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects :

Вычислительная техника : программное обеспечение / безопасность Высокая важность Эта статья находится в рамках WikiProject Computing , совместных усилий по улучшению освещения компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing High This article has been rated as High-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Mid-importance). This article is supported by Computer hardware task force (assessed as High-importance). This article is supported by WikiProject Computer Security (assessed as High-importance). Things you can help WikiProject Computer Security with: edit history watch purge Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information... Review importance and quality of existing articles Identify categories related to Computer Security Tag related articles Identify articles for creation (see also: Article requests) Identify articles for improvement Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc. Find editors who have shown interest in this subject and ask them to take a look here. Linux Mid‑importance This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux Mid This article has been rated as Mid-importance on the project's importance scale. Microsoft Windows: Computing Mid‑importance This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Computing. Apple Inc. Mid‑importance This article is within the scope of WikiProject Apple Inc., a collaborative effort to improve the coverage of Apple, Mac, iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc. Mid This article has been rated as Mid-importance on the project's importance scale.

Пожалуйста, объедините эту статью с Kernel page-table isolation . - Mardus / talk 22:18, 3 января 2018 (UTC) [ ответить ]

В идеале эта страница должна быть об уязвимости Meltdown, а KPTI — просто о смягчении/функции? Хотя я не уверен, насколько они отличаются. Legoktm ( обсуждение ) 23:46, 3 января 2018 (UTC) [ ответить ]

KPTI/KAISER изначально предлагался в первую очередь как чрезвычайно широкое (но потенциально дорогостоящее!) средство смягчения атак обхода KASLR . Я считаю, что оно было предложено до обнаружения Meltdown. Meltdown намного хуже простого обхода KASLR, поскольку способен напрямую читать всю отображенную память. KPTI/KAISER, будучи очень широким молотком, останавливает чтение памяти ядра с помощью ошибки, и именно поэтому он был фактически принят. 184.176.111.201 (обсуждение) 00:33, 4 января 2018 (UTC) [ ответить ]

На данный момент объяснение выглядит следующим образом:

1. Процессор пытается выполнить инструкцию, ссылающуюся на операнд памяти. Режим адресации требует, чтобы адрес операнда, Base+A, был вычислен с использованием значения по адресу, A, запрещенному для процесса системой виртуальной памяти и проверкой привилегий. Инструкция планируется и отправляется в блок выполнения. Затем этот блок выполнения планирует как проверку привилегий, так и доступ к памяти.

2. Проверка привилегий информирует исполнительный блок о том, что адрес A, задействованный в доступе, запрещён для процесса (согласно информации, хранящейся в системе виртуальной памяти), и, таким образом, инструкция должна завершиться неудачей. Затем исполнительный блок должен отменить эффекты чтения памяти. Однако одним из таких эффектов может быть кэширование данных в Base+A, которое могло быть завершено как побочный эффект доступа к памяти до проверки привилегий — и могло не быть отменено исполнительным блоком (или любой другой частью ЦП). Если это действительно так, то сам по себе акт кэширования представляет собой утечку информации. В этот момент вмешивается Meltdown.[45]

3. Процесс выполняет атаку по времени, выполняя инструкции, напрямую ссылающиеся на операнды памяти. Чтобы быть эффективными, операнды этих инструкций должны находиться по адресам, которые покрывают возможный адрес, Base+A, операнда отклоненной инструкции. Поскольку данные по адресу, на который ссылается отклоненная инструкция, Base+A, тем не менее были кэшированы, инструкция, напрямую ссылающаяся на тот же адрес, будет выполняться быстрее. Процесс может обнаружить эту разницу во времени и определить адрес, Base+A, который был рассчитан для отклоненной инструкции, и таким образом определить значение по запрещенному адресу памяти A.

Это слишком многословно, но, что более важно, во многих местах НЕВЕРНО:

"Режим адресации требует, чтобы адрес операнда, Base+A, был рассчитан с использованием значения по адресу" совершенно неверен - первый доступ может использовать любой режим адресации, важно то, что он должен считывать с адреса, который злоумышленник хочет знать, но ему не разрешено. Это *второй* доступ должен использовать эти данные для индексации в массиве проверки кэша. "Инструкция запланирована и отправлена ​​в исполнительный блок". Зачем это вообще нужно говорить? Чтобы сделать статью длиннее? Следующая неправильная часть: в вышеприведенном, *где* находится вторая спекулятивная загрузка, та, которая создает побочный эффект кэширования? Тот факт, что первый доступ, вероятно, также кэширует свой результат, не имеет значения для эксплойта, поскольку обнаружение того, что _это_ местоположение кэшировано, невозможно. Чтобы эксплойт сработал, вам нужно _использовать_ полученное спекулятивное значение, пока вы можете.

Я заменяю его на:

1. ЦП получает указание прочитать данные (например, один байт) по адресу, к которому текущему процессу не разрешен доступ. Чтение выполняется спекулятивно, но его результат, A, не сохраняется в видимом архитектурном состоянии ЦП. (Данные станут видимыми позже, если проверка доступа подтвердит, что доступ к этому конкретному адресу разрешен).

2. Процессор продолжает спекулятивное выполнение и теперь ему предписано прочитать нормально доступную область памяти, используя режим адресации Base+A, для вычисления с использованием значения A по адресу, спекулятивно доступному на шаге 1. Это второе чтение также выполняется спекулятивно. Это вызывает кэширование местоположения Base+A.

3. Когда результат инструкции на шаге 1 пытается завершиться и сохраниться в видимом архитектурном состоянии ЦП (попытки "уйти на пенсию"), логика ухода на пенсию обнаруживает, что доступ не был разрешен, и поэтому результаты этой и всех последующих инструкций отбрасываются. Однако эффект кэширования данных в Base+A не отменяется (кэширование не является "архитектурным состоянием"). Сам по себе акт кэширования представляет собой утечку информации.

4. Процесс выполняет атаку по времени, измеряя, насколько быстро можно получить доступ к элементам массива Base[x]. Если данные по адресу Base+A кэшированы, а все остальные элементы Base+x — нет, то только инструкция, ссылающаяся на Base+A, выполняется быстрее. Процесс может обнаружить эту разницу во времени и определить значение A, полученное отклоненной инструкцией шага 1, — и таким образом определить значение по запрещенному адресу памяти.

Пользователь Twinkle отменил мою правку. Я хотел бы обсудить это здесь. Я думаю, что моя версия не просто лучше сформулирована — она ПРАВИЛЬНА, тогда как предыдущая неверна.

Я не вижу статьи о Spectre (ошибка безопасности) Artem-S-Tashkinov ( обсуждение ) 23:59, 3 января 2018 (UTC) [ ответ ]

 Готово - пожалуйста, ознакомьтесь с недавно созданной статьей по адресу => " Spectre (уязвимость безопасности) " - помощь в разработке статьи приветствуется - в любом случае - Приятного чтения! :) Drbogdan ( обсуждение )

Пока мы этим занимаемся, я не вижу статьи о BlueBorne - как так вышло, что никто ее еще не написал? В русской и японской википедиях она есть, в английской есть только небольшая ссылка в статье о BlueTooth. Artem-S-Tashkinov ( обсуждение ) 16:27, 4 января 2018 (UTC) [ ответ ]

 Готово - @Artem-S-Tashkinov: (и другие) - для начала - пожалуйста, ознакомьтесь с недавно созданной статьей по адресу => " BlueBorne (уязвимость безопасности) " - помощь в разработке статьи приветствуется - в любом случае - Приятного чтения! :) Drbogdan ( обсуждение ) 14:51, 5 января 2018 (UTC) [ ответить ]

Оба эти бага были обнаружены в одно и то же время, и почти все новостные статьи, с которыми я сталкивался, говорили о них обоих одновременно и почти взаимозаменяемо (в некоторых случаях). Если бы это было объединено, мы могли бы переименовать статью в Meltdown и Spectre уязвимости безопасности. Pinging создатели статьи: @ Drbogdan и Legoktm : . Anarchyte ( работа | обсуждение ) 05:43, 4 января 2018 (UTC) [ ответ ]

Насколько я понимаю, эти две ошибки будут иметь разные последствия. Похоже, что Meltdown имеет доступные исправления и в основном будет смягчен. Он также в основном затронул облачных провайдеров. Но Spectre — это совсем другая история, он затрагивает всех производителей чипов и все типы устройств. В статье упоминается, что они могли выполнять JavaScript в Google Chrome и считывать данные в частную память прямо оттуда. И похоже, что общая стратегия смягчения заключается в том, чтобы парализовать функции браузера ([1]) и ждать исправления в оборудовании, на что уйдут годы. Я еще не успел дочитать статью о Spectre, поэтому, пожалуйста, поправьте меня, если я ошибаюсь. Legoktm ( talk ) 06:28, 4 января 2018 (UTC) [ ответить ]

Последствия будут разными, но источник двух уязвимостей один и тот же. Они даже были анонсированы в одно и то же время и имеют один и тот же сайт. Более того, с определенной точки зрения Meltdown можно рассматривать как частный случай более общего Spectre. Таким образом, я бы по крайней мере поддержал слияние.

В то же время я бы сказал, что конкретные смягчения явно заслуживают своих собственных страниц, потому что у них другое происхождение и другие применения. Для использования в Википедии их соответствующие библиографии также будут сильно отличаться, по крайней мере на этом этапе. Decoy ( talk ) 07:06, 4 января 2018 (UTC) [ ответить ]

Источник двух уязвимостей не один и тот же. Одна из них связана с предсказанием ветвлений , другая — нет. Одна из них связана с реализацией только чипов Intel , другая — более общая, и у них есть два названия по определенной причине. Объединение этих двух уязвимостей не помогает и не следует из фактов, что они разные, и одна из них обходная, а другая — нет. Хотя я могу понять желание охватить обе вместе, они разные, связанные темы лучше не объединять. Widefox ; обсуждение 14:05, 4 января 2018 (UTC) [ ответить ]

Но это: спекулятивное выполнение. Хотя статья Spectre действительно сосредоточена на предсказании ветвлений, в своей последней части она также подробно рассматривает, как могут быть использованы формы спекулятивного выполнения, не предсказывающие ветвления. С этой точки зрения Meltdown — это всего лишь один из особенно детерминированных способов вызова спекулятивного выполнения на определенной архитектуре, что приводит к эксплуатируемым побочным эффектам. По сути, именно поэтому две статьи были опубликованы вместе и могут потребовать рассмотрения как единое целое.

Очевидно, я не собираюсь выдвигать этот вопрос. Тем более, что я не являюсь коренным жителем Википедии и не знаком со всеми правилами здесь. Но технологическая сторона вопроса по-прежнему довольно ясна для любого, кто читает газеты. Утверждение I. ;) Decoy ( talk ) 16:15, 4 января 2018 (UTC) [ ответить ]

• Не объединяйте. Я поддерживаю оценку Legoktm. Spectre и Meltdown — это разные недостатки. - Mardus / talk 08:19 , 4 января 2018 (UTC) [ ответить ]
• Выступайте против слияния в это время. Я думаю, если бы была одна статья, то это должно быть что-то общее, например, уязвимости спекулятивного исполнения (или содержаться в спекулятивном исполнении ), а не упоминать оба этих (несколько надуманных) названия, но похоже, что достаточно информации для отдельных страниц, которые могут быть связаны отдельно от других статей. Я бы предпочел подождать, пока это не разыграется больше, чтобы увидеть, придумает ли отрасль общий ярлык, который будет охватывать оба (или все три , как сказано в сообщении в блоге Google) вида уязвимости, и заслуживают ли подробности отдельных статей в долгосрочной перспективе. —DIYeditor ( обсуждение ) 08:32, 4 января 2018 (UTC) [ ответить ]

Согласен по поводу «спекулятивных уязвимостей исполнения» и «в настоящее время». Это будет происходить отсюда, но для Википедии это может быть слишком рано. Decoy ( обсуждение ) 09:38, 4 января 2018 (UTC) [ ответить ]

• Против : FWIW - я также против объединения двух статей об уязвимостях безопасности (т. е. " Meltdown " и " Spectre ") по причинам, очень хорошо описанным выше - надеюсь, это поможет в некотором роде - в любом случае - Наслаждайтесь! :) Drbogdan ( обсуждение ) 12:52, 4 января 2018 (UTC) [ ответить ]
• Полностью согласен (но условно). Должна быть одна статья с «кратким обзором», которая обсуждает их одновременно. Причин для этого много. Как заметил родитель, они рассматриваются нечетко, хотя на самом деле это отдельные недостатки. Кроме того, они происходят одновременно. Во-вторых, из-за определенной путаницы, которая последует, читатели либо перепутают эти два слова, либо неправильно напишут слово spectre и будут искать meltdown, надеясь, что это приведет к другому. В-третьих, большинство читателей захотят получить краткое изложение того, что представляют собой недостатки, в чем заключаются различия и как это повлияет на них. Они не захотят вдаваться в технический обзор, хотя есть бесчисленное множество программистов, которые будут искать именно это. В-четвертых, не все процессоры и, следовательно, компьютеры затронуты или будут затронуты (хотя полученные «исправления» могут отрицательно повлиять на производительность). Должна быть отдельная статья о том, какие процессоры затронуты и как различные операционные системы (и версии) для них справляются с этим недостатком. В-пятых, в основной статье должен быть параграф о правовых последствиях, а также о последствиях обоих недостатков, с которыми будет трудно разобраться в отдельных статьях. Поэтому должна быть одна «обзорная статья», которая может иметь ссылки на другие, более подробные статьи. Это было сделано бесчисленное количество раз в Википедии, и для меня здесь ясно как день, что именно так должно происходить редактирование сейчас. Nodekeeper ( обсуждение ) 13:44, 4 января 2018 (UTC) [ ответ ]

• Oppose, это разные недостатки, влияющие на разные процессоры, хотя и связанные. Один из них исправлен и обойден, другой — нет. Время не имеет значения, пока они оба заметны, что, я считаю, так и есть. Читатели уже лучше обслуживаются статьей по каждой теме, и это будет только усиливаться по мере их роста. Это закрытие WP:SNOW . Widefox ; обсуждение 13:54, 4 января 2018 (UTC) [ ответить ]
• Oppose Это разные уязвимости, которые затрагивают два почти разных набора оборудования. Потенциальная путаница между Spectre и Meltdown для читателей может быть устранена, если отметить, что они были публично раскрыты в одно и то же время, и убедиться, что ссылки на друг друга присутствуют вместе с тем, почему другой отличается. -- M asem ( t ) 14:28, 4 января 2018 (UTC) [ ответить ]

Я согласен закрыть это как "не объединенное", поскольку, похоже, этого не произойдет , хотя некоторые могут захотеть оставить это открытым на 24 часа (для обсуждения объединения нет временных ограничений, и, поскольку это популярная страница, я думаю, что мы скоро достигнем видимого консенсуса). Ура, Anarchyte ( работа | обсуждение ) 14:32, 4 января 2018 (UTC) [ ответить ]

Я знаю, что все против объединения, но структура, которую я упомянул в своем посте, неизбежна. Если бы мы объединили, статья была бы слишком длинной, а если мы не объединим, то в конечном итоге будет слишком много разрозненных статей по этой одной теме, а эти две необъединенные статьи будут слишком длинными сами по себе. Это как пытаться избежать гравитации. Nodekeeper ( talk ) 18:17, 4 января 2018 (UTC) [ ответить ]

• Oppose Meltdown — это проблема Intel, в то время как Spectre — это «фича» большинства процессоров с внеочередным выполнением. Они связаны косвенно, поэтому должны быть взаимосвязаны. Artem-S-Tashkinov ( talk ) 16:30, 4 января 2018 (UTC) [ reply ]
• Oppose Хотя эти проблемы в чем-то похожи и обсуждаются вместе, это разные проблемы с разными затронутыми системами, разными мерами по смягчению и т. д. В самой статье говорится: «Meltdown отличается от атак Spectre несколькими способами, в частности тем, что Spectre требует адаптации к программной среде процесса-жертвы, но применяется в более широком смысле к ЦП и не смягчается  KAISER ». Давайте оставим их как есть и сделаем перекрестную ссылку. Laboramus ( обсуждение ) 18:27, 4 января 2018 (UTC) [ ответ ]
• Поддержка (изменено с «Против, но »)

После обсуждения и описания проблемы с несколькими людьми я изменил свое мнение и теперь считаю, что сходств больше, чем различий. В частности, официальное описание самих атак говорит о вариантах 1, 2 и 3, где 1 и 2 — это Spectre, а 3 — Meltdown. Я думаю, что проще описать основную проблему спекулятивного выполнения + побочного канала синхронизации кэша один раз , а затем указать различные способы ее применения. Сделав это на одной странице, а не дублируя объяснение на двух, я считаю, что читатели лучше поймут. (Эта часть основана на моем опыте общения с людьми.)

Просто для пояснения различий:

• Оба используют тот факт, что при отмене спекулятивного выполнения обнаруживаемые (через временные каналы ) изменения в состояниях кэша сохраняются.
• Meltdown использует спекулятивные данные : тот факт, что Intel задерживает проверку разрешений на доступ к памяти настолько, что можно запустить вторую спекулятивную загрузку, адрес которой является функцией данных, возвращаемых первой спекулятивной загрузкой. Если первая загрузка была запрещена (нет разрешения на чтение), считанные данные можно восстановить с помощью атаки по времени на эффекты состояния кэша второго доступа. (Нет никаких фундаментальных технических причин, по которым проверка разрешений должна быть отложена так сильно; Intel просто не видела причин делать это более срочно, учитывая, что механизм перемотки спекуляции был доступен, а незаконные загрузки крайне редки в обычном программном обеспечении, поэтому задержка оказала незначительное влияние на производительность. AMD приняла другое решение по реализации и в итоге оказалась неуязвимой.)
• Spectre использует спекулятивный поток управления . В более серьезном варианте атакующий процесс загрязняет аппаратное обеспечение косвенного предсказания ветвлений, чтобы заставить целевой процесс (спекулятивно) перейти в произвольное контролируемое злоумышленником место в целевом адресном пространстве .

В обоих случаях спекулятивные операции отменяются без изменения архитектурного состояния, но эффекты кэширования сохраняются, и данные могут быть извлечены через каналы синхронизации. Это общая часть, которая может быть обсуждена в общей статье. 23.83.37.241 ( обсуждение ) 19:39, 4 января 2018 (UTC) Изменено с Oppose на Support 23.83.37.241 ( обсуждение ) 22:01, 5 января 2018 (UTC) [ ответить ]

У нас есть место для этого, Спекулятивное исполнение#Уязвимости безопасности . —DIYeditor ( обсуждение ) 22:28, 5 января 2018 (UTC) [ ответить ]

• Против (против слияния, я поддерживаю текущее разделение статьи) Причины, по которым я против/поддержу, следующие: (a, против) На техническом уровне это буквально разные виды. (b, поддерживаю) Новостные статьи и исходные материалы группируют их вместе, (c, против) в соответствии с рекомендациями Википедии относительно соответствующей структуры, я считаю, что их следует хранить как полностью отдельные статьи. (d, против) Возможно, по мере того, как пройдет время после исправления/обходных путей/и т. д. этих уязвимостей безопасности, может иметь смысл объединить их, но на данный момент мы не знаем, какими путями они пойдут, и их объединение может оказаться пустой тратой, если будущее событие заставит их разделить. Это моя часть. 134.186.234.108 ( обсуждение ) 16:20, 10 января 2018 (UTC) [ ответить ]

В статье сейчас говорится: «выпустил идентификатор Common Vulnerabilities and Exposures ID CVE-2017-5754 в январе 2018 года». Но учитывая, что в идентификаторе есть «2017», идентификатор был явно выпущен в 2017 году. Я не думаю, что дата выпуска идентификатора важна. Я думаю, что его следует перефразировать, возможно, чтобы указать дату, когда CVE был раскрыт общественности. Но это уже включено в раздел «История», так что, возможно, просто полностью удалите «в январе 2018 года» из предложения. Booch ( обсуждение ) 16:55, 4 января 2018 (UTC) [ ответить ]

Соответствующая часть из CVE FAQ MITRE ([2]): «Уязвимость обнаружена в 2015 году, и запрос на идентификатор CVE сделан в 2015 году. Уязвимости присвоен идентификатор «CVE-2015-NNNN», но он не опубликован. (Идентификатор CVE будет отображаться как «Зарезервирован» в списке CVE.) Однако раскрывающая сторона не публикует идентификатор CVE публично до 2017 года. В этом случае идентификатор CVE по-прежнему будет «CVE-2015-NNNN», несмотря на то, что уязвимость не была опубликована до 2017 года».

Таким образом, issual следует обычным правилам этики и управления пространством имен: «идентификаторы устанавливаются при первом выделении, а не при первой публикации». ;) Decoy ( обсуждение ) 18:29, 4 января 2018 (UTC) [ ответить ]

Я пытаюсь выяснить, какие процессоры затронуты. 32-битные процессоры не затронуты, и некоторые 64-битные процессоры также не затронуты этим. Я обновлю статью по мере появления новостей и буду признателен за помощь других редакторов. Nodekeeper ( обсуждение ) 20:09, 4 января 2018 (UTC) [ ответ ]

Очевидно, что все 32-битные процессоры Intel также затронуты. Nodekeeper ( обсуждение ) 03:06, 5 января 2018 (UTC) [ ответить ]

Придираюсь, но почти уверен, что это не так. Все отчеты предполагают, что это как минимум требует спекулятивного выполнения , что означает, что 32-битный 80386 для Pentium определенно не будет затронут. Только Pentium Pro и далее могут быть затронуты. В нашей статье в настоящее время упоминаются Atom до 2013 года, я полагаю, это потому, что они не поддерживают конкретные инструкции, на которые опирается Meltdown. Я не знаю, когда он был представлен, но подозреваю, что это было после Pentium Pro. (Но Pentium Pro и далее, включая Atoms, все еще будут затронуты некоторыми идеями Spectre.) Nil Einne ( обсуждение ) 10:39, 5 января 2018 (UTC) [ ответ ]

На самом деле, прошу прощения, я ошибаюсь насчет Atoms. Наше Out-of-order execution предполагает, что у них этого нет до Silvermont , что означает, насколько мне известно, у них не может быть спекулятивного исполнения. Вот почему они не затронуты. Так что быть неуязвимым на самом деле не так старо, как Pentium. Я немного запутался, всегда ли у Quarks есть спекулятивное исполнение [3] [4] Nil Einne ( talk ) 10:56, 5 января 2018 (UTC) [ ответить ]

Bonnell (микроархитектура), похоже, подтверждает, что все атомы, основанные на этом, лишены спекулятивного исполнения. Nil Einne ( обсуждение ) 11:43, 5 января 2018 (UTC) [ ответить ]

Сейчас у нас есть Meltdown и Spectre, но и Google[5], и AMD[6] указывают, что есть три варианта. По-видимому, все они основаны на спекулятивном исполнении. По этому поводу потребуются разъяснения. Также обратите внимание, что аргументы в пользу объединения в одну статью (со ссылками на вторичные статьи) становятся сильнее. Nodekeeper ( обсуждение ) 20:51, 4 января 2018 (UTC) [ ответить ]

Я указал, что есть третья разновидность выше в обсуждении слияния. Нельзя ли просто обсудить какие-либо общие черты в Speculative execution#Security vulnerabilities ? Этот раздел определенно нуждается в некотором расширении; я добавил только краткое упоминание. Настроение было довольно сильным против слияния статей Meltdown и Spectre, и я думаю, что для отдельных статей достаточно контента и отличительных черт. —DIYeditor ( обсуждение ) 21:33, 4 января 2018 (UTC) [ ответить ]

Спасибо за ваш комментарий. Мы видим, как статья складывается воедино. Похоже, что уязвимость Meltdown принадлежит исключительно Intel, в то время как другая уязвимость «архитектурного недостатка» будет относиться к «исполнению вне очереди», подмножеством которого является «спекулятивное исполнение». Таким образом, процессор Intel потенциально может иметь все варианты недостатков спекулятивного исполнения, в то время как другие процессоры (ARM, AMD и кто угодно) будут иметь недостатки «архитектуры». Исследования и прослушивание осведомленных источников показывают, что последний (Spectre) представляется наиболее опасным в долгосрочной перспективе, поскольку от него гораздо сложнее защититься архитектурно. Все три варианта попадают под «уязвимости спекулятивного исполнения». Кроме того, следует отметить, что все эти новости выходят до формально запланированного объявления 9 января. Nodekeeper ( обсуждение ) 22:49, 4 января 2018 (UTC) [ ответить ]

Да, есть три уязвимости. В блоге Project Zero они описаны так:

• (Spectre) Вариант 1: обход проверки границ (CVE-2017-5753)
• (Spectre) Вариант 2: внедрение целевой ветви (CVE-2017-5715)
• (Meltdown) Вариант 3: несанкционированная загрузка кэша данных (CVE-2017-5754)

Legoktm ( обсуждение ) 09:19, 5 января 2018 (UTC) [ ответить ]

В статье говорится, что уязвимо только x86 от Intel. Однако Apple только что опубликовала заявление здесь https://support.apple.com/en-us/HT208394, в котором говорится, что их собственные процессоры Ax также уязвимы. -- 64.121.146.209 (обсуждение) 03:20, 5 января 2018 (UTC) [ ответить ]

Спасибо за ваш вклад. Было бы полезно, если бы вы зарегистрировались в Википедии с именем пользователя, чтобы мы могли лучше вас узнать. Пожалуйста, обратите внимание, что все эти уязвимости попадают под «спекулятивное выполнение» и что существуют различные «типы» спекулятивного выполнения. И Meltdown, и Spectre относятся к этому типу уязвимости. Apple использует как чипы Intel, так и Arm. Когда они говорят, что процессоры Ax (которые похожи на ядра ARM) подвержены уязвимости, они имеют в виду уязвимость Spectre. Процессоры Intel, которые они используют, также будут иметь уязвимость Meltdown, которая, согласно цитируемым источникам, влияет только на процессоры Intel. По мере того, как факты об этом станут более ясными, статью можно будет изменить, чтобы отразить это. Также прокрутите вниз до «Затронутое оборудование», где подробно рассказывается о том, какие процессоры подвержены уязвимости. Nodekeeper ( обсуждение ) 04:40, 5 января 2018 (UTC) [ ответить ]

Аккаунты — отстой, Википедия: IP-адреса тоже люди . Во-первых, вся статья изначально была написана как тирада против Intel с нелепыми проблемами PoV. Во-вторых, в статье предполагается, что P6 затронут, потому что у него есть спекулятивное выполнение, к сожалению, этого недостаточно, чтобы сделать такое предположение. Более того, P6 вряд ли затронут, потому что он на самом деле не делает спекулятивного доступа к памяти, улучшение, которое было добавлено гораздо позже. -- 64.121.146.209 (обсуждение) 05:50, 5 января 2018 (UTC) [ ответить ]

По предоставленной вами ссылке вы ограничены в своих возможностях. [[ Wikipedia:IP-адреса тоже люди#Что незарегистрированный пользователь не может сделать самостоятельно (напрямую) . Неважно, вы улучшили статью, и я включил изменения, на которые вы меня вдохновили. Nodekeeper ( обсуждение ) 06:46, 5 января 2018 (UTC) [ ответить ]

«Кроме того, P6 вряд ли затронут, потому что он на самом деле не делает спекулятивный доступ к памяти» - Это не спекулятивный доступ к памяти, а скорее выполнение вне очереди, частью которого является спекулятивное выполнение. Происходит то, что процессор пытается выполнить несколько инструкций заранее. Некоторые из этих инструкций могут считывать привилегированную память. Когда он это делает, то процесс с более низкими привилегиями может считывать то, что считывает спекулятивная ветвь, и, следовательно, получать доступ к данным с более высокими привилегиями спекулятивной ветви, которые могут включать пароли. Этот недостаток присущ спекулятивному выполнению вне очереди, которое есть у P6. Nodekeeper ( обсуждение ) 06:57, 5 января 2018 (UTC) [ ответить ]

ARM опубликовала заявление, в котором говорится, что A75 уязвим к meltdown, а A15, A57 и A72 уязвимы к варианту meltdown. Но затем они также говорят, что для чипов, затронутых вариантом, не требуется никакого программного смягчения. Legoktm ( talk ) 09:28, 5 января 2018 (UTC) [ ответить ]

Первый абзац не соответствует стилю Википедии для вводного абзаца WP:LEAD , и я был бы признателен другим редакторам за помощь в его возврате назад или радикальном сокращении в соответствии с WP:LEAD . Редактор, который его изменил, не только не следует WP:LEAD , но и не обсуждает в talk, как было предложено, и не работает над WP:CONSENSUS . Nodekeeper ( talk ) 08:13, 5 января 2018 (UTC) [ ответить ]

Если это имеет отношение к запутанной формулировке (и что выглядит неточной – она не включает все устройства Microsoft Windows, поскольку это уязвимость оборудования?), я только что попытался это исправить. Throne3d ( обсуждение ) 17:40, 5 января 2018 (UTC) [ ответить ]

Спасибо за помощь. Теперь лид читается намного лучше. Технически это не все устройства Microsoft Windows, потому что Windows была портирована на другие устройства, на которых нет процессоров Intel, например, их планшеты Surface используют процессоры с ядрами ARM, не все из которых уязвимы (в отличие от Intel, где уязвимы почти все). Но Microsoft действительно удерживает большинство для установленных ОС рабочих столов. Так что кто-то может сказать «все рабочие столы Microsoft Windows» и быть правым, но не «все устройства Windows». Nodekeeper ( обсуждение ) 18:17, 5 января 2018 (UTC) [ ответить ]

Никаких проблем! Я имел в виду больше – разве у вас не может быть настольного компьютера AMD под управлением Microsoft Windows, который не будет затронут, поскольку он не использует затронутое оборудование? Throne3d ( обсуждение ) 19:36, 5 января 2018 (UTC) [ ответить ]

У меня такое чувство, что к тому времени, как это будет сделано, мы все станем экспертами по конвейеризации ветвей микропроцессоров !:D Так что AMD на самом деле уязвима для одного из вариантов Spectre, но не Meltdown, который действительно бьет по Intel. Вариант Spectre на самом деле является «структурным» недостатком, а не недостатком программирования «микрокода», как Meltdown. Вот очень хорошая статья о процессорах AMD. AMD удалось вырваться вперед в PR-битве и выглядит хорошо, хотя некоторые из их процессоров (например, линейка FX) на самом деле уязвимы для Spectre, который на самом деле является более проблемным из двух багов. Так что, если вы хотите подключить компьютер сегодня и не быть уязвимым, вам нужно будет взглянуть на компьютер Raspberry Pi (который некоторые люди используют как минимальный рабочий стол Linux). Или найти планшет с процессором ARM, не входящим в список уязвимых. Однако Microsoft и Linux скоро выпустят исправления для своих операционных систем, но он будет иметь снижение производительности из-за исправления Spectre, о котором все говорят, пока исправление Google не будет реализовано в широком масштабе. Я думаю, что Linux может опередить Microsoft в этом, потому что команда Google уже внедрила свое исправление в компилятор GCC . Кстати, это немного смешно, потому что на одном из форумов не так давно, до того, как эти уязвимости стали известны, пользователи обсуждали, почему Linux не на рабочем столе, а ряд постеров жестко критиковали компилятор GCC, потому что он не очень хорошо оптимизирует программы для выполнения вне очереди — а это часть, ответственная за Spectre! Также со временем, возможно, будут найдены другие типы уязвимостей выполнения вне очереди (особенно в других процессорах, которые еще не упоминались), что демонстрируют проблемные варианты ARM. Nodekeeper ( обсуждение ) 03:44, 6 января 2018 (UTC) [ ответить ]

Галлахер, С. (4 января 2017 г.) «Генеральный директор Intel продал все акции, которые мог, после того, как Intel узнала об ошибке безопасности» Ars Technica

Брайан Кржанич, генеральный директор Intel, продал акции Intel на миллионы долларов — все, с чем он мог расстаться в соответствии с корпоративными уставами — после того, как Intel узнала о Meltdown и Spectre, двух связанных семействах уязвимостей безопасности в процессорах Intel. Хотя представитель Intel сказал репортеру CBS Marketwatch Джереми Оуэнсу, что сделки «не связаны» с раскрытием информации о безопасности, а финансовые документы Intel показали, что продажа акций была запланирована ранее, Кржанич запланировал эти продажи на 30 октября. Это через целых пять месяцев после того, как исследователи сообщили Intel об уязвимостях. И Intel не предоставила никаких дополнительных объяснений того, почему Кржанич внезапно продал все акции, которые ему было разрешено продать. В результате продажи акций Кржанич получил более 39 миллионов долларов.

Я хотел бы увидеть это в обобщенном виде в статье. YATA 123 (обсуждение) 12:01, 5 января 2018 (UTC) [ ответить ]

В ссылке arstechnica, которую вы прислали, на самом деле не так уж много информации. По сути, «должностные лица SEC все еще могли бы рассматривать маневр как торговлю, основанную на инсайдерской информации, особенно если бы не было других существенных причин для продажи акций Кржаничем». Главное слово там — ЕСЛИ. Скандал, тем не менее, захватывающий.

Я извиняюсь за то, что отверг это, основываясь только на одной ссылке... Есть много других ссылок, которые предполагают, что это в какой-то степени вина Intel:

https://www.wsj.com/articles/intel-wrestled-with-chip-flaws-for-months-1515110151 https://investorplace.com/2018/01/intel-corporation-intc-should-fire-brian -кржанич/ https://www.prnewswire.com/news-releases/kaplan-fox-announces-investigation-of-intel-corporation-300578289.html

Но опять же, есть много IF. Я собираюсь придерживаться Because Google здесь. Пока мы не получим больше информации о том, как Intel, возможно, где-то облажался. — Предыдущий неподписанный комментарий добавлен 108.185.180.195 ( обсуждение ) 17:29, 5 января 2018 (UTC) [ ответить ]

Это сообщение в почтовых рассылках OpenBSD относительно дефектов в процессорах Intel может быть связано с Meltdown. Упомянутый документ по исправлениям все еще доступен в архивной форме здесь. -- Tactica ( обсуждение ) 17:33, 5 января 2018 (UTC) [ ответ ]

Вероятно, должно быть «необнаружимым образом»? -- Тактика ( обсуждение ) 19:49, 5 января 2018 г. (UTC) [ ответ ]

На самом деле, то, что там написано, правильно, хотя и запутанно. Перефразируя то, что говорится, когда привилегированная программа делает чтение программы в ветви спекулятивного выполнения, она делает это «обнаруживаемым образом» программой с более низкими привилегиями. Неисправный микропроцессор проверяет привилегии *после* спекулятивного выполнения, позволяя программе с более низкими привилегиями доступ, пока она этого не сделает. AMD избежала этой ошибки, потому что они проверяют привилегии *до* спекулятивного выполнения, и, следовательно, программа с более низкими привилегиями не может обнаружить данные в ветви спекулятивного выполнения с более высокими привилегиями. Nodekeeper ( обсуждение ) 02:00, 6 января 2018 (UTC) [ ответить ]

Я все еще нахожу это довольно запутанным, но я уловил суть. Я последовал примеру в испанском переводе, спасибо! :) -- Tactica ( talk ) 17:53, 6 января 2018 (UTC) [ ответить ]

Массив 5000 должен быть доступен мошенническому процессу. Ему нужно будет получить к нему доступ, чтобы измерить время доступа. Пункт девять должен заканчиваться так: Таким образом, даже если сама инструкция не удалась, и даже если процесс не может напрямую прочитать содержимое адреса 2000, мошеннический процесс все равно может использовать свою атаку по побочным каналам, чтобы определить, что адрес 5004 находится в кэше, а другие адреса между 5001 и 5005 — нет, поэтому он все равно может определить, что второй адрес, который инструкция попыталась бы прочитать, — это 5004, и, следовательно, что содержимое несанкционированного адреса 2000 — это «4». 69.12.251.25 (обсуждение) 19:57, 5 января 2018 (UTC) [ ответить ]

В разделе «История» о том, кто обнаружил и/или сделал возможной уязвимость общедоступной, может быть полезна следующая информация. На ^[1] приведена ссылка на ^[2] , страница от 28.07.2017, которая довольно подробно описывает возможный подход к уязвимости с простыми примерами кода, показывающими эффект. Автор не придумал полностью работающий эксплойт, но его предположения точно такие же, как и реализованные в атаке Meltdown позже. Если дата страницы верна, что я не могу подтвердить/опровергнуть, Автор должен быть как-то указан. Эта информация общедоступна уже более 5 месяцев. Есть ли способ проверить, действительно ли веб-страница такая старая, как на ней указано? Спасибо. 91.5.148.221 (обсуждение) 00:34, 6 января 2018 (UTC) [ ответ ]

Вот эта статья Reuters [7], в которой подробно описывается, как разворачивалось открытие. Очевидно, была статья, написанная в июне прошлого года, и статья Reuters, похоже, намекает, что ошибка была обнаружена в декабре прошлого года, до этого, в 2016 году. Nodekeeper ( talk ) 02:19, 6 января 2018 (UTC) [ reply ]

Да, вы можете просмотреть старые версии, начиная с 28 июля 2017 года, на Wayback Machine (часто используется, например, для демонстрации предшествующего уровня техники в патентах):

^[3]

В версии от 28.07.2017 определенно описывается использование атаки по времени кэширования для наблюдения за результатами спекулятивных операций, обусловленных данными, полученными с недействительными привилегиями. Мне это очень напоминает Meltdown. Определенно стоило упомянуть.

Есть ли что-то определенное или доказанное о состоянии уязвимости любого из процессоров на базе сокета Intel 478/775 к расплавлению? Были ли эти процессоры специально протестированы? А как насчет линейки процессоров Via x86 (C7/C7M)? — Предыдущий неподписанный комментарий добавлен 198.2.94.117 (обсуждение) 16:15, 6 января 2018 (UTC) [ ответить ]

Мне тоже интересно узнать об уязвимости процессоров Via. Я заметил, что статьи и на Meltdown, и на Spectre, похоже, вообще не упоминают Via, как будто Intel и AMD — единственные бренды процессоров 80686 и x86-64. Brolin Empey 09:20, 10 января 2018 (UTC) — Предыдущий неподписанный комментарий добавлен Brolin Empey ( обсуждение • вклад )

Я проверил /proc/cpuinfo на ядре Linux 4.15 на HP 2133 Mini-Note PC с процессором VIA C7-M, который, по-видимому, уязвим как для Meltdown, так и для Spectre, как показано на этом снимке экрана. Может ли кто-нибудь проверить на VIA Nano, преемнике x86-64 80686 C7? Brolin Empey 20:56, 31 октября 2018 (UTC) — Предыдущий неподписанный комментарий добавлен Brolin Empey ( обсуждение • вклад )

В статье говорится, что «данные с неавторизованного адреса почти всегда будут временно загружены в кэш ЦП во время спекулятивного выполнения, откуда их можно будет восстановить с помощью других методов». Можно ли дать ссылку на то, что это за другие методы? RJFJR ( обсуждение ) 19:59, 7 января 2018 (UTC) [ ответить ]

Я создал перенаправление атаки по сторонним каналам Cache , чтобы помочь с этим. Кровавые подробности на самом деле находятся в разделе «Эксплойт Meltdown» . Спасибо и хвала всем, кто предоставил этот материал. Это первое место, где я увидел полное техническое описание механизма сторонних каналов, используемого Meltdown. ~ Kvng ( talk ) 18:11, 8 января 2018 (UTC) [ ответить ]

В этой статье есть ссылка на документ meltdownattack.com/meltdown.pdf, но мне еще предстоит найти программу для чтения PDF-файлов, которая могла бы правильно его отобразить. Как был отформатирован этот документ? Можно ли его перекомпоновать так, чтобы его можно было прочитать в стандартной программе просмотра PDF-файлов? — Предыдущий неподписанный комментарий, добавленный 198.2.94.117 (обсуждение) 00:06, 8 января 2018 (UTC) [ ответить ]

FWIW - PDF (например, https://meltdownattack.com/meltdown.pdf ) нормально воспроизводится на моем компьютере с dell xps8930/windows10/google chrome/adobe acrobat extension - надеюсь, это хоть как-то поможет - в любом случае - приятного просмотра! :) Drbogdan ( обсуждение ) 01:49, 8 января 2018 (UTC) [ ответить ]

Единственная проблема, с которой я столкнулся, заключалась в том, что буквы были слишком малы для того, чтобы их было легко читать. Это можно быстро исправить, нажав на кнопку +, которая увеличивает изображение, хотя и ценой того, что на экране не будет целой страницы одновременно. Вы это имели в виду? JRSpriggs ( talk ) 03:39, 8 января 2018 (UTC) [ ответить ]

Является ли уязвимость Meltdown основной угрозой для многопользовательских серверов? Является ли Meltdown практической угрозой для однопользовательских ПК в домашних условиях или в ситуациях SOHO (т. е. не в учреждениях, не на предприятиях)? Можно ли использовать Meltdown в таких системах без необходимости использования других эксплойтов для его запуска на удаленных целевых системах и сообщения о результатах злоумышленнику? — Предыдущий неподписанный комментарий, добавленный 198.2.94.11 (обсуждение)

Обсуждается потенциальная возможность использования Javascript, которая позволит посещаемой вами веб-странице читать и сообщать обо всем, что находится в памяти — недавно использованные пароли и финансовую информацию, историю просмотров и другую активность. Нет никаких признаков того, что кто-то уже создал такую ​​уязвимость, но я уверен, что они над этим работают. ~ Kvng ( talk ) 18:16, 8 января 2018 (UTC) [ ответить ]

Разве эта проблема «обнаружения паролей» не требует просеивания мегабайт оперативной памяти и нахождения короткой последовательности байтов, которая «выглядит как пароль»? Есть ли что-то в том, как пароль хранится в оперативной памяти (ОЗУ ядра или пользовательской памяти), что делает его поиск проще, чем я себе представляю? И как узнать, к чему это пароль? И как его проверить, если это пароль для входа в сканируемую систему?

Хакеры мотивированы и умны, и то, что кажется невероятным, но явно возможным, легко выполняется. Я не уверен, что именно здесь происходит, но я видел несколько таких демонстраций. ~ Kvng ( talk ) 16:30, 9 января 2018 (UTC) [ ответить ]

Вы можете подумать, что в вашей основной памяти много строк из 15 символов, но это далеко не так много, как количество возможных случайных строк из 15 символов. JRSpriggs ( обсуждение ) 21:28, 9 января 2018 (UTC) [ ответить ]

Второй абзац введения в настоящее время начинается со слов « Meltdown затрагивает широкий спектр систем. На момент раскрытия информации это включало все устройства iOS и Mac, а также ... ».

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

Не следует ли переписать введение, чтобы сосредоточиться на широком спектре затронутых устройств, прежде чем упоминать какой-либо конкретный бренд или продукт (если это вообще имеет значение)? В том виде, в котором оно сейчас написано, абзац может оставить у торопливого читателя впечатление, что Meltdown затрагивает в основном устройства iOS и Mac, что, похоже, далеко от истины.

В остальной части статьи (включая разделы «Затронутое оборудование» и «Влияние») в настоящее время не упоминаются эти продукты Apple, а также не дается четкого представления о доле конкретных потребительских товаров, на которые это влияет.

Zakinster ( обсуждение ) 16:36, 8 января 2018 (UTC) [ ответить ]

Это хороший момент, но не по тем причинам, которые вы упомянули. Редакторам нужно провести различие, что уязвимости сначала затрагивают микропроцессоры , которые затем, в свою очередь, затрагивают операционные системы, на которых они работают, и, в свою очередь, программы, которые работают на операционных системах. С двух важных точек зрения - с точки зрения безопасности и с точки зрения производительности. Кроме того, в начале есть пара грамматических ошибок.

Однако, по собственному признанию Apple, уязвимости затрагивают все их машины. Затем вам нужно провести анализ того, какой процент оборудования Apple представляет установленную базу пользователей компьютеров. В последний раз, когда я видел действительную круговую диаграмму, они были вторыми после Microsoft. Так что, по любому счету, это не «маленькое» число, как вы могли бы утверждать, но я действительно думаю, что ваши критические замечания по редактированию в целом справедливы. Хотя вам нужно признать, что это продолжающаяся и развивающаяся история, и по мере того, как мы узнаем больше, статья изменится. Тем не менее, я замечаю тенденцию, что с течением времени эта вещь становится больше и охватывает больше оборудования и становится более проблематичной как со стороны поставщика, пытающегося смягчить проблему, так и со стороны конечного пользователя, который не хочет быть уязвимым. Nodekeeper ( обсуждение ) 20:58, 8 января 2018 (UTC) [ ответ ]

Во-первых, Windows также упоминается в том же предложении. Во-вторых, я не уверен, что вы можете прочитать «затрагивают все их машины» из ссылки, использованной в лиде. Этот источник продолжает объяснять, что Apple уже выпустила некоторые смягчающие меры до раскрытия информации. Я согласен, что мы должны сосредоточиться в первую очередь на процессорах, а затем на смягчающих мерах ОС. Нам нужен новый абзац в лиде, описывающий смягчающие меры, и я предполагаю, что не будет возражений против упоминания в нем продуктов Apple :) ~ Kvng ( talk ) 21:45, 8 января 2018 (UTC) [ ответить ]

Единственное, что я возражаю против этого, так это то, что мы не получим еще один ужасный раздел Lead, как это было раньше, который внезапно занял половину страницы. Я не смог его отменить, потому что у меня закончились откаты, и мне пришлось создать шаблон, чтобы исправить это. (см. WP:LEAD ). Кстати, Apple только что выпустила еще один патч (подробности о котором пока не ясны), а патч Microsoft убивает машины AMD. Завтра, 9 января, должны были быть запланированы крупные объявления до того, как у нас появились утечки из-за патчей для ядра Linux. Похоже, это очень изменчивое новостное событие, поэтому я думаю, что нам следует подождать пару дней, может быть, выходные, прежде чем мы внесем радикальные изменения. Но в остальном я думаю, что ваши решения по редактированию идут по плану. Nodekeeper ( обсуждение ) 23:26, 8 января 2018 (UTC) [ ответить ]

Упомянутые «устройства iOS и Mac», по-видимому, представляют только ~12% и ~8% их соответствующей доли рынка: для персональных компьютеров Apple MacOS может быть второй по доле рынка ОС, но с всего лишь ~8% (после Microsoft Windows, ~89%) ^[1] , они на самом деле 5-е место в конструкторе компьютеров (после Lenovo, HP, Dell и ASUS) с долей рынка всего 7% ^[2] , и нет никаких оснований полагать, что эти 4 других основных конструктора не затронуты в равной степени. Для мобильных устройств их ОС занимает второе место с ~12% (после Android, ~88%) ^[3] , и их устройства, похоже, также занимают второе место с ~15% (после Samsung, ~21%) ^[4] . Zakinster ( обсуждение ) 08:58, 10 января 2018 (UTC) [ ответить ]

В статье говорится:

На практике, поскольку атаки по побочным каналам кэша медленные, быстрее извлекать данные по одному биту за раз (для чтения байта требуется всего 2 × 8 = 16 атак на кэш, а не 256 шагов, если бы он пытался прочитать все 8 бит сразу).

Но фактическое число атак на кэш для чтения одного байта должно быть 8, а не 16. Например, если мы попытаемся узнать значение бита 0, обратившись к ячейке 5000 + бит0, если бит равен 0, будет прочитано 5000, и когда мы измерим скорость ячейки 5000, она будет быстрой, потому что находится в кэше, однако если она медленная, нам не нужно измерять 500, потому что мы можем автоматически предположить, что если бит не равен 0, то будет равен 1. — Предыдущий неподписанный комментарий добавлен Maury91 (обсуждение • вклад ) 23:56, 9 января 2018 (UTC) [ ответить ]

Поиск ошибки в конструкции ЦП в Xbox 360 Брюсом Доусоном: в 2005 году у Брюса возникла проблема с спекулятивным выполнением ЦП во время работы над ЦП Xbox 360. «И это была проблема — предсказатель ветвлений иногда приводил к спекулятивному выполнению инструкций xdcbt, и это было так же плохо, как и их реальное выполнение». Это больше похоже на ошибку ЦП, чем на ошибку безопасности, но хорошо знать, что некоторые инженеры знали о проблемах со спекулятивным выполнением ЦП, даже если они не считали эту ошибку скрытым каналом. — Haypo (обсуждение) — Предыдущий недатированный комментарий добавлен 00:11, 10 января 2018 (UTC) [ ответить ]

Это цель, которую я получил из того, что вы написали: Meltdown — это ошибка процессора, которая также является уязвимостью безопасности. Интересно, но я не уверен, что делать с этой информацией. 134.186.234.108 ( обсуждение ) 16:30, 10 января 2018 (UTC) [ ответить ]

В 2010 году Джоанна Рутковска и Рафал Войтчук попытались атаковать спекулятивное выполнение процессора для выполнения кода в Invisible Things Lab, но «ничего не добились»:

• https://twitter.com/rootkovska/status/948997805158338560
• https://twitter.com/rootkovska/status/895954342943084544

Попытка атаки не пыталась использовать скрытый канал, но предполагала, что привилегированные инструкции будут выполнены заранее (предполагалось), и что некоторые данные могут быть украдены оттуда. Но это не так.

Не похоже, чтобы кто-то проверял спекулятивное выполнение CPU в прошлые годы. -- Haypo (обс.)

Означает ли это, что доступные в то время (2010) ЦП не были уязвимы? Было бы неплохо разобраться с уязвимостью старых ЦП, возвращающихся к версиям сокета 478/775. — Предыдущий неподписанный комментарий добавлен 198.2.94.117 (обсуждение) 14:36, 11 января 2018 (UTC)[ отвечать ]

Нет, это только указывает на то, что некоторые исследователи безопасности знали о спекулятивном исполнении и пытались его использовать. Они не пытались найти скрытый канал. -- Haypo (обсуждение) 14:54, 11 января 2018 (UTC) [ ответить ]

Бьорн Михаэльсен: Intel, по-видимому, знала об этом конкретном векторе атаки по крайней мере с 2012 года (через fefe): https://mobile.twitter.com/TheSimha/status/949361495468642304

Симха Сетхумадхаван: «Слайд из доклада, который я сделал в Intel (и во многих других местах) 6 лет назад. Доклад был посвящен инструментам и методам проектирования для обнаружения и устранения микроархитектурных побочных каналов (измерение и метод фактора уязвимости побочных каналов, а также смягчение последствий TimeWarp из ISCA12)». https://mobile.twitter.com/TheSimha/status/949361495468642304

• http://www.cs.columbia.edu/~simha/preprint_isca12_svf.pdf
• http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf

-- Haypo (обсуждение) — Предыдущий недатированный комментарий добавлен 01:44, 10 января 2018 (UTC) [ ответить ]

Как мы пришли к #Spectre и #Meltdown. Хронология: https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP

-- Haypo (обсуждение) — Предыдущий недатированный комментарий добавлен 01:48, 10 января 2018 (UTC) [ ответить ]

Страница загрузки

Может быть, кто-то будет так любезен и отразит это в статье? :) На данный момент мне не известно о каких-либо обновлениях, специально предназначенных для других операционных систем.-- Tactica ( обсуждение ) 10:14, 11 января 2018 (UTC) [ ответ ]

Там много чего можно почитать, и механизм, кажется, не такой уж и сложный. Я могу что-то упустить. Вот мое понимание после прочтения:

• Вредоносный процесс хочет получить значение (X) по адресу W, к которому у него не должно быть доступа.
• Процесс сообщает ЦП о необходимости получить значение по адресу Y+(значение по адресу W) (косвенная адресация), где Y — произвольный базовый адрес.
• Процессор извлекает Y+X, проверяя при этом привилегии для него (это сохраняет значение в кэше для Y+X).
• Затем запросы выполняются напрямую для Y+Z, где Z — это все возможные значения X (этот диапазон определяется размером X).
• Если запрос выполняется быстрее, то он был кэширован, и мы знаем, что X = Z. (Вот тут-то и вступает в силу синхронизация кэша).
• Фактически мы извлекли значение из W (хотя оно было привилегированным)
• Этот процесс можно повторить для других значений W (но с использованием другого Y, чтобы оно случайно не попало в кэш).

Кажется, это правильно? Если нет, то можно было бы что-то добавить в раздел, чтобы прояснить то, что я неправильно понял.

Также было бы неплохо получить какое-то объяснение, как это состояние RACE. Насколько я вижу, оба события, создаваемые планировщиком, происходят, не мешая друг другу.

Спасибо! — Предыдущий неподписанный комментарий добавлен Snydergd ( обсуждение • вклад ) 13:33, 15 января 2018 (UTC) [ ответить ]

Я согласен, что раздел «Механизм» — разговорный, и это обычно не одобряется. Вы изложили его, но, по-моему, слишком агрессивно, поэтому я не думаю, что понял бы ваше резюме, если бы сначала не прочитал весь раздел «Механизм». Кроме того, ваше описание тяготеет к WP:HOWTO , что обычно не одобряется. Я думаю, что лучше всего попытаться провести редактирование существующего материала. Если это слишком сложно или не улучшит ситуацию существенно, то пришло время рассмотреть переписывание. ~ Kvng ( обсуждение ) 16:50, 15 января 2018 (UTC) [ ответить ]

В подразделе Обзор :

... поскольку в семействе микропроцессоров, используемых в этих компьютерах, практически нет различий...

Что это значит? О каком семействе микропроцессоров идет речь (или это может быть "... семейства микропроцессоров...")? Изменение в чем?

-- Мортенс ( обсуждение ) 14:51, 15 января 2018 (UTC) [ ответить ]

Вздох, еще одна так называемая уязвимость безопасности была полностью раздута. — Предыдущий неподписанный комментарий добавлен 218.103.26.1 (обсуждение) 03:39, 17 января 2018 (UTC) [ ответить ]

это шутка о спекулятивном исполнении ? ~ Kvng ( обсуждение ) 15:22, 20 января 2018 (UTC) [ ответить ]

Даты были в 3 разных форматах. Я сделал их все ДМГ[8], а Дрбогдан откатился[9], снова сделав их 3 разными форматами. Я думаю, нам следует использовать ДМГ, потому что эта статья представляет международный интерес. По крайней мере, они должны быть согласованы на протяжении всей статьи. —DIYeditor ( обсуждение ) 21:16, 18 января 2018 (UTC) [ ответить ]

MOS :DATERET, нам следует сохранить первый стиль даты, используемый в статье, который, по-видимому, DMY[10]. До этого в ссылках встречались даты YMD с дефисом, но это не один из двух вариантов написания даты в тексте статьи. —DIYeditor ( обсуждение ) 21:22, 18 января 2018 (UTC) [ ответить ]

@ DIYeditor : Да - согласен - пожалуйста, поймите, что у меня нет никаких проблем с используемым форматом датировки - кажется, оригинальный шаблон "MDY" (т. е. {{use mdy dating|date=January 2018}}) был добавлен "08:31, 4 января 2018" - в то время все справочные даты были скорректированы, чтобы "соответствовать этому формату" - однако - все это можно было скорректировать/обновить до любого формата, который вам нравится, конечно - в любом случае - Наслаждайтесь! :) Drbogdan ( talk ) 21:45, 18 января 2018 (UTC) [ ответить ]

Не имеет большого значения, если это последовательно. Давайте подождем и посмотрим, есть ли у кого-нибудь еще мнение. —DIYeditor ( обсуждение ) 00:05, 19 января 2018 (UTC) [ ответить ]

@ DIYeditor :  Готово - обновлены/скорректированы все даты в соответствии с изначально отмеченным шаблоном "MDY" - конечно, всегда можно скорректировать на другой формат даты - но все справочные даты теперь имеют один формат - по крайней мере, на данный момент afaik - в любом случае - Наслаждайтесь! :) Drbogdan ( обсуждение ) 19:31, 26 января 2018 (UTC) [ ответить ]

 Сделано @ DIYeditor : FWIW - обновлены все даты в основной статье " Meltdown (уязвимость безопасности) " в конце концов в формат "DMY" - кажется лучше - в любом случае - Наслаждайтесь! :) Drbogdan ( обсуждение ) 13:27, 4 июня 2019 (UTC) [ ответ ]

Ясно, но технично. Не журналистская болтовня. Не куча ненужных деталей. В нем нет ссылок, но сделано хорошо. Спасибо. Tuntable ( обсуждение ) 23:57, 22 января 2018 (UTC) [ ответить ]

Первоначальное заявление Intel о том, что затронуты все процессоры, не является неверным, поскольку (умно) Intel не разделяла Meltdown и Spectre, а говорила обо всех обнаруженных проблемах безопасности, объединяя Meltdown и Spectre в одном предложении. Возможно, предложение можно перефразировать, чтобы лучше это отразить.-- Denniss ( talk ) 12:53, 20 марта 2018 (UTC) [ ответить ]

Не смешно, см. [11]. Сомон с лучшими языковыми навыками, пожалуйста, включите в статью как побочный эффект. -- Деннис ( обсуждение ) 16:49, 28 марта 2018 (UTC) [ ответить ]

Статья здесь кажется чрезмерно неточной и немного паникерской. Начальное утверждение " Это позволяет мошенническому процессу читать всю память, даже если он не имеет на это полномочий. " не подтверждается исследованиями. AlsoMostlyHarmless ( обсуждение ) 16:25, 30 марта 2018 (UTC) [ ответ ]

Если у вас есть ссылка на надежный источник, которая противоречит многочисленным надежным утверждениям в статье, которые не подтверждают то, что вы утверждаете, обязательно добавьте эту информацию. Anastrophe ( обсуждение ) 01:18, 1 апреля 2018 (UTC) [ ответить ]

Вступление к статье гласит: «большинство интеллектуальных устройств и встраиваемых устройств используют процессоры на базе ARM (мобильные устройства, смарт-телевизоры, принтеры и другие), включая широкий спектр сетевого оборудования». Я считаю, что это утверждение трудно оправдать. На момент объявления единственным ядром ЦП от ARM ltd, которое было уязвимо к Meltdown, был A75, и не так много устройств (если таковые вообще были) были в поле с этим ядром. Я понимаю, что Apple и другие производят свои собственные ядра ARM. Вышеприведенное утверждение может быть применимо или не применимо к iPhone или AppleTV; я не знаю. Однако рынок, описанный в заявлении, намного больше, чем просто продукты Apple. Такое общее утверждение должно быть обосновано цитатой. Я считаю, что подавляющее большинство телефонов Android, смарт-телевизоров, принтеров, маршрутизаторов и т. д. не были подвержены Meltdown.

Обратите внимание, что эта статья о Meltdown, а не о Spectre. Также не следует забывать, что уязвимость «3A», опубликованная ARM, не является Meltdown, как описано в этой статье. Уязвимость 3A позволяет вам считывать значение регистра управления, а не памяти, и ARM не рекомендует никаких мер по ее смягчению. Пожалуйста, прочтите информацию об ARM, уже приведенную в этой статье. WmMills (обсуждение) 15:15, 29 сентября 2018 (UTC) [ ответить ]

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

В оригинальной статье Meltdown атака Flush+Reload упоминается как пример извлечения данных из кэша, но эта техника зависит от того, что другой процесс одновременно манипулирует этими данными весьма специфическим образом. Это ни в коем случае не универсальный механизм «прочитать все, что есть в кэше».

В статье Meltdown утверждается, что можно прочитать любое значение с запрещенного адреса, но это утверждение вводит в заблуждение. Хотя данные с запрещенного адреса памяти были считаны в кэш (когда не должны), они остаются недоступными для злоумышленника, если только не используется другой механизм для их извлечения. Это должно быть ясно указано в описании эксплойта. — Предыдущий неподписанный комментарий добавлен LukMF (обсуждение • contribs ) 10:24, 8 марта 2021 (UTC) [ ответить ]

Перенаправление Meltdown (уязвимость безопасности) было указано в перенаправлениях для обсуждения , чтобы определить, соответствует ли его использование и функционирование правилам перенаправления . Читатели этой страницы могут прокомментировать это перенаправление в Wikipedia:Redirects for discussion/Log/2024 3 марта § Meltdown (уязвимость безопасности) до тех пор, пока не будет достигнут консенсус. Utopes _{( обсуждение / продолжение )} 18:17, 3 марта 2024 (UTC) [ ответить ]

в части «фон», где объясняется, как компьютер распределяет свою оперативную память, мне кажется, это можно было бы сформулировать лучше, потому что в настоящее время там говорится, что что-то «сопутствует» памяти компьютера, но я не уверен, как это можно сформулировать лучше - какой-то скучающий ребенок в школе 21:25, 2 апреля 2024 (UTC) [ ответить ]

Я не вижу слова «сожительство» нигде в статье...? ура. anastrophe , он редактор. 23:45, 2 апреля 2024 (UTC) [ ответить ]

я забыл поставить тире между co и habit, в статье пишется "co-habit" - какой-то скучающий ребенок в школе 00:19, 3 апреля 2024 (UTC) [ ответить ]

Спасибо. Я попробую поработать над этим позже, во всем этом полно эмоциональных формулировок, например, «каждому процессу дается впечатление» и тому подобное. Это следует характеризовать как аналогию, а не как голую. Ура. anastrophe , он редактор. 01:15, 3 апреля 2024 (UTC) [ ответить ]

На самом деле, это осиное гнездо недостатков, которое быстро поглотит все мое время, и сделает это неэффективно, поскольку я не эксперт по предметной области. Мне придется предоставить другим возможность прояснить формулировку. Ура. anastrophe , он редактор. 04:48, 3 апреля 2024 (UTC) [ ответить ]