Стандарт Thunderbolt 3 описывает передачу данных на скорости 40 Гб/с. (2х по сравнению с Т2). Вы хотите сказать, что каждая новая версия контроллера должна по 5% к стандарту добавлять? Если разрешить такое, например, с USB, то уже бы закончились буквы и цифры для обозначения версий.
И не мудрено. Thunderbolt был разработан Интелом по инициативе (читай по заказу) Эппл и на данный момент не является бесплатным (требуется лицензирование). В 2018 Интел обещает сделать этот интерфейс бесплатным, тогда, возможно, он получит более широкое распространение.
Вообще Гугловский «security team» работает не ради «хайпа». Вот, например, сколько вони было из-за уязвимости в Интеловском ME о которой раструбила некая российская компания. Эту уязвимость и уязвимостью назвать трудно, так как требует физически доступ к компьютеру. С другой стороны, 90 дней назад, Гугл нашёл уязвимость в AMD PSP (аналог Intel ME), котороя куда более критична, так как позволяет «remote execution», тихо сообщил об этом AMD. AMD, тоже, тихо, выпустили заплатку. По прошествии 90 дней Гугл опубликовал эту информацию на мало кому известном сайте (без лишенго шума). Так это и должно работать.http://seclists.org/fulldisclosure/2018/Jan/12
Интел не будет засуживать «этих отморозков». Вообщето, Интелу выгоднее что бы такие дыры находили «эти отморозки», а не кто нибудь с несовсем «чистыми» намерениями…Цитата:https://spectreattack.com/spectre.pdf
We would like to thank Intel for their professional handling of this issue through communicating a clear timeline and connecting all involved researchers. We would also thank ARM, Qualcomm, and other vendors for their fast response upon disclosing the issue.
Не правильно понимаете. Панику подняли из-за пары тройки специфических синтетических тестов на неоптимизированных патчах. Патчи подправили, оптимизировали и сейчас те же тесты уже не показывают такую разницу с KPTI и без. В большинстве случаев — в пределах погрешности. Это в синтетике, на практике разница вообще не заметна.
phoronix.com в помощь.
Можно, конечно, прятать голову в песок, утверждать, что нас это не касается и спустить все на «авось». Не самый действенный метод решать проблемы. Это хорошо поняли в ARM. К сожалению, в меньшей степени в АМД.
Закончилось дело большим «хайпом». Но, тем не менее, это надо было сделать. И хорошо, что Гугл, а не какой нибудь талантливый хакер. Впрочем, исследованиями занималась не только Гугл. В авторстве подписалась куча народу — это те кого мы знаем. А те, кого мы не знаем...?
Experiments were performed on multiple x86 processorarchitectures, including Intel Ivy Bridge (i7-3630QM),Intel Haswell (i7-4650U), Intel Skylake (unspecifiedXeon on Google Cloud), and AMD Ryzen. The Spectrevulnerability was observed on all of these CPUs. Similarresults were observed on both 32- and 64-bit modes, andboth Linux and Windows.
We have empirically verified the vulnera-bility of several Intel processors to Spectre attacks, in-cluding Ivy Bridge, Haswell and Skylake based proces-sors. We have also verified the attack’s applicabilityto AMD Ryzen CPUs. Finally, we have also success-fully mounted Spectre attacks on several Samsung andQualcomm processors (which use an ARM architecture)found in popular mobile phones.
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.
То ли авторы не достаточно компетентны, то ли АМД лукавит. Впрочем, ARM уже заявила, что для их CPU существует вектор атаки, использующий данную уязвимость (они называют это 3b).
В новых исследованиях обнаружилось, что разница в производительности (в том же Redis например) между разными версиями kernel гораздо более существенна чем от влючения/выключения KPTI.Here
Справедливости ради, PoC для ARM тоже никто не демонстрировал, глубоко ковыряли только интелловские процессоры. Что не помешало ARM пойти дальше и самим заявить об уязвимости перед meltdown. Я не утверждаю что эту уязвимость можно воспроизвести на процессорах AMD, но и не удивлюсь когда все эти патчи потихоньку, без лишнего шума, в будущем «проэнаблят» и для процессоров AMD.
Забавно — Линус Товальдс рассердился на Интел, посоветовав всем перейти на процессоры ARM. Всего через несколько часов ARM признало, что их самые высокопроизводительные процессоры (А15, А57, А72, А75) подвержены всем трём типам атак. АМД пока что упирается, утверждая о «near zero chance», но это не «статистический баг». Либо уязвимость есть, либо её нет.
Никак. В новости же сказано — архитектура PIM (process in memory). Данные не гоняют туда-сюда по USB, они уже находятся в каждом из 28к «ядер». По usb пересылается только команда произвести вычисления. Проблема появляется когда локальность ваших данных больше 28к. С другой стороны интелловский Movidius реализует обычную фон-нэймовскую архитектуру, но и там не особо гоняются данные по USB — спасибо 4 Gb кэша на стике.
Ну если такое говорить после каждой заявы на лидерство от очередного, никому не известного стартапа… Может Интелу вообще закрыться? Вообще, судя по описанию этого чипа, там закос на архитектуру PIM, что, скорее всего, просто нагромождение 28K не связанных между собой, управляемых программно, векторных ядер.
Полагаю объяснение от Эппл вы не читали? Я не являюсь поклонником Эппл, но, имхо, компания поступила весьма логично. К сожалению, «техническое обоснование» практически осталось «за кадром», а оно весьма информативно. Мало кто помнит что у аккумуляторов, кроме параметра «capacity» есть ещё параметр «capability» который характеризует макс. мощность которую может отдавать батарея. У деградировавших батарей ухудшается не только «capacity», но и «capability», в результате чего батарея может не «потянуть» процессор выполняющий «тяжёлую» задачу. Тут надо отметить, что Эппл не уменьшает производительность, ограничивая энергопотребление, на всех старых аппаратах поголовно, а только на тех, где процессор детектит падение напряжения батареи. Можно поругать Эппл за то, что софт не предупреждает юзера об изношенности батареи, но ведь и андроид (Самсунг, Мото, ЛЖ, итд.) этого не делает.
Эппл может и не слышала (не знаю — у меня никогда не было продукции Эппл и, скорее всего, не будет) но для Samsung/LG «репутация» тоже не более, чем пустой звук, учитывая, что обе уже попадались на читерствe с бенчмарками в прошлом. Короче, фанаты могут продолжать свои битвы Apple vs Samsung, Китай vs Бренд итд. Но по факту — они все одного поля яблочки…
phoronix.com в помощь.
То ли авторы не достаточно компетентны, то ли АМД лукавит. Впрочем, ARM уже заявила, что для их CPU существует вектор атаки, использующий данную уязвимость (они называют это 3b).