Comments 214
Ощущение, что за счет таких вот "дырок" Интел и наращивал производительность последние годы.
Как я понял это вообще коситься только хостеров впсок, а для обычных юзеров все по прежнему, если дал исполнить вредоносный код у себя, то тебе кранты не зависимо от наличия этих уязвимостей в процессоре.
Насчёт определения вредоносности — мне не кажется, что задача выявления кода, эксплуатирующего на JS эту уязвимость, настолько сложна. Есть же примерный тестовый фрагмент. Понятно, как он работает (что делает и в какой последовательности). Да, есть обфускаторы. Ну так и что? Во-первых, они больше против анализа кода человеком работают, чем против анализа алгоритмом (алгоритму пофигу на имена, отступы, перестановку независимых блоков местами). А во-вторых, если точно непонятно, «хороший» перед нами код или «плохой» — можно всё равно показывать красное предупреждение перед исполнением скрипта и показом страницы, и просить пользователя нажать на ссылку вида «Я понимаю риск, продолжить», даже если код безобидный, а просто сильно обфусцирован. Не все сайты будут такому рады, зато безопасность :)
retrieve running apps
read sensitive log data
Это для антивирусника встроенного же
approximate location (network-based)
precise location (GPS and network-based)
Это для отображения ближайших банкоматов на карте
read your text messages (SMS or MMS)
receive text messages (SMS)
Это теоретически можно объяснить желанием избавить пользователя от ввода СМС-кода подтверждения вручную (когда в самом начале регаешь аккаунт, там надо ввести код, присланный банком в смс, точно так же работает Viber вроде, тоже ловит код автоматически).
Контакты — наверное для каких-то опций шеринга (типа, рассказать о приложении друзьям).
Вот зачем ему доступ к камере и микрофону — я без понятия…
Сколько антивирусов вы написали? Или хотя бы сигнатур?
Ни одного. А к чему этот аргумент? Я не сказал, что я напишу. Но спецы напишут без проблем. Там же идея простая, как пробка, извините меня…
Контакты — наверное для каких-то опций шеринга
Доступ к контактам нужен для отправки денег. Там есть опция послать деньги клиенту сбера по номеру телефона. Этот номер телефона можно искать в адресной книге.
В моём телефоне Sony Ericsson QR-сканер был предустановлен как небольшое отдельное приложение сторонней компании, которое можно было при желании удалить. Но когда всё встроено в банк-клиент — оно пошустрее будет, чем через интенты.
мне не кажется, что задача выявления кода, эксплуатирующего на JS эту уязвимость, настолько сложна.
Вот зачем ему доступ к камере и микрофону — я без понятия…Там внутри звонилка в банк через сеть, для клиентов за рубежом. Я в РБ съехал из РФ, поэтому сталкивался.
Ждём «производительность падает в два раза каждые 18 месяцев из-за новых патчей на дыры».
Тогда и закон Мура снова начнет работать в правильном направлении. :)
надо лишить пользователя права исполнять нативный код в принципе
Насколько я помню, атаки типа Meltdown и Spectre вполне себе успешно выполняются на Javascript в браузере. Так что запрещение нативного кода ничего не меняет.
JVM на уровне ядра ОС, и виртуальная песочница для пользовательских программ. :)
Так ведь когда то и хотели сделать процессоры с системой команд, основанной на Java- и .NET/IL-байткоде, а также первоначально ожидалось, что проект Longhorn будет включать как раз виртуальную JIT-машину .NET на уровне ядра, а WinAPI будет эмулироваться (а ведь были еще проекты Sing# и Singularity OS).
Но потом что-то пошло не так..
Тогда что принципиально изменится? Злоумышленники будут искать способ заставить эту виртуальную машину выполнить то, что она выполнять не должна (или не должна в конкретных условиях). Просто ещё одна прослойка появляется, внутри которой можно концентрировать какую-то логику по защите пользователя от вредоносных действий.
Тогда что принципиально изменится?
Код будет исполняться под контролем VM, которая не обязана эмулировать проблемное поведение процессора.
Злоумышленники будут искать способ заставить эту виртуальную машину выполнить то, что она выполнять не должна
Это будет уже другая проблема, которую, к стати, решить и проще, и быстрее.
> решить и проще, и быстрее
Не всегда, живущие годами уязвимости в софте это доказывают. Тем более можно взять просто компьютер постарше — будет в разы быстрее VM с интерпретацией исполнением.
Она может иметь свои уязвимости, она будет в разы медленнее
Я слышал, что заплатки тоже сильно присаживают производительность (сам их не использовал). Вопрос, что хуже, лекарство или болезнь.
можно взять просто компьютер постарше — будет в разы быстрее VM с интерпретацией исполнением.
Спорное утверждение. Как я понял, уязвимость присутствует в процессоре давно, раньше просто ни кому в голову не приходило их поискать. Да и задача стоит не в полной эмуляции всего компьютера, а контолируемого исполнения кода процессором.
> уязвимость присутствует в процессоре давно
Не ранее внеочередного исполнения, VM будет не быстрее тех (если исполняется на современных, которые с уязвимостью).
Если VM будет написана не на java, а способ и глубина ее интеграции в ОС тщательно продумана, то падение производительности может оказаться не столь заметным.
Ядра для ОС можно сильно упростить и ускорить за счет того, что не нужна быстрая арифметика с плавающей точкой, не требуется бОльшая часть возможностей по обработке аудио и видео, не требуется поддержка SIMD. На сэкономленных транзисторах можно сделать гигантский кэш первого уровня, чтобы все ядро ОС туда поместилось.
Сейчас управляемые приложения работают через доп. прослойку, а традиционные работают нативно.
А было бы наоборот, при этом традиционные приложения перешли бы в разряд легаси, и постепенно выбыли бы из эксплуатации.
Предполагалось, что при этом управляемые приложения стали бы работать более безопасно.
в целом идея с виртуализацией «традиционных » приложений ясна.
Здесь скорее, речь шла о выполнении традиционных приложений в режиме эмуляции, как это было сделано для выполнения DOS-приложений в Windows-среде, чем о виртуализации.
Чем управляемые приложения качественно лучше традиционных? В традиционных — за исполнение отвечает процессор, в вашем сценарии — виртуальная машина, которая неким образом общается с процессором. При этом процессоры останутся те же (или почти те же), в них всё равно будут какие-то уязвимости, вопрос в масштабах. И виртуальная машина ещё своих сверху добавит :)
Как раз сейчас выполнение управляемых приложений и происходит так, как вы описали — процессор со своими уязвимостями, ОС со своими, и прикрученная к ОС виртуальная машина со своими (плюс тот момент, что она именно "прикручена" фактически как сторонее приложение, что в свою очередь снижает надежность).
В итоге что получаем — плюсы управляемого байт-кода во многом нивелируются вышеописанным.
А когда был хайп в момент появления Java и .NET, была куча статей и обещаний, что вот-вот появятся процессоры, которые могут исполнять управляемый байт-код Java или IL.
(Да вроде бы даже и были уже Java-процессоры, а на стороне .NET были Singularity OS и Sing#)
Тогда виртуальная машина в ОС смогла бы стать более "нативной", реальной частью ОС, если и вовсе не ее ядра, и при этом стать более компактной, отвечать, например, только за сборку мусора, т.к. байт код исполнялся бы процессором, и JIT-компилятор тоже не потребовался бы.
Плюсы достаточно очевидны — управляемый код выполняется в железе "нативно", а на стороне ОС минимизируется количество прослоек.
Я в целом пару раз с машинными кодами сталкивался. Сдаётся мне, что там не так много разного у этих концепций. Те же байты, отвечающие за команды, указатели, данные, которые лежат по указанным смещениям… Чем байт-коды устроены иначе? Как там с хранением данных обстоит? Есть ли работа со смещениями для получения доступа к следующей нужной команде?
Основное отличие в том, что байт-коды виртуальной машины это ограниченный набор высокоуровневых кодов (.NET IL, Java byte code), которые почти 1-в-1 соответствуют высокоуровнему языку (C#, Java).
Например, есть в .NET фильтры исключений на уровне IL.
Когда мы на C# пишем так (when):
try
{
// Foo
}
catch (Exception ex) when (SomeCondition)
{
// Handling
}
Понятно, что в современных процессоров таких "байт-кодов" нет, и современные JIT переводят эти байт-коды низкоуровневые процессорные системы команд.
И идея была в том, чтобы система команд процессора была именно такой высокоуровневой, а остальное (что сейчас делает программный JIT) — под аппаратным капотом.
Процессору нужно будет: сходить за указателем на объект; сходить за классом объекта (другой указатель); распарсить структуру класса, найдя мапу список методов -> их тела; если нет в этой структуре, пойти перебирать предков, причём, возможно, по нескольким путям (везде сейчас есть множественное наследование, даже если все кроме одного предка это интерфейсы). Искать в мапе по совпадению строк — перебирать посимвольно; сама мапа это несколько структур данных внутри… Проблемы:
1. Мы зашиваем сложный алгоритм в процессор. И более простые алгоритмы (например, поиск виртуальной страницы) часто делаются на микрокоде, а не вшиты на уровне ASIC.
2. Может оказаться, что выгоднее чуть переделать участвующие структуры. Новые открытия идут постоянно: например, тема последних лет 5 это что мапы (словари, хэш-таблицы — как ни называй) с упорядочением ключей в порядке вставления стали дешёвыми, а так как они интуитивно понятнее большинству программистов, их вводят везде (во всех реализациях Javascript уже давно, а сейчас и в стандарте ES; в Python начиная с 3.6; и так далее). Или, реализации closed-addressing типичнее, но сейчас есть очень эффективные open-addressing. Поменять алгоритм в VM — банально. Поменять в железном процессоре — зверски сложно и дорого, в x86 до сих пор торчат хаки от первых 8086, если не 8080.
Вы можете сказать, что это делать так вообще не нужно — вызов по имени это особый случай, а основной вариант это по фиксированному смещению в VMT. Да, это так. Но тогда и закодировать это в команду обычного процессора проще простого, а для вызова по имени можно написать call в процедуру VM. Так и делают на практике…
в x86 до сих пор торчат хаки от первых 8086, если не 8080.
Ого. Я б почитал про такое, интересно.
Навскидку:
- Структура команд не менялась с 16-битного режима, один переход (16->32) был бездарно протерян Intelʼом, второй (32->64) — AMD. По первым байтам невозможно предсказать длину команды, соответственно, декодер чудовищно усложнён и ловит множество частных случаев типа «тут добавлен SIL байт, который надо разобрать, чтобы понять длину константы смещения».
- Там же, осталось множество однобайтных команд, которые ничего не потеряли бы, даже если бы их сделали 4-байтными (HLT, CMC, IN, OUT, ENTER, LEAVE, и ещё десяток других). Зато для новых добавлений типа AVX вынуждены строить VEX и EVEX префиксы, выискивая дыры в кодировках (VEX вставлен в недопустимые варианты для LDS и LES, и занимает два лишних байта на каждую команду).
- Устаревший формат команд DIV, IDIV. «Косая» версия этих команд (делимое длины 2*N при делителе, частном и остатке длины N) перестала быть ценной с момента, когда стало понятно, что умножение значительно быстрее деления, и любое деление больше 1 раза на один и тот же делитель стараются делать через обратное умножение. В результате мало того, что регистры фиксированы (и нужно переименование регистров, чтобы это не портило производительность алгоритмов), так и всякий раз нужно заливать старшую часть расширением младшей. Для сравнения, в RISC (включая такой полу-RISC, как ARM) этого раритета уже нет, делимое той же длины. Также можно было бы сэкономить на генерации остатка (как в AArch64 — кому он нужен, добудет через обратное умножение).
- Стек в FPU, который требует спец-хаков от всех компиляторов. (Тут частично смягчено тем, что само FPU сочтено устаревшим начиная с введения SSE2.)
- Команды RCL, RCR никому не нужны при смещении больше чем на 1 бит (разрешённом в 186/286). Они вообще-то и для 1 бита не нужны сейчас (все их задачи успешно покрыты через SHLD и SHRD), но уже во времена перед 386 было ясно, что их расширение на несколько бит бессмысленно. Сейчас они возникают только в ручном коде. Но в x86-64 они занимают такое же почётное место, как и полезные варианты сдвигов.
- XCHG, аналогично, используется только в ручном коде. Ладно 80386 в 1985-м, там ещё не было ясно, что происходит (SSA был опубликован, кажется, в 1987, а в компиляторы массово пошёл уже в 90-х), но в x86-64 переносить её как что-то ценное уже не было никакого смысла. Даже просто освободить однобайтный код для чего-то другого — уже было бы полезно.
- Бит OF вынесли в 8086 в старший байт Flags (16-битного), при том, что в младшем получилось 2 неиспользуемых бита (сейчас всегда константы). В результате LAHF/SAHF не работают с ним, а передачу соответствующего сигнала из FPU делают через бит PF. Причём, даже в 32 битах эти биты не «отпустили» на волю — можно было бы использовать, например, для детекта поддержки CPUID, вместо нового бита
- Бит PF по-прежнему получает чётность результата основных команд (в смысле количества бит), при том, что нужен 0.000001% применений. Уже в 32-битке можно было сделать, что он ставится в признак чётности только в каком-нибудь TST, а для остальных команд найти ему применение получше (да хоть аналог OF, см. предыдущий пункт).
- Сегментная адресация, которая должна быть настроена даже в x86-64, хотя там от неё используются только хвосты рожек и одно копыто ножек. Применить сегменты в качестве ссылок на страничные таблицы (как это сделано в Power и zSeries) означало бы заметно удешевить виртуализацию. Нет, сохраняются странные атавизмы.
- Работа с портами ввода-вывода — такое впечатление, что её специально замедляют. Сделать вместо in eax,dx возможность in eax,[dx+offset] — даже такая мелочь радикально бы упростила типичный код I/O.
Это только пятая часть, наверно, — только то, что на самом виду, от тех решений, что делались в ранние времена и не устраняются. Есть множество других более поздних нелепостей, которые просто изумляют (цензурно говоря), но не так фатально мешают, но я и так много написал. Реализация результата у Intel+AMD, наверно, весьма неплоха (раз они до сих пор близки к первому месту), но именно архитекторы… я не знаю, кем надо быть, чтобы смотреть даже не на шаг, а на полшага вперёд, и каждый следующий шаг делать в несовместимом направлении.
А здесь получается нужна высокая квалификация разработчика, программа получается дорогая, а средства защиты при массовом исполнении ее выловят мгновенно. И тогда смысл?
Возможно только для хитро целевых атак.
Ну от них патчи уже стоят :)
Только от Meltdown. От Spectre патчей не существует.
Зато вот есть очень надежный патч от Meltdown — называется «смени процессор на AMD» :)
Вспомните Эдиссона и его историю с лампочкой. Не каждый сможет 10тыс раз проводить эксперимент с подбором материалов для нити накаливания. А к тому времени уличное освещение (газовое) уже существовало. Он довел это дело до ума.
И хоть разработка cpu кажется вам невозможной (нерентабельной), в перспективе, при помощи сообщества, ситуация может измениться.
А тут вам надо взять лампу накаливания, и улучшить её КПД, возможно вам понадобится 10 милионов опытов, чтобы добиться этого. Это вполне возможно, но потом вам надо будет ещё найти фабрику которая сможет из вашего материала делать лампочки, и при этом конкурировать с теми кто их делает уже давно.
Сказать что это невозмножно будет неправильным, сказать что трудно исполнимым да. Помните конкуренты Intel/AMD/ARM на месте не сидят, и дыры закроют которые уже нашли.
Сделать надежный проц для себя, если главная цель надежный то это реально(386 для FPGA вроде кто то уже делал). Другое дело и быстрый и надежный это уже совсем другое дело, иначе бы их делали не только AMD/Intel а например ещё и VIA делала что то конкурентное опыт у них есть но вот не делают.
PS. Хотя я думаю найдётся много людей который при финансировании готовы этим заниматься пока финансирование не закончится.
В 1877 году русский морской офицер А. Н. Хотинский принимал в Америке крейсеры, строящиеся по заказу России. Он посетил лабораторию Эдисона и передал ему лампу накаливания А. Н. Лодыгина и «свечу Яблочкова» со схемой дробления света. Эдисон внёс некоторые усовершенствования и в ноябре 1879 года получил на них патент как на свои изобретения. Яблочков выступил в печати против американцев, заявив, что Томас Эдисон украл у русских не только их мысли и идеи, но и их изобретения. Профессор В. Н. Чиколев писал тогда, что способ Эдисона не нов и обновления его ничтожны.
Яблочков, Павел Николаевич
Смысл патента Эдисона — не платить за патенты Европе.
Description
The ao486 is an x86 compatible Verilog core implementing all features of a 486 SX. The core was modeled and tested based on the Bochs software x86 implementation. Together with the 486 core, the ao486 project also contains a SoC capable of booting the Linux kernel version 3.13 and Microsoft Windows 95.
Current status
31 March 2014 — initial version 1.0.
19 August 2014 — driver_sd update, ps2 fix.
Features
The ao486 processor model has the following features:
pipeline architecture with 4 main stages: decode, read, execute and write,
all 486 instructions are implemented, together with CPUID,
16 kB instruction cache,
16 kB write-back data cache,
TLB for 32 entries,
Altera Avalon interfaces for memory and io access.
The ao486 SoC consists of the following components:
ao486 processor,
IDE hard drive that redirects to a HDL SD card driver,
floppy controller that also redirects to the SD card driver,
8259 PIC,
8237 DMA,
Sound Blaster 2.0 with DSP and OPL2 (FM synthesis not fully working). Sound output redirected to a WM8731 audio codec,
8254 PIT,
8042 keyboard and mouse controller,
RTC
standard VGA.
All components are modeled as Altera Qsys components. Altera Qsys connects all parts together, and supplies the SDRAM controller.
The ao486 project is currently only running on the Terasic DE2-115 board.
Производительность
CPU benchmarks
The package DosTests.zip from www.roylongbottom.org.uk/dhrystone%20results.htm was used to benchmark the ao486.
Test Result
Dhryston 1 Benchmark Non-Optimised 1.00 VAX MIPS
Dhryston 1 Benchmark Optimised 4.58 VAX MIPS
Dhryston 2 Benchmark Non-Optimised 1.01 VAX MIPS
Dhryston 2 Benchmark Optimised 3.84 VAX MIPS
Running software
The ao486 successfuly runs the following software:
Microsoft MS-DOS version 6.22,
Microsoft Windows for Workgroups 3.11,
Microsoft Windows 95,
Linux 3.13.1.
Для сравнения результаты тестов производительности моего нетбука
********************************************************
Dhrystone Benchmark Version 1.1 Non-optimised via C/C++ Thu Aug 16 00:57:44 2018
VAX MIPS rating: 487.87
Correct result
Windows NT Version 5.1, build 2600, Service Pack 3
CPU GenuineIntel, Features Code BFE9FBFF, Model Code 000106CA, 1662 MHz
Memory 2085916 KB, Free 150620 KB
********************************************************
Dhrystone Benchmark Version 1.1 Optimised via C/C++ Thu Aug 16 00:57:50 2018
VAX MIPS rating: 1664.16
Correct result
Windows NT Version 5.1, build 2600, Service Pack 3
CPU GenuineIntel, Features Code BFE9FBFF, Model Code 000106CA, 1662 MHz
Memory 2085916 KB, Free 148908 KB
********************************************************
Dhrystone Benchmark Version 2.1 Non-optimised via C/C++ Thu Aug 16 00:57:57 2018
VAX MIPS rating: 548.52
Classic Benchmark Ratings for CPUSpeed.txt where 100 MHz Pentium = 100
Integer Dhry2 NoOpt 1714
Numeric results were correct
Windows NT Version 5.1, build 2600, Service Pack 3
CPU GenuineIntel, Features Code BFE9FBFF, Model Code 000106CA, 1662 MHz
Memory 2085916 KB, Free 150168 KB
********************************************************
Dhrystone Benchmark Version 2.1 Optimised via C/C++ Thu Aug 16 00:58:04 2018
VAX MIPS rating: 1224.27
Classic Benchmark Ratings for CPUSpeed.txt where 100 MHz Pentium = 100
Integer Dhry2 Opt 941
Numeric results were correct
Windows NT Version 5.1, build 2600, Service Pack 3
CPU GenuineIntel, Features Code BFE9FBFF, Model Code 000106CA, 1662 MHz
Memory 2085916 KB, Free 141232 KB
а честное сравнение производительности вы найдете тут
Dhry1 Dhry1 Dhry2 Dhry2
Opt NoOpt Opt NoOpt
VAX VAX VAX VAX
CPU MHz MIPS MIPS MIPS MIPS
AMD 80386 40 17.5 4.32 13.7 4.53
IBM 486D2 50 26.6 7.89 22.4 7.89
80486 DX2 66 45.1 12.0 35.3 12.4
IBM 486BL 100 53.9 12.0 40.9 11.8
AMD 5X86 133 84.5 9.37 84.5 9.42
Pentium 75 112 19.3 87.1 18.9
Cyrix P150 120 175 27.9 160 28.3
Pentium 100 169 31.8 122 32.2
Cyrix PP166 133 219 38.4 180 39.8
IBM 6x86 150 234 44.1 188 43.9
Pentium 133 239 38.3 181 39.0
Pentium 166 270 43.6 189 43.9
Cyrix PR233 188 286 46.4 232 45.8
Pentium 200 353 47.4 269 48.1
Pentium MMX 200 352 51.4 276 51.0
AMD K6 200 349 43.1 289 43.3
Pentium Pro 200 373 92.4 312 91.9
Celeron A 300 553 133 484 136
Pentium II 300 544 132 477 136
AMD K62 500 778 77.8 606 76.8
AMD K63 450 804 76.3 645 77.4
Pentium II 450 813 199 713 204
Celeron A 450 828 198 720 202
Pentium III 450 846 197 722 203
Pentium III 600 1105 263 959 270
Athlon 600 1316 321 942 316
Duron 600 1382 350 999 349
Pentium III 1000 1858 461 1595 465
PIII Tualatin 1200 2205 546 1907 571
Pentium 4 1700 2262 239 1843 242
Athlon Tbird 1000 2282 634 1659 602
Duron 1000 2288 576 1674 587
Celeron M 1295 2440 640 2273 645
Atom 1600 2462 717 1828 728
Pentium 4 1900 2593 261 2003 269
Atom 1666 2600 772 1948 780
P4 Xeon 2200 3028 300 2265 309
Atom Z8300 1840 3203 904 2686 927
Athlon 4 1600 3707 956 2830 1004
Pentium M 1862 4082 954 3933 975
Ath4 Barton 1800 4181 1061 3172 1099
Pentium 4E 3000 4379 566 3553 566
Athlon XP 2080 4826 1228 3700 1312
Turion 64 M 1900 4972 1186 3742 1150
Pentium 4 3066 5052 432 4012 434
Opteron 1991 5077 1268 3985 1223
Core 2 Duo M 1830 5379 892 4952 966
Athlon XP 2338 5433 1400 4160 1482
Athlon 64 2150 5658 1312 4288 1355
Pentium 4 3678 5787 511 4227 480
Athlon 64 2211 5798 1348 4462 1312
Celeron C2 M 2000 5804 932 5275 1050
Core 2 Duo 1 CP 2400 7145 1198 6446 1251
Core i5 2467M @@@@ 8338 1183 4752 1148
Phenom II 1 CP 3000 9462 2250 7615 2253
Core i7 930 **** 9826 1662 8684 1661
Core i7 860 #### 10094 1789 9978 1847
Core i7 3930K &&&& 13871 1960 11197 1972
Core i7 4820K $$$1 14136 1958 11867 1981
Core i7 4820K $$$2 14776 2006 11978 2014
Core i7 3930K OC 17269 2444 13877 2432
#### Rated as 2800 MHz but running at up to
3460 MHz using Turbo Boost
**** Rated as 2800 MHz but running at up to
3066 MHz using Turbo Boost
@@@@ Rated as 1600 MHz running at up to
2300 MHz using Turbo Boost
&&&& Rated as 3200 MHz but running at up to
3800 MHz, OC OverClocked ~4730 MHz
$$$1 Rated as 3700 MHz but running at up to
3900 MHz, using Turbo Boost
$$$2 Performance not Balanced Power Setting
for 3900 MHz
M = Mobile CPU
Электромобили изобрёл не Илон Маск, а Ипполит Владимирович Романов, но только Илон Маск смог добиться коммерческого успеха.
А к тому времени уличное освещение (газовое) уже существовало. Он довел это дело до ума
Ну почему, почему все всегда забывают про Лодыгина? Лампу накаливания изобрёл именно Лодыгин в 1874 году. Эдиссон занялся этим в 1879 (и, насколько я помню книжку, про Лодыгина он знал отлично и торопился скорее запатентовать лампочку в США). В 1890-х Лодыгин предложил для нити накаливания вольфрам и молибден и специальную закрутку спирали. Эдиссон же сделал выключатель и цоколь лампочки. Таким образом, до совершенства лампу доводил не Эдиссон, а Лодыгин.
Только это использование изобретения, а не доведение его до совершенства. Лампочка, которая у нас сейчас есть, придумана Лодыгиным и по его же идее была сделана с вольфрамовой нитью. А это — сама суть лампочки накаливания. От Эдиссона у неё цоколь и форма.
Вот тут хорошая статья из книги про Лодыгина. Есть там и про Эдиссона фрагменты.
В 1877 году группа русских моряков едет в США для закупки четырех кораблей («Африка», «Европа», «Азия» и «Забияка») и среди них — мичман Хотинский, везущий за океан калильные лампы Лодыгина и дуговые — Чиколева и Яблочкова — для демонстрации. За пропаганду успехов русской электротехники Хотинского представляют к ордену Анны третьей степени. Но по непонятным причинам именно там, в США, заявка на патент фирмой «Лодыгин и К°» оказалась не оплачена! Хотя оплачена в каждом из мизерных княжеств Германии, в Англии, Франции и даже Индии. И вскоре после отъезда Хотинского из США весной 1879 года Эдисон, до того не занимавшийся электричеством (см. биографическую книгу Дж. Брайана «Эдисон») проводит в лаборатории при огромном стечении народа и прессы свой первый опыт электрйческого освещения лампой накаливания. Опыт не удается — лампа тут же гаснет. Но Эдисон не только талантливый изобретатель, он и энергичный предприниматель. Он спешно подает заявку и вскоре получает патент на лампу накаливания с угольным стержнем, о чем тут же начинают трубить американские газеты, называя его — творцом электросвета. Тринадцать месяцев и сорок тысяч долларов ушли у Эдисона на опыты, в итоге его лампы стали светить несколько часов. Вслед за Эдисоном, сумевшим выпустить пробную партию ламп для продажи, а более — для рекламы «нового изобретения», начинают производить лампы лодыгинской конструкции предприниматели Англии, Франции и Германии. Эдисон, не желая делить прибылей с ними, подает в суд и тратит на тяжбу сотни тысяч долларов. Американские судьи, копнув историю изобретения, узнают о Лодыгине и аннулируют патент Эдисона. Американскому предпринимателю приходится приняться за поиск тела накала, чем-то отличного от найденного Лодыгиным, чтобы иметь юридическое право на подачу заявки вновь. Один из сотен посланных им во все страны света агентов-поисковиков находит японский бамбук… В США заявка принимается, но во многих странах Эдисону выдается патент лишь на усовершенствование в системе электроосвещения. А патент на изобретение в США (за № 369260) выдается лишь через десять лет, в 1890 году, — после окончания срока действия патентов Лодыгина во многих странах.
Интересно, что все эти годы, пока мировая пресса и электротехнический мир спорили о нравственной и юридической стороне дела — кто стыдил, а кто восхвалял Эдисона — Лодыгин отмалчивался — он продолжал работать. Будто знал что-то известное только ему одному, будто видел, что рано считать конструкцию лампы окончательной… И в самом деле — знал и видел, как никто из тех, кто лихорадочно спешил урвать барыши с нового приобретения цивилизации, штампуя угольную лампу с личным клеймом на стеклянных колбах: «Эдисон», «Грамм», «Сван», «Максим».
…
В Париже встретили его радушно: знали по публикациям И. Фонтена, по многим статьям в газетах и журналах и особенно по нашумевшей в дни Всемирной электрической выставки в Париже в 1881 году статье в журнале «Ла Люмьере электрик», где французские электротехники восстали против присвоения Эдисону титула первооткрывателя электрического освещения. «А Лодыгин? А его лампы? — вопрошал почтенный журнал. — Почему уж не сказать, что и солнечный свет изобрели в Америке?»
…
У фирмы «Вестингауз» есть возможности и для серьезных исследований, и для быстрого внедрения новшеств. Именно здесь Лодыгин может наконец осуществить свою давнюю мечту — получить в электропечах любые тугоплавкие нити для ламп и к тому же создать нужные ему электропечи.
И вот когда в 1890 году Эдисон, после дорогостоящих судебных процессов с конкурентами, получает наконец-то вожделенный патент на угольную лампу… Лодыгин подает серию заявок на лампы с нитями из железа, платины, вольфрама, осмия, иридия и других металлов и их сплавов! Вот чем он, не участвуя в судах, заканчивает борьбу за свой приоритет в электроосвещении!
Но сам он считает работу с лампой завершенной только после того, как разрабатывает серию электропечей сопротивления и индукционных — для плавки тугоплавких металлов — и берет на них патенты. Всем светотехникам скоро становится ясно — новые лодыгинские лампы вытеснят угольные. Творец тех и других — Лодыгин.
…
К 1905 году Лодыгин прочно обживается в США. У него теперь есть свой дом, семья, две дочери, Маргарита и Вера, а тоска по родине не ослабевает.
Но возвращение требует больших денег! Их предлагают неизвестные предприниматели за патент на вольфрамовую лампу… Позже выяснилось, что они — подставные лица от фирмы Дженерал электрик, слившейся с Эдисоновской.
…
Даже в некрологе его заслуги приглушены, затенены, хотя в американской прессе писалось много об его открытиях и одна из статей с перечнем его изобретений называлась «Блистательный Лодыгин», а в газете «Нью-Йорк геральд» еще в 1879 году — во время шумной рекламной компании вокруг Эдисона — прошла статья «Свет Лодыгина».
Ну и намек про то, что якобы злодеи помешали оплатить американский патент, вообще критики не выдерживает.
А вообще, вполне возможно, что они оба пришли к идее лампочки независимо. Такое бывает, когда создаются условия появления новой технологии.
В Википедии написано, что первая лампа накаливания была сделана в 1840 году (Де ла Рю). И к появлению современной лампочки приложили руки множество изобретателей.
Там кстати и бамбуковая нить упомянута, которая есть в вашей цитате.
К идее они не могли придти независимо — Эдисон точно знал про Лодыгина.
В Википедии написано
Всё верно. Только то, что сделали в 1840 было совершенно непригодно для использования в качестве лампочки (зачем вам лампочка на десяток секунд?). С 1840 десятки человек пытались эту самую лампочку сделать. Но ничего не получалось и стали даже считать, что это невозможно. А вот у Лодыгина получилось сделать лампочку, горевшую с пол-часа.
Не думаю, что кого-то хотят «подвинуть».
Ну да, я солидарен идее пагубности копирайта в науке и технике — иначе мир, а ну резко скинулся парой тысяч триллионов нынешних долларов Китаю за хотя бы бумагу, керамику и порох; — копирайт только вредит развитию нашей цивилизации. И деньги в близкой перспективе лишатся смысла и устареют, ведь роботы занимают всё больше и в перспективе заберут практически весь рынок труда, старая идея заработной платы перестанет работать. Тоже немало кто «очень огорчается такое читая», отказывается даже допускать эту совершенно логичную мысль.
Тут дело не в том что, мол «А, дурацкий совковый битард хейтер трудолюбивой америки натыкал коммент, который мне пришлось прочитать и я потратил своё время». Не, то было не об этом, друзья.
NASA безусловно заслуживает уважение тем что делает для нас всех. Но когда обнаруживается что «учёные придумали» что было уже придумано и описано десятилетия назад в тех же журналах и нет никакой ссылки даже в русскоязычных медиа, вот это обидно. Ровно то же и про изобретения — на мой взгляд важно только то кто изобрёл первым и поделился открытием, и возможно кто ещё независимо и параллельно, но не кто первым прибежал в патентное бюро.
У кого-то иной взгляд, он тоже имеет право на жизнь, не проблема. Просто я искренне полагал, что инструменты хабра нужны для несколько иных целей ) Не говоря уж о том, что в комментных баталиях тут всегда стоит читать не «война, иду на вы», а немного [не]заслуженного сарказма, лёгкой доброй иронии и конечно какой-то позиции. Но… )))
И как пример с тарелкой всё так, но, продолжая тему именно про тарелки — оч интересно было бы, пока даже идей нет рабочих теоретических.
В отличие от первой, статики, вторая часть этих явлений изучена сильно по разному.
Если движение зарядов, т.е. электродинамика и создаваемые этим объективные эффекты, которые мы называем магнетизмом, изучены достаточно неплохо и ушли во множественное применение в промышленность, в т.ч. периодическое движение зарядов, э/м волны и кванты э/м волны всем знакомы.
То движение масс, гравидинамика, возможные эффекты второго проявления гравитации, своеобразный гравимагнетизм, — пока только небольшие предпосылки, что нащупывается. Ну тут объективные технологические проблемы, шутка ли, что мы гравитационную волну смогли достоверно поймать только «на днях» от слияния двух нейтронных звёзд. И пока не слышно никаких чётких заявлений ни о параметрах ни о самом факте существования гравитонов, квантов гравитационного поля.
Так вот. В мире электромагнетизма есть такая штука как сверхпроводимость и связанный с ней эффект выталкивания магнитного поля из тела сверхпроводника.
Мысль-гипотеза для левитирующих (над произвольным по иным параметрам гравитирующим объектом порядка планеты) объектов — возможно механизм левитации должен быть связан с гравитационной сверхпроводимостью и гравидинамикой (маховики релятивистских скоростей?), т.е. левитирование должно достигаться либо выталкиванием внешнего гравитационного поля из внутреннего объёма или созданием противоположно направленного гравистатического (гравитационного) поля.
Там ещё третий вариант есть :) Но как раз уже более известный — про гипердвигатель коконного типа, когда вокруг корабля создаётся своеобразная сфера из вспененного специальный образом вакуума и он разгоняется относительно «нормального» пространства до неограниченных сверхрелятивистских скоростей при отсутствии внутри кокона даже намёка на ускорение. Емнип даже тут на хабре про это было.
Ещё интересная штука на тему есть на мембране www.membrana.ru/particle/3028 про достижения немецкой физической мысли.
В простейшем рассмотрении тело с массой точно не сверхпроводник для гравитации. Например бетонная стена радикально помешает движению гравитационного носителя «автомобиль».
К тому же если в прямом смысле подходить к вопросу сверхпроводника — того что имеет нулевое сопротивление движению носителей, — то как и для зарядов, для масс в качестве «сверхпроводника» внезапно подойдёт идеально чистый вакуум.
Кстати насколько хорошо подойдёт реальный физический вакуум, пусть даже без вот этого всякого солнечного ветра, межзвёздного газа и залётных фотонов и иных реальных частиц, чисто бурление метрик и виртуальных пар частиц типа электрон-позитрон и др. — и на это так решительно сходу не ответить.
Что же касается «нормального сверхпроводника», т.е. некоего вещества в котором шёл бы без потерь процесс движения носителей, то для электронов как мы знаем подходит довольно широкий ряд вещественных сред, а для масс… Для масс как очевидный геометрический случай подходит вращение аксиально симметричного тела — маховик, гироскоп, юла, неважно как назвать. И масса движется, и она сама себе не мешает, и сама из себя создаёт так сказать среду-вещество-сверхпроводник для самой себя. Такой вот своеобразный сам себе сверхпроводник. Лишь бы была решена инженерная задача, чтоб в случае огромных скоростей вращения девайс не разваливался.
Но там у немцев выше намного интересней теория, советую.
Не успел заметить и поправить вовремя, правильно так:
В простейшем рассмотрении тело с массой точно не сверхпроводник для гравитационного тока (движения массы).
т.е. некоего вещества в котором шёл бы без потерь процесс движения носителей, то для электронов как мы знаем подходит довольно широкий ряд вещественных сред
Например, каких? Там совсем нет потерь, или они просто очень малы? Просто здравый смысл подсказывает, что идеального ничего не бывает, и какое-то сопротивление среды есть всегда. Иначе уже и вечный двигатель бы существовал, и скорость света была бы достижима для чего-то крупнее частицы…
Кстати, «вечных» относительно продолжительности жизни человека и более, двигателей/источников энергии существует достаточно немало, начиная со звёзд.
Со звёздами — понятно, я имел в виду «вечный» в смысле бесконечности двигатель, а не в смысле «проработает тысячу лет». И почему не имеет? Вы же сами сказали про «ноль потерь». Двигатель должен совершать какую-то работу, отдавая энергию. Берём источник с очень большой энергией (которая закончится очень нескоро). Тот же атомный реактор подойдёт. И применяем эти знания про «ноль потерь». Должна получиться очень, очень долгая работа источника. Но вроде пока такого не разработано. В чём загвоздка?)
P.S. Я квантовую физику не изучал, пытаюсь понять это явление с позиций обычной школьной программы, сильно не пинайте.
речь идёт о сверхнизких температурах?Ну как сверхнизких, до -70 градусов под давлением.
Неужели прямо ноль? Или просто потери так малы, что наши приборы не могут их зафиксировать?Там примерно следующая ситуация. Сопротивление прямо пропорционально температуре, но в некоторых веществах, при охлаждении ниже определенной температуры, резко падает как минимум на порядки, и становится неотличимо от нуля на современном оборудовании. При этом обладающая самой большой предсказательной силой на сегодняшний день рабочая гипотеза утверждает, что там ровно ноль.
При этом обладающая самой большой предсказательной силой на сегодняшний день рабочая гипотеза утверждает, что там ровно ноль.
А вот это странно. Не поделитесь ссылкой на описание этой теории? Просто уменьшение чего-то на порядки (даже на очень много порядков) — ноль давать не должно. Это ведь деление :)
Исключение — если там деление, сделанное x раз, где x стремится к бесконечности… Но это для физического процесса как-то странновато всё-таки.
Не поделитесь ссылкой на описание этой теории?Смысл теории заключается в том, что частицы могут находиться не в непрерывном спектре состояний, а в дискретном. И если частица уже находится в минимальном энергетическом состоянии, то отдать часть своей энергии «на трение» она не может. Точно так же, если она находится в одном из наиболее низких состояний, то она не может отдать «на трение» малую часть своей энергии — либо всю, либо ничего. Ссылка
Просто уменьшение чего-то на порядки (даже на очень много порядков) — ноль давать не должноЯ пишу «как минимум, на порядки». Мы не можем в эксперименте отличить 0 от очень маленького значения, и никогда не сможем. Однако, были определенные интересные эксперименты — например, сверхпроводящий контур проводил ток в течение 23 лет без источника тока и без зафиксированной потери напряжения. А график зависимости сопротивления от температуры выглядит вот так (зеленая линия):Предположение, что оно там становится в точности равно нулю, проще, чем предположение, что оно там имеет сложную структуру и очень близко к нулю, поэтому оно должно иметь предпочтение в соответствии с бритвой Оккама
А что есть cv, я не очень понял?
Потом ещё интересен такой момент: как обошли проблему потерь из-за сопротивления на измерительном приборе? Мерили ток всего несколько раз за эти 23 года, очень быстро?
вариант со сложной структурой кажется вероятнееС какой именно сложной структурой? Почему именно такой, а не какой-нибудь другой? Пока ответа на этот вопрос нет, простая структура более вероятна, чем любая отдельно взятая сложная. См аргументацию бритвы Оккама.
что есть cvТеплоемкость.
как обошли проблему потерь из-за сопротивления на измерительном приборе?Не знаю. С той фразы есть ссылка на первоисточник, можно изучать. Можно, наверное, даже с автором связаться.
С какой именно сложной структурой?
Примерно так же соотносящейся с cv, как и на верхнем участке, я полагаю (догадка навскидку). Или любой другой, зависимость может отличаться.
См аргументацию бритвы Оккама.
Бритва Оккама была придумана философами, а не физиками. И мотивацией была лень, насколько я понимаю — с простыми концепциями и меньшим их количеством проще работать. Это не значит, что всё в мире устроено согласно этому принципу :)
так же соотносящейся с cv, как и на верхнем участкеНа верхнем участке cv пропорциональна температуре, а p пропорционально ее кубу. То есть, чтобы было «так же», при пересечении критической температуры p должна расти примерно в десять раз (поскольку cv растет чуть более, чем вдвое). Вот только по экспериментам p падает на много порядков. Не подходит.
Это не значит, что всё в мире устроено согласно этому принципуБритва Оккама вообще не говорит о том, как устроен мир. Она говорит о том, что, поскольку мы не знаем, в какую сторону мир отличается от простой гипотезы, есть смысл принять в качестве рабочей именно эту простую гипотезу, как «среднее» между всеми отличающимися от нее сложными. Почему, например, вы думаете, что сопротивление сверхпроводника вообще положительно, а не отрицательно, как у газоразрядной лампы?
То есть, чтобы было «так же», при пересечении критической температуры p должна расти примерно в десять раз (поскольку cv растет чуть более, чем вдвое). Вот только по экспериментам p падает на много порядков. Не подходит.
На рисунке же есть формула. Ниже критической температуры у cv другая зависимость.
Почему, например, вы думаете, что сопротивление сверхпроводника вообще положительно, а не отрицательно, как у газоразрядной лампы?
Хороший вопрос… А есть способ померить отрицательное сопротивление? Может быть так, что оно отрицательное, но очень близко к нулю, и поэтому мы этого не фиксируем? Это тоже вполне себе версия :)
Ниже критической температуры у cv другая зависимость.Ну так и у p другая зависимость. Я, видимо, не понял, что вы понимаете под «так же соотносится с cv, как и на верхнем участке» — я интерпретировал это как «p пропорционально кубу cv».
Может быть так, что оно отрицательное, но очень близко к нулю, и поэтому мы этого не фиксируем?Может. Но гипотеза о том, что там ровно ноль, проще, находится посередине между другими объяснениями, и хорошо стыкуется с соседними научными теориями. Поэтому логично на сегодняшний день именно ее принять за рабочую. Если вдруг появятся другие данные — не беда, пересмотрим вопрос.
Труба с водой вполне себе аналог провода с электронами. Может если сделать катушку планетарных масштабов с движущейся массой, то можно будет построить гравитационное радио. Или трансформатор.
Лампу накаливания изобрёл именно Лодыгин в 1874 году.
Эм,
In addressing the question of who invented the incandescent lamp, historians Robert Friedel and Paul Israel list 22 inventors of incandescent lamps prior to Joseph Swan and Thomas Edison
Лодыгин всего лишь один из множества изобретателей, работавших как совместно, так и порознь.
В 1890-х Лодыгин предложил для нити накаливания вольфрам
Если точнее, то в 1893 он оформил патент, в 1906 продал его General Electric. Причина непопулярности в то время ламп с вольфрамовой нитью — их дороговизна. Поэтому история сделала спираль, и на новом её витке патент в 1904 году оформили Шандор Юст и Франьо Ханаман, в 1906-м Вильям Кулидж изобрёл метод спекания вольфрама в «ковкий вольфрам», удешевивший создание спиралей, благодаря чему в 1911-м General Electric начала производство коммерческих ламп, ставших действительно популярными после того, как в 1913-м Ирвинг Ленгмюр открыл, что наполнение баллона инертным газом вместо вакуумирования повышает светимость и долговечность лампы (замедляет почернение баллона). Окончательный, практически современный вид лампа накаливания получила в 1917-м году, с патентованием Берни Ли Бенбоу спирали, сделанной из спирали (двойная спираль). Таким образом, говорить, что именно Лодыгин «доводил лампу до совершенства» — очень странно. Этот процесс длился многие годы и в нём учавствовало множество людей.
С.П. Королёв и руководство СССР не смотрели на другие страны, разрабатывая ракеты.
За упаднические настроения Сталин бы вас расстрелял.
За упаднические настроения Сталин бы вас расстрелял.
А Иван Грозный чего бы сделал?
С.П. Королёв и руководство СССР не смотрели на другие страны, разрабатывая ракеты.
Вообще-то смотрели, и особенно на Рейх.
Просто, выводы делали правильные.
За упаднические настроения Сталин бы вас расстрелял.
Лично. Потом четвертовал. Вас. За поклёп на вождя. Тоже лично. Почему-то "Сталин" в качестве пугала и прожектёрство идут рука об руку.
не смотрели на другие страны, разрабатывая ракеты.
Очередной несовместимый процессор, который будет не нужен ещё по одному пункту? Отличная идея.
Многие современные процессоры производятся в Китае
Современные по дате производства, но не передовые по сути.
Если цель бабла поднять — затея, может, и тухлая. А если развлечься — в самый раз.
Ну, ракеты же у нас частники пытаются делать. И там тоже начинают не с возвращаемых ступеней, а с простейшей летающей пепяки.
Так собирали же уже: https://m.habr.com/post/243175/
И рак вылечат, и на Марс полетят. Я как-то даже не знаю — вы сознательно себе запретили или даже не подозреваете думать о цене такой разработки(дело не только в деньгах) и о бесполезности разработки (а это ведь не только "придумать процессор" — это все его схемы сделать) без производства.
стартапы делают многие тяжелые и трудоатратные вещи
Вы сравниваете постройку сарая с небоскрёбом.
1) Хотим, чтобы на нашем процессоре крутилась винда. Тогда нужно создавать процессор, эмулирующий другие процессоры. Чтобы продавать их без признаков архитектуры, а пользователь загружал прошивку и получался x86. То есть банальный FPGA, только на три порядка лучше, чем лучшие из ныне имеющихся. Удачи.
2) Бог с ней, с виндой. Обойдёмся одним Линуксом. Тогда разрабатывать ничего не нужно, потому что уже есть ARM. Но вот чего-то не взлетает стационарный ARM, не взлетает.
developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
©
Ключевой кусок фразы "we believe our processors are not susceptible ....".
Мы верим...
Да, пока не удалось обнуражиться уверенны, что нет такой уязвимости у них. До тех пор пока не доказано обратное — этого достаточно.
Насколько я понимаю, пока вендоры кардинально не пересмотрят разграничение прав при спекулятивном исполнении мы будем получать или дыры или падение производительности. А поскольку на рынке чипов для ПК всего два игрока, то и заморачиваться не стоит.
На рынке чипов для ПК больше двух игроков.
Их может быть довольно много, но по факту производителей чипов для ПК очень мало, если откинуть такие экзотические варианты, как рабочая станция на power 9, то остается только AMD и Intel, причем первый практически не представлен в верхнем сегменте бизнес-ноутбуков.
У VIA до сих пор есть лицензия на х86.
VIA x86 Processors
List of x86 manufacturers
Zhaoxin
Zhaoxin's home-grown x86 CPU
Т.ж.:
Lenovo на Snapdragon 850 с Microsoft Windows 10 Pro (64-битная версия) может скоро выйти
И т.ж. процессоры «Эльбрус» и «Байкал».
Вендором в РФ обычно называют поставщика готовых систем (HP, Dell, ...).
AMD Ryzen 3-5-7 в ноутбуках — 37 достаточно дорогих моделей на Яндекс маркете (в Мск).
средний компьютер имеет 0 (ноль) анклавов
А пруфаните плиз чем-нибудь это утверждение? Выглядит интересно, но спорно в свете 1password того же.
Судя по зарплатке к ядру исправление для обычных машин довольно простое и надёжное для L1. А вот с виртуальными машинам всё очень плохо. (Англ)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958f338e96f874a0d29442396d6adf9c1e17aa2d&context=40&ignorews=0&dt=0
Если что, это был <sarсasьm /> :)
Если вы покупали процессор напрямую у Интела и в договоре купли-продажи согласовали возврат хоть части денег в случае обнаружения уязвимостей, то вернёт, конечно.
SGX вроде как отличное подспорье для DRM (даже root не может получить доступ к данным программы), а DRM, как известно, плохо...
Вопрос к людям, хорошо знакомых с темой: возможность эксплуатации этих уязвимостей для получения конкретной выгоды или кражи конкретной информации реалистична? Не теоретически, а вживую, и не на демо-программке?
RedHat пишут, что верифицировали.
When we first reproduced this attack within Red Hat earlier this year, we used a modified version of the TU Graz Meltdown code to extract data from known physical addresses in which we had stored interesting strings. While we should have seen an innocuous string we stashed in the guest physical memory, once the malicious L1TF PTE was created for the same location in the host, we read its memory instead. There are a few additional pieces required to reproduce the vulnerability that are omitted.
Когда у вас сервер под нагрузкой, там с пяток пользователей, и вот один решил что то там захакать… В результате беготни потоков у него ничего не выйдет, в кэше будут какие то разные куски разной памяти, да и с точными замерами времени могут быть разнообразные проблемы.
Решето? Баг? — Репорт, багфикс, переделать.
В этом ключе. Если ось смогли и кучу софта, почему б и железо не смочь копилефту.
Вы про RISC-V? Уже есть настоящее железо, правда без серийного производства пока дороговато.
Почему — выше написали.
Напоминаю, что «ось» писалась в те древние времена, когда еще не было истерии вокруг копирайта.
А еще есть спецслужбы.
В интернетах находит только новость на appleinsider.com
It is highly likely that Apple will be involved in the patching process, if it hasn't already, as it uses Intel processors across its entire Mac and MacBook product lines. Current-generation iMac models use Skylake processors, and while earlier MacBook Pro models used Skylake and Kaby Lake chips, the latest use Coffee Lake.
Т.е. облачным сервисам разогнать клиентов и закрыться?
Регистров для реализации шифрования на них не хватит, так что в кеш что-то попадёт.
А тут что? Мы вообще не канал между процессором и RAM должны защищать (иначе да, можно было бы чипы шифрования встроить в проц и в планку памяти просто-напросто). Тут проблема в том, что процессор не настолько умный, чтобы отличить обращение «легитимного» источника к данным кэша от «нелегитимного» (или даже не так, у процессора нет времени на такие проверки, т.к. это просадит производительность; упреждающие ветки, по которым может пойти алгоритм, надо считать здесь и сейчас, а разбираться некогда). И чем поможет шифрование в нашем случае тогда?
Spectre и Meltdown больше не самые опасные атаки на CPU Intel. Исследователи сообщили об уязвимости Foreshadow