Pull to refresh

Comments 214

Ощущение, что за счет таких вот "дырок" Интел и наращивал производительность последние годы.

В целом так и есть, спекулятивное исполнение оно и надо чтобы ускорить работу, а вот побочные его результаты сейчас и пожинаем.
Ждать закрытия дырок с побочным снижением производительности?
Так были же уже патчи, закрывающие какую-то из дыр и подкашивающие производительность. Я где-то читал, что если спекулятивное исполнение вырубить вовсе, по производительности лет на 10 назад укатимся.
Лепота-а-а-а…
Благими намерениями дорога ведет ад.
Что конкретно вы например пожинаете? я так и не увидел никаких последствий на себе, сопоставимых с поднятым хайпом.
Как я понял это вообще коситься только хостеров впсок, а для обычных юзеров все по прежнему, если дал исполнить вредоносный код у себя, то тебе кранты не зависимо от наличия этих уязвимостей в процессоре.
Вредоносный JS в браузере, например?
Давайте пример, я зайду на любой сайт, продемонстрируйте мне вред JSа.
Значит, есть повод производителям браузеров задуматься о некотором относительно поверхностно — дабы работало быстро и сильно не грузило процессор — анализе скриптов при загрузке до начала их выполнения. Хотя лично я пока ещё от вредоносных скриптов не пострадал ни разу (не считая времён, когда использовал IE7).
Вы так говорите, как будто это не задача, которую антивирусные компании до сих пор не решили.
А как быть тем, у кого не стоит антивирус? Я именно про браузер писал. Вы считаете, что нагружать браузер функциями, не свойственными ему (встраивать антивирус) — скверная идея? Ну так авторы приложения «Сбербанк.Онлайн» вон к себе антивирус встроили, их это не остановило :)
UFO just landed and posted this here
Так это ж чуть ли не крупнейший банк РФ… Там реально всё с приложением так плохо?)

Насчёт определения вредоносности — мне не кажется, что задача выявления кода, эксплуатирующего на JS эту уязвимость, настолько сложна. Есть же примерный тестовый фрагмент. Понятно, как он работает (что делает и в какой последовательности). Да, есть обфускаторы. Ну так и что? Во-первых, они больше против анализа кода человеком работают, чем против анализа алгоритмом (алгоритму пофигу на имена, отступы, перестановку независимых блоков местами). А во-вторых, если точно непонятно, «хороший» перед нами код или «плохой» — можно всё равно показывать красное предупреждение перед исполнением скрипта и показом страницы, и просить пользователя нажать на ссылку вида «Я понимаю риск, продолжить», даже если код безобидный, а просто сильно обфусцирован. Не все сайты будут такому рады, зато безопасность :)
UFO just landed and posted this here
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 вроде, тоже ловит код автоматически).

Контакты — наверное для каких-то опций шеринга (типа, рассказать о приложении друзьям).

Вот зачем ему доступ к камере и микрофону — я без понятия…

Сколько антивирусов вы написали? Или хотя бы сигнатур?

Ни одного. А к чему этот аргумент? Я не сказал, что я напишу. Но спецы напишут без проблем. Там же идея простая, как пробка, извините меня…
Контакты — наверное для каких-то опций шеринга

Доступ к контактам нужен для отправки денег. Там есть опция послать деньги клиенту сбера по номеру телефона. Этот номер телефона можно искать в адресной книге.
Камера — это для QR-кодов на квитанциях.
Ого, не знал, что так можно. Наверное, туда и расшифровщик этих самых QR-кодов встроили? Только сегодня читал статью, про то, что современные приложения стали раздуты по объёму — вот и пример (правда, тут как раз такая интеграция полезна).

В моём телефоне Sony Ericsson QR-сканер был предустановлен как небольшое отдельное приложение сторонней компании, которое можно было при желании удалить. Но когда всё встроено в банк-клиент — оно пошустрее будет, чем через интенты.
И перевода денег на карту методом «наведи камеру на карту, номер распознается»
UFO just landed and posted this here
Пожалуйста, подскажите хотя бы одного спеца, который уже больше 20 лет пишет антивирус для лечения уязвимостей Spectre и Meltdown.
UFO just landed and posted this here
При том, что вы находитесь в ветке, где обсуждается фраза
мне не кажется, что задача выявления кода, эксплуатирующего на JS эту уязвимость, настолько сложна.
UFO just landed and posted this here
Ну это уж я не знаю. Вот товарищ выше по ветке утверждает, что там код очень специфический — если это действительно так, то задетектировать его не должно быть сложно.
Именно для JS — да, потому что там был всего один метод эксплуатации, связанный с особенностям работы JIT компилятора и приведением типов — да и тот Google уже оперативно прикрыл в следующей же версии Chrome. А вот на чём-то вроде C++ — это да, тут кроме как прошивкой процессора и патчем на ОС ничем не защитишься…
Вот зачем ему доступ к камере и микрофону — я без понятия…
Там внутри звонилка в банк через сеть, для клиентов за рубежом. Я в РБ съехал из РФ, поэтому сталкивался.
Например я, в теории мог бы пожинать патчи для операционок которые бы тормозили мой проц купленный за кровные деньжищи. Меня это не касается. И вообще я в целом имел ввиду мир, а не себя лично.
UFO just landed and posted this here
Закон Мура развернулся.
Ждём «производительность падает в два раза каждые 18 месяцев из-за новых патчей на дыры».
Если только ситуация не пойдет по более парадоксальному пути: если нельзя защитится от пользовательского нативного кода, значит надо лишить пользователя права исполнять нативный код в принципе. JVM на уровне ядра ОС, и виртуальная песочница для пользовательских программ. :)
Ну вот, опять минус :) Интересно почему. Ну да, JVM не подойдет, нужно что — то другое, способное «эмулировать» опасное поведение, и исполнять все остальное напрямую на железе. Не уверен, что задача безнадежно неразрешима, но есть надежда, что ее сложность не превысит сложности построения нового ЦП без описанных проблем.
Тогда и закон Мура снова начнет работать в правильном направлении. :)
надо лишить пользователя права исполнять нативный код в принципе

Насколько я помню, атаки типа Meltdown и Spectre вполне себе успешно выполняются на Javascript в браузере. Так что запрещение нативного кода ничего не меняет.

Атака использует особенности работы процессора. При чем здесь способ доставки зловредного кода?
Да ничего они не выполняются. Проверял сто раз и других просил. У вас у самого-то этот тест выполнился?
Я и нативные примеры на C, которые здесь приводились, не смог заставить добывать хоть что-то осмысленное из памяти на двух разных компьютерах. Давали какое-то ничтожное количество попаданий на фоне тяжелой загрузки процессора.
JVM на уровне ядра ОС, и виртуальная песочница для пользовательских программ. :)

Так ведь когда то и хотели сделать процессоры с системой команд, основанной на Java- и .NET/IL-байткоде, а также первоначально ожидалось, что проект Longhorn будет включать как раз виртуальную JIT-машину .NET на уровне ядра, а WinAPI будет эмулироваться (а ведь были еще проекты Sing# и Singularity OS).


Но потом что-то пошло не так..

Интересно… То есть под эмуляцией мы в данном случае подразумеваем исполнение виртуальной машиной обычного нативного кода в целях исполнения инструкций, пришедших ей «на вход» в виде байт-кодов?

Тогда что принципиально изменится? Злоумышленники будут искать способ заставить эту виртуальную машину выполнить то, что она выполнять не должна (или не должна в конкретных условиях). Просто ещё одна прослойка появляется, внутри которой можно концентрировать какую-то логику по защите пользователя от вредоносных действий.
Тогда что принципиально изменится?

Код будет исполняться под контролем VM, которая не обязана эмулировать проблемное поведение процессора.


Злоумышленники будут искать способ заставить эту виртуальную машину выполнить то, что она выполнять не должна

Это будет уже другая проблема, которую, к стати, решить и проще, и быстрее.

Она может иметь свои уязвимости, она будет в разы медленнее (т.е. сайтики делать можно, но работа с оборудованием может не получиться).

> решить и проще, и быстрее

Не всегда, живущие годами уязвимости в софте это доказывают. Тем более можно взять просто компьютер постарше — будет в разы быстрее VM с интерпретацией исполнением.
Она может иметь свои уязвимости, она будет в разы медленнее

Я слышал, что заплатки тоже сильно присаживают производительность (сам их не использовал). Вопрос, что хуже, лекарство или болезнь.


можно взять просто компьютер постарше — будет в разы быстрее VM с интерпретацией исполнением.

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

Заплатки просаживают, но не на порядки (когда для интерпретации одного опкода нужно выполнить десятки команд).

> уязвимость присутствует в процессоре давно

Не ранее внеочередного исполнения, VM будет не быстрее тех (если исполняется на современных, которые с уязвимостью).
Если, все таки, настаивать на решении этой проблемы, а я не уверен, что это нужно делать в обязательном порядке для всех, то, наиболее перспективным мне кажется вариант с изоляцией пользовательских процессов от доступа к CPU. Что — то в стиле android, грузим ОС, грузим виртуалку, грузим пользовательские процессы в память VM.
Если VM будет написана не на java, а способ и глубина ее интеграции в ОС тщательно продумана, то падение производительности может оказаться не столь заметным.
Если пользовательский процесс будет отгорожен от CPU, то падение производительности будет в разы, просто по определению (может или исполнять сам процессор после jit или другого преобразования или на исполнение любой инструкции пользовательского процесса (а какой пользовательский? это ведь не только тонкий клиент, инженерные расчёты — тоже клиентсвие) потребуется несколько инструкций CPU (выборка, анализ, выборка операндов, анализ, исполнение). Андроид уже давно использует компиляцию, т.к. иначе даже современные телефоны оставались бы страшными тормозами даже показывая калькулятор.
Одно не понятно. Кто мешает в наше время сделать процессор, в котором будут физически выделенные ядра для запуска ядра ОС и отдельные физические ядра, на которых крутитятся пользовательские приложения?
Ядра для ОС можно сильно упростить и ускорить за счет того, что не нужна быстрая арифметика с плавающей точкой, не требуется бОльшая часть возможностей по обработке аудио и видео, не требуется поддержка SIMD. На сэкономленных транзисторах можно сделать гигантский кэш первого уровня, чтобы все ядро ОС туда поместилось.
А потом приходит Андроид со своей обработкой видео в ядре и stagefright и рушит всю систему. Сделать процессор и операционку (с нуля), а потом не осилить, ибо нужен ещё и софт, а пользователи даже более привычный винмобайл и хромуюось неоценили.
При чём тут Андроид?.. Вы много его видели на декстопах? Мы вроде десктопные процессоры обсуждаем…
Про калькулятор — не факт. Была же Java ME, на ней игрушки порой летали, если мобильный был достаточно мощным. Но «мощный» мобильный по временам первой половины нулевых — это даже не 100 МГц процессор...)
Игрушки летали даже на 8 МГц, вопрос в размерах картинки и детализации, а ещё применяемых хаках. Есть области, где такие хаки не прокатят.
Принципиально изменилось бы то, что управляемые (байт-код VM) и «традиционные» приложения поменялись бы местами:
Сейчас управляемые приложения работают через доп. прослойку, а традиционные работают нативно.
А было бы наоборот, при этом традиционные приложения перешли бы в разряд легаси, и постепенно выбыли бы из эксплуатации.
Предполагалось, что при этом управляемые приложения стали бы работать более безопасно.
Ну в целом идея с виртуализацией «традиционных » приложений ясна. А можно поподробнее, почему такой подход будет безопаснее? Чем управляемые приложения качественно лучше традиционных? В традиционных — за исполнение отвечает процессор, в вашем сценарии — виртуальная машина, которая неким образом общается с процессором. При этом процессоры останутся те же (или почти те же), в них всё равно будут какие-то уязвимости, вопрос в масштабах. И виртуальная машина ещё своих сверху добавит :)
в целом идея с виртуализацией «традиционных » приложений ясна.

Здесь скорее, речь шла о выполнении традиционных приложений в режиме эмуляции, как это было сделано для выполнения DOS-приложений в Windows-среде, чем о виртуализации.


Чем управляемые приложения качественно лучше традиционных? В традиционных — за исполнение отвечает процессор, в вашем сценарии — виртуальная машина, которая неким образом общается с процессором. При этом процессоры останутся те же (или почти те же), в них всё равно будут какие-то уязвимости, вопрос в масштабах. И виртуальная машина ещё своих сверху добавит :)

Как раз сейчас выполнение управляемых приложений и происходит так, как вы описали — процессор со своими уязвимостями, ОС со своими, и прикрученная к ОС виртуальная машина со своими (плюс тот момент, что она именно "прикручена" фактически как сторонее приложение, что в свою очередь снижает надежность).


В итоге что получаем — плюсы управляемого байт-кода во многом нивелируются вышеописанным.
А когда был хайп в момент появления Java и .NET, была куча статей и обещаний, что вот-вот появятся процессоры, которые могут исполнять управляемый байт-код Java или IL.
(Да вроде бы даже и были уже Java-процессоры, а на стороне .NET были Singularity OS и Sing#)


Тогда виртуальная машина в ОС смогла бы стать более "нативной", реальной частью ОС, если и вовсе не ее ядра, и при этом стать более компактной, отвечать, например, только за сборку мусора, т.к. байт код исполнялся бы процессором, и JIT-компилятор тоже не потребовался бы.


Плюсы достаточно очевидны — управляемый код выполняется в железе "нативно", а на стороне ОС минимизируется количество прослоек.

UFO just landed and posted this here
Так когда это было — Java-процессоры? В то время и x86 был другим.

И не назвал бы Itanium унылым.

А насчет того, куда движется мир в технологиях — скорее, это движение вперед, но с итеративным раскачиванием маятника.
Так что, может, увидим еще и процессоры для байт-кода.
UFO just landed and posted this here
Да, в целом согласен. А можно ещё раз к началу — в чём принципиальное отличие Java (или других) байт-кодов от обычного машинного кода?

Я в целом пару раз с машинными кодами сталкивался. Сдаётся мне, что там не так много разного у этих концепций. Те же байты, отвечающие за команды, указатели, данные, которые лежат по указанным смещениям… Чем байт-коды устроены иначе? Как там с хранением данных обстоит? Есть ли работа со смещениями для получения доступа к следующей нужной команде?

Основное отличие в том, что байт-коды виртуальной машины это ограниченный набор высокоуровневых кодов (.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.


Ого. Я б почитал про такое, интересно.
«Да их тут тысячи!» (tm)

Навскидку:
  • Структура команд не менялась с 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, наверно, весьма неплоха (раз они до сих пор близки к первому месту), но именно архитекторы… я не знаю, кем надо быть, чтобы смотреть даже не на шаг, а на полшага вперёд, и каждый следующий шаг делать в несовместимом направлении.
Благодарю, прочитал с интересом.
Вообще, я думаю, пост про такое будет очень в духе Хабра и взлетит!
Ну, UWP в Windows 10 примерно по такой идеологии и работает
Закон Мура же не о производительности, а о количестве транзисторов, так что всё с ним нормально, уязвимости, а точнее патчи, его не затрагивают.
Закон Мура нередко упоминают в контексте производительности, хотя это дань истории и ни чего больше. В те, не очень далекие времена, когда процессоры были еще одноядерными, а разговор о пределе роста числа транзисторов в рамках одного кристала был теоретическим, тогда удвоение числа транзисторов в процессоре напрямую приводило и к росту вычислительных возможностей в два раза. Но, чем ближе был предел, тем больше это переставало быть правдой.
А вообще были зарегистрированы реальные случаи эксплуатации Meltdown/Spectre? А то я читал, что патчи для Windows Server, закрывающие Meltdown, после установки даже выключены по умолчанию.
Прототипы вредоносных программ есть, антивирусы даже их распознают. Но реального применения не слышал. По моему мнению — слишком сложно и запредельно круто. Если злоумышленник хочет заработать деньги — то куда проще использовать адварь, шифровальщик или майнер. Надо что украсть — фишинг, брутфорс, уязвимости обычного типа.

А здесь получается нужна высокая квалификация разработчика, программа получается дорогая, а средства защиты при массовом исполнении ее выловят мгновенно. И тогда смысл?

Возможно только для хитро целевых атак.
Вот и радуешься, когда сидишь на интеле 6тилетней давности (i7-3635QM)
Spectre/Meltdown и у вас есть :)
Ну от них патчи уже стоят :) Хотя последнее время заметил, что система (ubuntu) подлагивает. Возможно дело и не в патчах, надо как-нибудь заняться этим ))
Ну от них патчи уже стоят :)


Только от Meltdown. От Spectre патчей не существует.
Зато вот есть очень надежный патч от Meltdown — называется «смени процессор на AMD» :)
Самый надежный патч — иди «пешком» — кирпич, который даже звонить не умеет ))
Атомы постарше не умели в спекуляцию. Вот вам тот самый кирпич, даже лучше чем AMD.
*полез на антресоль за старым нетбуком*
Как говорят безопасники: самый безопасный компьютер — это силикатный огнеупорный кирпич.
Может быть сами соберемся, да разработаем свой cpu без этих дыр? Думаю, что на хабре достаточно профессионалов в этом деле найдется
Возможно, но стартапы делают многие тяжелые и трудоатратные вещи. Да, не все из них выстреливают, но если найти людей, которые будут этим гореть — успех будет, при наличии финансов, конечно
Чисто ИМХО но пока будут делать первый образец, Intel/AMD выкатят минимум пару моделей, и DDR из 4 превратится в 6-7. А ещё к процу надо чипсет сделать. Можно посмотреть например на разработку Эльбрус. Опять же ИМХО стартапщикам такое не по зубам.
Возможно я так свою карму утоплю по глубже. Но, считаю, что если так думать, то никто и пытаться не будет.
Вспомните Эдиссона и его историю с лампочкой. Не каждый сможет 10тыс раз проводить эксперимент с подбором материалов для нити накаливания. А к тому времени уличное освещение (газовое) уже существовало. Он довел это дело до ума.
И хоть разработка cpu кажется вам невозможной (нерентабельной), в перспективе, при помощи сообщества, ситуация может измениться.
Он делал лампочку с нуля. Так же кто то при наличии лампы накаливания, всё равно сделал газоразрядные лампы, светодиодные, люминесцентные итд.
А тут вам надо взять лампу накаливания, и улучшить её КПД, возможно вам понадобится 10 милионов опытов, чтобы добиться этого. Это вполне возможно, но потом вам надо будет ещё найти фабрику которая сможет из вашего материала делать лампочки, и при этом конкурировать с теми кто их делает уже давно.
Сказать что это невозмножно будет неправильным, сказать что трудно исполнимым да. Помните конкуренты Intel/AMD/ARM на месте не сидят, и дыры закроют которые уже нашли.
Сделать надежный проц для себя, если главная цель надежный то это реально(386 для FPGA вроде кто то уже делал). Другое дело и быстрый и надежный это уже совсем другое дело, иначе бы их делали не только AMD/Intel а например ещё и VIA делала что то конкурентное опыт у них есть но вот не делают.
PS. Хотя я думаю найдётся много людей который при финансировании готовы этим заниматься пока финансирование не закончится.
Ага… Про VIA только вот вчера пробежала новость, что там бэкдор встроен на аппаратном уровне.
Он не делал лампочку с нуля: Пруф
И кто говорит, что это будет просто?
Посмотрите на судьбу «Эльбруса». Его делали профессионалы еще советской школы. Спроектировали отличный процессор (они утверждали, что лучше Интел), а потом долгие годы искали возможности его сделать — спонсоров, оборудование и проч. Современные процессоры — это почти миллиард транзисторов, 14 нм технологии. Вы представляете себе эти цифры?
Да, я представляю себе эти цифры. Дальше что?
Современные процессоры есть на 7 нм.
В 1877 году русский морской офицер А. Н. Хотинский принимал в Америке крейсеры, строящиеся по заказу России. Он посетил лабораторию Эдисона и передал ему лампу накаливания А. Н. Лодыгина и «свечу Яблочкова» со схемой дробления света. Эдисон внёс некоторые усовершенствования и в ноябре 1879 года получил на них патент как на свои изобретения. Яблочков выступил в печати против американцев, заявив, что Томас Эдисон украл у русских не только их мысли и идеи, но и их изобретения. Профессор В. Н. Чиколев писал тогда, что способ Эдисона не нов и обновления его ничтожны.

Яблочков, Павел Николаевич

Смысл патента Эдисона — не платить за патенты Европе.
Так точно, на FPGA собрали даже SoC уровня 486sx (тобишь без математического сопроцессора) AO486, только с производительностью там печально, точнее ПЕЧАЛЬЬЬЬНООО. Базовая частота SoC 30MHz, турбочастота 39MHz.
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
Мне кажется, этот чип и процессор Вашего нетбука — это изделия разных весовых категорий. Многоядерность, гипертрединг (если он у Вас есть), спекулятивное исполнение, всякие там оптимизированные кэши и конвейеры… Для более честного сравнения — берите ноутбук 2000-2001 года (или обычный Пентиум 3 года 1998-ого). Тогда разница будет не столь космическая.
С плюшками у Atom n450 не так много. Это частота 1.6ггц, кэш второго уровня в 512кб, гипертрединг, и современные инструкции, поддержка 64 бит. А вот спекулятивный out of order тут отсутствует, и ограничение в 2гб.

а честное сравнение производительности вы найдете тут
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
Эдиссон не изобрёл лампу накаливания — до него такие лампы производил Лодыгин. Но у Эдиссона был шикарный пиар.
Не только один пиар.
Электромобили изобрёл не Илон Маск, а Ипполит Владимирович Романов, но только Илон Маск смог добиться коммерческого успеха.
Насчёт единичного коммерческого успеха Маска — тут Вы перегибаете. Сто- сто двадцать лет назад электромобили выпускались вполне успешно и многими производителями, пока их бензиновые авто Форда не вытеснили (с аккумуляторами тогда было не очень). Я уж не говорю про такие электромобили как троллейбусы и заводской электротранспорт.
с аккумуляторами и сейчас не фонтан :)
В дополнение к предыдущему оратору — даже если брать современные времена, то другие автопроизводители посмотрели бы на ваш комментарий с огромным недоумением, особенно Renault-Nissan.
Так у Лодыгина совсем другие лампы же были, вроде бы как. В статье сказано, что когда к 81-ому года лампа конструкции Яблочкова стала терять актуальность, потому что лампы Эдиссона были привлекательнее — лампа Лодыгина на тот момент была ещё более морально устаревшей и ещё менее актуальной. И сам принцип горения там был несколько другой
А к тому времени уличное освещение (газовое) уже существовало. Он довел это дело до ума


Ну почему, почему все всегда забывают про Лодыгина? Лампу накаливания изобрёл именно Лодыгин в 1874 году. Эдиссон занялся этим в 1879 (и, насколько я помню книжку, про Лодыгина он знал отлично и торопился скорее запатентовать лампочку в США). В 1890-х Лодыгин предложил для нити накаливания вольфрам и молибден и специальную закрутку спирали. Эдиссон же сделал выключатель и цоколь лампочки. Таким образом, до совершенства лампу доводил не Эдиссон, а Лодыгин.
Судя по Википедии, лампочки Эдисона вытеснили газовое освещение еще до того, как Лодыгин додумался до использования вольфрама для нити накаливания. А в 1906 General Electric честно купила у него патент.
Ну да. Эдиссон эту самую лампочку внедрял на ура.
Только это использование изобретения, а не доведение его до совершенства. Лампочка, которая у нас сейчас есть, придумана Лодыгиным и по его же идее была сделана с вольфрамовой нитью. А это — сама суть лампочки накаливания. От Эдиссона у неё цоколь и форма.

Вот тут хорошая статья из книги про Лодыгина. Есть там и про Эдиссона фрагменты.
Лампочки Эдисона газовое освещение очень долго не могли вытеснить. На самом деле, до сих пор не до конца убили. А уже и газоразрядные есть, и светодиодные. Но газовое освещение все еще применяется спелеологами и туристами, на улицах нескольких городов еще встречается. Шахтеры до сих пор в некоторых странах пользуются (хотя в Европе и США ацетиленовые лампы почти ушли из шахт к 60-м годам).
Вот, кстати, из указанной мной книги. Тут поинтересней википедии будет:

Лодыгин и Эдисон
В 1877 году группа русских моряков едет в США для закупки четырех кораблей («Африка», «Европа», «Азия» и «Забияка») и среди них — мичман Хотинский, везущий за океан калильные лампы Лодыгина и дуговые — Чиколева и Яблочкова — для демонстрации. За пропаганду успехов русской электротехники Хотинского представляют к ордену Анны третьей степени. Но по непонятным причинам именно там, в США, заявка на патент фирмой «Лодыгин и К°» оказалась не оплачена! Хотя оплачена в каждом из мизерных княжеств Германии, в Англии, Франции и даже Индии. И вскоре после отъезда Хотинского из США весной 1879 года Эдисон, до того не занимавшийся электричеством (см. биографическую книгу Дж. Брайана «Эдисон») проводит в лаборатории при огромном стечении народа и прессы свой первый опыт электрйческого освещения лампой накаливания. Опыт не удается — лампа тут же гаснет. Но Эдисон не только талантливый изобретатель, он и энергичный предприниматель. Он спешно подает заявку и вскоре получает патент на лампу накаливания с угольным стержнем, о чем тут же начинают трубить американские газеты, называя его — творцом электросвета. Тринадцать месяцев и сорок тысяч долларов ушли у Эдисона на опыты, в итоге его лампы стали светить несколько часов. Вслед за Эдисоном, сумевшим выпустить пробную партию ламп для продажи, а более — для рекламы «нового изобретения», начинают производить лампы лодыгинской конструкции предприниматели Англии, Франции и Германии. Эдисон, не желая делить прибылей с ними, подает в суд и тратит на тяжбу сотни тысяч долларов. Американские судьи, копнув историю изобретения, узнают о Лодыгине и аннулируют патент Эдисона. Американскому предпринимателю приходится приняться за поиск тела накала, чем-то отличного от найденного Лодыгиным, чтобы иметь юридическое право на подачу заявки вновь. Один из сотен посланных им во все страны света агентов-поисковиков находит японский бамбук… В США заявка принимается, но во многих странах Эдисону выдается патент лишь на усовершенствование в системе электроосвещения. А патент на изобретение в США (за № 369260) выдается лишь через десять лет, в 1890 году, — после окончания срока действия патентов Лодыгина во многих странах.

Интересно, что все эти годы, пока мировая пресса и электротехнический мир спорили о нравственной и юридической стороне дела — кто стыдил, а кто восхвалял Эдисона — Лодыгин отмалчивался — он продолжал работать. Будто знал что-то известное только ему одному, будто видел, что рано считать конструкцию лампы окончательной… И в самом деле — знал и видел, как никто из тех, кто лихорадочно спешил урвать барыши с нового приобретения цивилизации, штампуя угольную лампу с личным клеймом на стеклянных колбах: «Эдисон», «Грамм», «Сван», «Максим».

В Париже встретили его радушно: знали по публикациям И. Фонтена, по многим статьям в газетах и журналах и особенно по нашумевшей в дни Всемирной электрической выставки в Париже в 1881 году статье в журнале «Ла Люмьере электрик», где французские электротехники восстали против присвоения Эдисону титула первооткрывателя электрического освещения. «А Лодыгин? А его лампы? — вопрошал почтенный журнал. — Почему уж не сказать, что и солнечный свет изобрели в Америке?»

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

И вот когда в 1890 году Эдисон, после дорогостоящих судебных процессов с конкурентами, получает наконец-то вожделенный патент на угольную лампу… Лодыгин подает серию заявок на лампы с нитями из железа, платины, вольфрама, осмия, иридия и других металлов и их сплавов! Вот чем он, не участвуя в судах, заканчивает борьбу за свой приоритет в электроосвещении!

Но сам он считает работу с лампой завершенной только после того, как разрабатывает серию электропечей сопротивления и индукционных — для плавки тугоплавких металлов — и берет на них патенты. Всем светотехникам скоро становится ясно — новые лодыгинские лампы вытеснят угольные. Творец тех и других — Лодыгин.

К 1905 году Лодыгин прочно обживается в США. У него теперь есть свой дом, семья, две дочери, Маргарита и Вера, а тоска по родине не ослабевает.

Но возвращение требует больших денег! Их предлагают неизвестные предприниматели за патент на вольфрамовую лампу… Позже выяснилось, что они — подставные лица от фирмы Дженерал электрик, слившейся с Эдисоновской.

Даже в некрологе его заслуги приглушены, затенены, хотя в американской прессе писалось много об его открытиях и одна из статей с перечнем его изобретений называлась «Блистательный Лодыгин», а в газете «Нью-Йорк геральд» еще в 1879 году — во время шумной рекламной компании вокруг Эдисона — прошла статья «Свет Лодыгина».


Этот отрывок написан, по моему ощущению, очень эмоционально. И возникает вопрос — а автор искренне хотел независимо и объективно разобраться в ситуации, или им двигало чувство «наших обидели»? Мне тут видится последнее.

Ну и намек про то, что якобы злодеи помешали оплатить американский патент, вообще критики не выдерживает.

А вообще, вполне возможно, что они оба пришли к идее лампочки независимо. Такое бывает, когда создаются условия появления новой технологии.

В Википедии написано, что первая лампа накаливания была сделана в 1840 году (Де ла Рю). И к появлению современной лампочки приложили руки множество изобретателей.

Там кстати и бамбуковая нить упомянута, которая есть в вашей цитате.
Скорее, он написан живым языком. Это не злодеи помешали оплатить патент, это про него забыли.
К идее они не могли придти независимо — Эдисон точно знал про Лодыгина.

В Википедии написано


Всё верно. Только то, что сделали в 1840 было совершенно непригодно для использования в качестве лампочки (зачем вам лампочка на десяток секунд?). С 1840 десятки человек пытались эту самую лампочку сделать. Но ничего не получалось и стали даже считать, что это невозможно. А вот у Лодыгина получилось сделать лампочку, горевшую с пол-часа.
Ну так значит автор идеи — не Лодыгин, что и требовалось доказать. И не Эдиссон тоже, впрочем. Ценнее всего ведь изобретение, а не доведение реализации до ума, разве нет?
Спасибо за просвещение! У них там и Попова с Зворыкиным и тд на раз подвинуть и забыть очень хотят. А Наса походу потихоньку добирается до чтения наших «Техники молодёжи» и «Науки и Жизни» 20 века.
Не знаю, на что вы намекаете, но аппараты, которые делает НАСА, работают вполне успешно, и наверно между созданием работающего аппарата и написанием статьи в журнале все же есть значительная разница.

Не думаю, что кого-то хотят «подвинуть».
Зворыкина вряд ли — он американец был на тот момент. А вот Катаева все давно забыли. Они, кстати, есть по той ссылке.
Странные бывают люди конечно на хабре (привет, я тоже но по другой части), категорически нетерпимые до иных точек зрения, вплоть до кинуть какашкой в карму )) Человек не переходил на личности, не утверждал что нация или группа лиц Х идиоты и прохиндеи в отличие от других из Y, ответил по теме ветки коммента, — да, отмечающий что советская наука была крутая и копилефтная, — но вроде с чего столько реакции? :)

Ну да, я солидарен идее пагубности копирайта в науке и технике — иначе мир, а ну резко скинулся парой тысяч триллионов нынешних долларов Китаю за хотя бы бумагу, керамику и порох; — копирайт только вредит развитию нашей цивилизации. И деньги в близкой перспективе лишатся смысла и устареют, ведь роботы занимают всё больше и в перспективе заберут практически весь рынок труда, старая идея заработной платы перестанет работать. Тоже немало кто «очень огорчается такое читая», отказывается даже допускать эту совершенно логичную мысль.

Тут дело не в том что, мол «А, дурацкий совковый битард хейтер трудолюбивой америки натыкал коммент, который мне пришлось прочитать и я потратил своё время». Не, то было не об этом, друзья.

NASA безусловно заслуживает уважение тем что делает для нас всех. Но когда обнаруживается что «учёные придумали» что было уже придумано и описано десятилетия назад в тех же журналах и нет никакой ссылки даже в русскоязычных медиа, вот это обидно. Ровно то же и про изобретения — на мой взгляд важно только то кто изобрёл первым и поделился открытием, и возможно кто ещё независимо и параллельно, но не кто первым прибежал в патентное бюро.

У кого-то иной взгляд, он тоже имеет право на жизнь, не проблема. Просто я искренне полагал, что инструменты хабра нужны для несколько иных целей ) Не говоря уж о том, что в комментных баталиях тут всегда стоит читать не «война, иду на вы», а немного [не]заслуженного сарказма, лёгкой доброй иронии и конечно какой-то позиции. Но… )))
Между «описать в журнале» и «спроектировать, провести испытания, исправить все проблемы, получить работающее устройство» все же есть разница. Условно говоря, придумать и описать летающую тарелку я могу, а сделать ее и добиться, чтобы она летала — вряд ли.
Описать — в деталях? Если вы это сделаете, я думаю, это и будет изобретением самой тарелки (при условии, что в её конструкции не будет физически несуществующих или невозможных элементов и процессов).
С этим солидарен конечно, спору нет.
И как пример с тарелкой всё так, но, продолжая тему именно про тарелки — оч интересно было бы, пока даже идей нет рабочих теоретических.
По теме левитирующих «НЛО» объектов, если не против — мысленная гипотеза одна есть. Хоть гравитация и электромагнетизм выглядят как совершенно разные и независимые явления, классические формулы у них одинаковы не считая константы, начиная с электростатики взаимодействия двух зарядов F=kq1q2r→/r3 и гравистатики (гравитации) двух масс F=Gm1m2r→/r3

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

Если движение зарядов, т.е. электродинамика и создаваемые этим объективные эффекты, которые мы называем магнетизмом, изучены достаточно неплохо и ушли во множественное применение в промышленность, в т.ч. периодическое движение зарядов, э/м волны и кванты э/м волны всем знакомы.

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

Так вот. В мире электромагнетизма есть такая штука как сверхпроводимость и связанный с ней эффект выталкивания магнитного поля из тела сверхпроводника.

Мысль-гипотеза для левитирующих (над произвольным по иным параметрам гравитирующим объектом порядка планеты) объектов — возможно механизм левитации должен быть связан с гравитационной сверхпроводимостью и гравидинамикой (маховики релятивистских скоростей?), т.е. левитирование должно достигаться либо выталкиванием внешнего гравитационного поля из внутреннего объёма или созданием противоположно направленного гравистатического (гравитационного) поля.

ещё
Альтернативная идея с каким-либо образом получением отрицательной массы и т.о. отталкиванием по тому же закону гравитирования двух тел видится менее перспективной. Здесь совсем незнакомая территория, в том числе «непонятно чего» в виде отрицательных энергий. С другой стороны, не исключено, что то что сейчас передний край физической науки называет тёмной материей и тёмной энергией на самом деле оно и есть (но может и другое), и в нашей вселенной это обычное дело, стандартная компонента. С которой пока непонятно как управляться.

Там ещё третий вариант есть :) Но как раз уже более известный — про гипердвигатель коконного типа, когда вокруг корабля создаётся своеобразная сфера из вспененного специальный образом вакуума и он разгоняется относительно «нормального» пространства до неограниченных сверхрелятивистских скоростей при отсутствии внутри кокона даже намёка на ускорение. Емнип даже тут на хабре про это было.


Ещё интересная штука на тему есть на мембране www.membrana.ru/particle/3028 про достижения немецкой физической мысли.
А гравитационные волны разве замедляются или поглощаются веществом? Мне кажется, можно считать, что в гравитационном смысле вообще все — сверхпроводники.
Оч сложно судить. Но если эксперимент вроде LIGO позволил засечь гравитационную волну, значит сенсор поглотил какую-то часть энергии этой макроскопической волны, значит о грави-сверхпроводнике уже речи нет. Тем более, надо полагать, в масштабах больших тел типа планеты, определённо составляющие макротело микрочастицы массы взаимодействуют с волной, поглощают её частично и надо полагать переводят во внутреннюю энергию.

В простейшем рассмотрении тело с массой точно не сверхпроводник для гравитации. Например бетонная стена радикально помешает движению гравитационного носителя «автомобиль».

К тому же если в прямом смысле подходить к вопросу сверхпроводника — того что имеет нулевое сопротивление движению носителей, — то как и для зарядов, для масс в качестве «сверхпроводника» внезапно подойдёт идеально чистый вакуум.

Кстати насколько хорошо подойдёт реальный физический вакуум, пусть даже без вот этого всякого солнечного ветра, межзвёздного газа и залётных фотонов и иных реальных частиц, чисто бурление метрик и виртуальных пар частиц типа электрон-позитрон и др. — и на это так решительно сходу не ответить.

Что же касается «нормального сверхпроводника», т.е. некоего вещества в котором шёл бы без потерь процесс движения носителей, то для электронов как мы знаем подходит довольно широкий ряд вещественных сред, а для масс… Для масс как очевидный геометрический случай подходит вращение аксиально симметричного тела — маховик, гироскоп, юла, неважно как назвать. И масса движется, и она сама себе не мешает, и сама из себя создаёт так сказать среду-вещество-сверхпроводник для самой себя. Такой вот своеобразный сам себе сверхпроводник. Лишь бы была решена инженерная задача, чтоб в случае огромных скоростей вращения девайс не разваливался.

Но там у немцев выше намного интересней теория, советую.
> В простейшем рассмотрении тело с массой точно не сверхпроводник для гравитации.

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


Например, каких? Там совсем нет потерь, или они просто очень малы? Просто здравый смысл подсказывает, что идеального ничего не бывает, и какое-то сопротивление среды есть всегда. Иначе уже и вечный двигатель бы существовал, и скорость света была бы достижима для чего-то крупнее частицы…
В случае квантовых эффектов вполне обычное дело что потеря или есть от 1 элементарной штуки, чётко определённого маленького кусочка энергии и более целое количество таких штук, или ровно ноль. В случае электрических сверхпроводников как раз при определённом диапазоне условий (внешнее магнитное поле от 0 до Х и температура сверхпроводника от Т1 до Т2) тот самый ноль потерь. К вечному двигателю конечно отношения не имеет.

Кстати, «вечных» относительно продолжительности жизни человека и более, двигателей/источников энергии существует достаточно немало, начиная со звёзд.
Звучит как-то невероятно. Неужели прямо ноль? Или просто потери так малы, что наши приборы не могут их зафиксировать?

Со звёздами — понятно, я имел в виду «вечный» в смысле бесконечности двигатель, а не в смысле «проработает тысячу лет». И почему не имеет? Вы же сами сказали про «ноль потерь». Двигатель должен совершать какую-то работу, отдавая энергию. Берём источник с очень большой энергией (которая закончится очень нескоро). Тот же атомный реактор подойдёт. И применяем эти знания про «ноль потерь». Должна получиться очень, очень долгая работа источника. Но вроде пока такого не разработано. В чём загвоздка?)
«и температура сверхпроводника от Т1 до Т2» — наверное, речь идёт о сверхнизких температурах? Кажется интуитивно ясно, что при очень низкой температуре частицы движутся медленно, меньше сталкиваются друг с другом, и если мы направим в такой среде поток частиц с большой скоростью, то потеря энергии будет минимальной.

P.S. Я квантовую физику не изучал, пытаюсь понять это явление с позиций обычной школьной программы, сильно не пинайте.
UFO just landed and posted this here
Тогда ещё раз — они равны нулю для отдельной частицы, или в макро-масштабах? Если в макро — это выглядит странно, и вроде бы, ньютоновской механике противоречит (а не должно же).
речь идёт о сверхнизких температурах?
Ну как сверхнизких, до -70 градусов под давлением.
Неужели прямо ноль? Или просто потери так малы, что наши приборы не могут их зафиксировать?
Там примерно следующая ситуация. Сопротивление прямо пропорционально температуре, но в некоторых веществах, при охлаждении ниже определенной температуры, резко падает как минимум на порядки, и становится неотличимо от нуля на современном оборудовании. При этом обладающая самой большой предсказательной силой на сегодняшний день рабочая гипотеза утверждает, что там ровно ноль.
Спасибо, теперь понятнее))

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


А вот это странно. Не поделитесь ссылкой на описание этой теории? Просто уменьшение чего-то на порядки (даже на очень много порядков) — ноль давать не должно. Это ведь деление :)
Исключение — если там деление, сделанное x раз, где x стремится к бесконечности… Но это для физического процесса как-то странновато всё-таки.
Не поделитесь ссылкой на описание этой теории?
Смысл теории заключается в том, что частицы могут находиться не в непрерывном спектре состояний, а в дискретном. И если частица уже находится в минимальном энергетическом состоянии, то отдать часть своей энергии «на трение» она не может. Точно так же, если она находится в одном из наиболее низких состояний, то она не может отдать «на трение» малую часть своей энергии — либо всю, либо ничего. Ссылка
Просто уменьшение чего-то на порядки (даже на очень много порядков) — ноль давать не должно
Я пишу «как минимум, на порядки». Мы не можем в эксперименте отличить 0 от очень маленького значения, и никогда не сможем. Однако, были определенные интересные эксперименты — например, сверхпроводящий контур проводил ток в течение 23 лет без источника тока и без зафиксированной потери напряжения. А график зависимости сопротивления от температуры выглядит вот так (зеленая линия):imageПредположение, что оно там становится в точности равно нулю, проще, чем предположение, что оно там имеет сложную структуру и очень близко к нулю, поэтому оно должно иметь предпочтение в соответствии с бритвой Оккама
Но вариант со сложной структурой кажется вероятнее (интуитивно, так как в мире редко когда что-то устроено настолько просто). Если конечно не принимать во внимание аргументы выше.

А что есть 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-м году, с патентованием Берни Ли Бенбоу спирали, сделанной из спирали (двойная спираль). Таким образом, говорить, что именно Лодыгин «доводил лампу до совершенства» — очень странно. Этот процесс длился многие годы и в нём учавствовало множество людей.
Считали уже на Хабре, нужно $200 млрд инвестиций и 20 лет работы. Как наберете — приходите, я готов возглавить проект.
Под архитектуру x64 малореально что-то сделать, там целый лес патентов, которые надо как-то обходить. ИМХО даже если ввалить в это миллиарды и годы, сделать всю обвязку и чипсет, на рынки Европы/Америки этот процессор не пустят копирасты (найдут повод для исков). Потом, ну сделают классные спецы принципиальную схему проца. А маски для фотолитографии? А производственное оборудование нужного техпроцесса? Нет, это нереально. Китайцы? Всё равно у них техпроцесс слабее. Так что заведомо получится что-то хуже, слабее, более устаревшее. Современные процессоры делаются на острие возможностей науки и техники. Просто так взять и сделать своё и лучше не получится, и чтобы вступить в конкуренцию с Интел и АМД, эту отрасль нужно развивать десятилетиями, вкладывая огромные средства и очень разумно всё делать, не допуская коррупции. А Россия очень отстала по части микроэлектроники. Какой-нибудь микроконтроллер разработать и отдать сделать «в железе» китайцам — да, а сделать что-то уровня KabyLake/Ryzen — нет.
В восхваляемой вами СШАшке не делают современного фотолитографического оборудования. Многие современные процессоры производятся в Китае. Самый быстрый суперкомпьютер до недавнего времени был китайским на китайских процессорах. Архитектура х64 — это вообще что такое?
С.П. Королёв и руководство СССР не смотрели на другие страны, разрабатывая ракеты.
За упаднические настроения Сталин бы вас расстрелял.
За упаднические настроения Сталин бы вас расстрелял.


А Иван Грозный чего бы сделал?
Стоило посмотреть на ник человека: «stalinets».
А я уже не первый раз говорю, что мой ник — хороший индикатор, на который реагируют разные неумные люди. Сейчас вот был хороший пример. =)
С.П. Королёв и руководство СССР не смотрели на другие страны, разрабатывая ракеты.

Вообще-то смотрели, и особенно на Рейх.
Просто, выводы делали правильные.
За упаднические настроения Сталин бы вас расстрелял.

Лично. Потом четвертовал. Вас. За поклёп на вождя. Тоже лично. Почему-то "Сталин" в качестве пугала и прожектёрство идут рука об руку.


не смотрели на другие страны, разрабатывая ракеты.

Очередной несовместимый процессор, который будет не нужен ещё по одному пункту? Отличная идея.


Многие современные процессоры производятся в Китае

Современные по дате производства, но не передовые по сути.

Зато можно получить в процессе кучу знаний, веселья, знакомств и опыта.

Если цель бабла поднять — затея, может, и тухлая. А если развлечься — в самый раз.

Ну, ракеты же у нас частники пытаются делать. И там тоже начинают не с возвращаемых ступеней, а с простейшей летающей пепяки.

Вопрос кто веселье спонсировать будет, а опыт… это в молодые годы стартап за ради одного опыта не так плохо, а потом уже не очень надо — некуда этот опыт через десяток-другой лет применять будет.

Было хорошее мнение :(

И рак вылечат, и на Марс полетят. Я как-то даже не знаю — вы сознательно себе запретили или даже не подозреваете думать о цене такой разработки(дело не только в деньгах) и о бесполезности разработки (а это ведь не только "придумать процессор" — это все его схемы сделать) без производства.


стартапы делают многие тяжелые и трудоатратные вещи

Вы сравниваете постройку сарая с небоскрёбом.

Есть один нюанс. Архитектура x86 — собственность компаний Intel и AMD. Это не открытый стандарт. Создавать совместимые процессоры они не разрешат. То есть в наличии два пути:
1) Хотим, чтобы на нашем процессоре крутилась винда. Тогда нужно создавать процессор, эмулирующий другие процессоры. Чтобы продавать их без признаков архитектуры, а пользователь загружал прошивку и получался x86. То есть банальный FPGA, только на три порядка лучше, чем лучшие из ныне имеющихся. Удачи.
2) Бог с ней, с виндой. Обойдёмся одним Линуксом. Тогда разрабатывать ничего не нужно, потому что уже есть ARM. Но вот чего-то не взлетает стационарный ARM, не взлетает.
"As in the case with Meltdown, we believe our processors are not susceptible to the new speculative execution attack variants called Foreshadow or Foreshadow-NG due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their datacenters, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms."

©

Ключевой кусок фразы "we believe our processors are not susceptible ....".
Мы верим...

«Я хочу верить» отличается от «мы уверены».
И что не так в этой фразе?
Да, пока не удалось обнуражиться уверенны, что нет такой уязвимости у них. До тех пор пока не доказано обратное — этого достаточно.
У слова «believe» есть ещё значение «думать, полагать, иметь мнение». «I believe this is so-and-so» — очень часто использующийся оборот со значением «я считаю, что…», а не «я верю».
С I believe все намного интереснее. Английский язык вообще очень богат тонкостями и нюансами. В данном случае, это плохо переводимый на русский юридический термин, который очень грубо приблизительно значит: «на момент написания у меня не было никаких причин, считать, что это так, но и не было никаких оснований полагать иначе». В американо-британской системе правосудия это гораздо круче, чем «I think», «I trust» или «I am sure» (которые на русский тоже можно перевести как «я считаю»)… для производителя, в данном случае. А для клиента — это плохо. Ибо если что, взять с производителя будет нечего. Производитель пожмет плечами, скажет: «Ну да, на тот момент мы верили, что все так и есть.»
Даже если отбросить такие обтекаемые формулировки типа «we believe our processors are not susceptible». Вы же понимаете, что серебряной пули нет, я не специалист в процессорах, но понимаю, что в ближайшие годы нас ждет снижение производительности из-за появления таких уязвимостей. Сейчас исследователи ломают Intel в силу большей распространенности. Говорить, что уязвимостей нет в AMD пока рано, они скорее всего есть, но необходим другой подход для спекулятивного исполнения нужной последовательности команд, и пока либо не дошли руки, либо отчет не опубликован.

Снижение то такое. Никто не заставляет нас апгрейдиться или ставить программные патчи (если они есть). С другой стороны, вендоры, наверняка все усилия приложат, чтобы производительность не падала в расчёте на доллар. Вплоть до выпуска в убыток, в надежде на Мура.
Поживем увидим. Мне вот сейчас нужно обновлять рабочий ноут. И я не парюсь по поводу того какой там процессор будет и какого вендора (честно говоря, там пока что только Intel). В итоге получу все одинаковое, включая производительность на доллар, на ватт, на уязвимость.
Насколько я понимаю, пока вендоры кардинально не пересмотрят разграничение прав при спекулятивном исполнении мы будем получать или дыры или падение производительности. А поскольку на рынке чипов для ПК всего два игрока, то и заморачиваться не стоит.
Вендоры-то причём тут?
На рынке чипов для ПК больше двух игроков.
Под вэндорами имелись в виду производители чипов. Ветка же начиналась с утверждения, что ставьте AMD чтобы обезопасить себя от уязвимостей.
Их может быть довольно много, но по факту производителей чипов для ПК очень мало, если откинуть такие экзотические варианты, как рабочая станция на power 9, то остается только AMD и Intel, причем первый практически не представлен в верхнем сегменте бизнес-ноутбуков.
Китайские x86-процессоры VIA догнали Intel Core i3 и замахнулись на Core i5
У 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 достаточно дорогих моделей на Яндекс маркете (в Мск).
А чего Вы так радуетесь? Уязвимость позволяет получить доступ не только к SGX (который есть только в последних поколениях), но и к L1 (уже не зависимо от поколения).
А почему вы считаете, что это более опасная атака, если средний компьютер имеет 0 (ноль) анклавов? Что атаковать-то?
средний компьютер имеет 0 (ноль) анклавов


А пруфаните плиз чем-нибудь это утверждение? Выглядит интересно, но спорно в свете 1password того же.
Тем, что это вендор-специфичное расширение, требующее специализированного железа. Я рад, что бета 1password его поддерживает. SGX не используется современными ОС и является довольно специальной фичей (которая так и не попала в мейнстрим).
Читайте внимательнее — уязвимость позволяет получить доступ еще и к L1 кэшу (уже на зависимо от наличия/отсутствия SGX). По крайней мере я так понял из поста.

Судя по зарплатке к ядру исправление для обычных машин довольно простое и надёжное для L1. А вот с виртуальными машинам всё очень плохо. (Англ)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958f338e96f874a0d29442396d6adf9c1e17aa2d&context=40&ignorews=0&dt=0

Помнится о подобном предупреждали в году так 2003 если не раньше. Просто с 2003 года стал интересоваться подобной тематикой.
UFO just landed and posted this here

Тогда точно не буду свой 486й на это новомодное барахло менять.

Они давно уже чёрные.
Гм. А Интел вернет хоть часть денех, потраченных одураченными обманутыми, как оказалось, вкладчиками пользователями?
Если что, это был <sarсasьm /> :)

Если вы покупали процессор напрямую у Интела и в договоре купли-продажи согласовали возврат хоть части денег в случае обнаружения уязвимостей, то вернёт, конечно.

А FDIV разве на P54C был? Вроде, на P5 только.
Вроде на первых P54C тоже. Но даже так, F00FC7C8 жил долго и щЯЯЯсливо

SGX вроде как отличное подспорье для DRM (даже root не может получить доступ к данным программы), а DRM, как известно, плохо...

Эти White Hat ребята сейчас умножат на ноль 10 лет разработки и ускорения ЦП.
Вопрос к людям, хорошо знакомых с темой: возможность эксплуатации этих уязвимостей для получения конкретной выгоды или кражи конкретной информации реалистична? Не теоретически, а вживую, и не на демо-программке?

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.
Слабо оно реалистично в нелабораторных условиях.
Когда у вас сервер под нагрузкой, там с пяток пользователей, и вот один решил что то там захакать… В результате беготни потоков у него ничего не выйдет, в кэше будут какие то разные куски разной памяти, да и с точными замерами времени могут быть разнообразные проблемы.
Когда уже Open Source CPU будет, со свободно разрабатываемой схемотехникой железо-схемотехнико-программистами-инженерами, — 3Dпечатаемый на Open Source Community спецзаводе штучно и партиями за копейки (дешевле известных брендов) без копирайтов-патентов?
Решето? Баг? — Репорт, багфикс, переделать.
В этом ключе. Если ось смогли и кучу софта, почему б и железо не смочь копилефту.
Потому что стоимость распространения и использования информации на порядки меньше того же с любыми физическими предметами

Вы про RISC-V? Уже есть настоящее железо, правда без серийного производства пока дороговато.

Опенсорсных процессоров полно. Напечатать тоже можно поштучно всего за несколько сотен тысяч долларов (shuttle run на не передовом техпроцессе)
Конкурентоспособный по производительности — никогда.
Почему — выше написали.
Напоминаю, что «ось» писалась в те древние времена, когда еще не было истерии вокруг копирайта.

А еще есть спецслужбы.
«Никогда» при нынешних бурлящих технологиях у точки бифуркации цивилизации — это очень смелое слово. :) Never give up!
А что не так со спецслужбами? Открытый дизайн ведь лучше закрытого, если цель — изучить и попытаться взломать
Не так с ними то, что они вполне в силах выкатить требование встроить бэкдор для себя любимых.
А по законам страны компания не имеет права отказать на такое требование?)
От Apple тишина? Ни одного апдейта для системы пока не появилось.
В интернетах находит только новость на 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.
В связи со статьёй и проблемой вообще, вспомнил, что в РФ на армейских РЛС используются мощные модульные промышленные компьютеры Kontron на процессорах от Intel.
UFO just landed and posted this here
В северной корее есть полупроводниковое производство такого уровня?
UFO just landed and posted this here
А можно хоть какую-то ссылку? Пока моё гугление ничего не дало…
UFO just landed and posted this here
Если учесть, что как правило на военке зарубежка идет с отставанием лет в пять, а то и десять, то не вижу проблем от новой дыры для корадуров.
Атаку нужно предотвращать до попадания в компьютер. Все атаки на процессор — это уже пропущенный гол и троллинг производителей.

Т.е. облачным сервисам разогнать клиентов и закрыться?

UFO just landed and posted this here
облачным сервисам не хранить конфиденциальные данные в кеше процессора. И это не зависимо от того, есть уязвимость или нет.
Так они туда в любом случае попадут при обращении к RAM. Есть защита от такого попадания?
у нас телеграм передаёт через интернет конфидециальные данные и никто не может взломать, а вы в память не можете передать? Защита есть всегда. Важно понять нужна ли она?
Всегда — слишком сильное слово, «всегда» бывает не всегда.
Регистров для реализации шифрования на них не хватит, так что в кеш что-то попадёт.
а когда у шпионской программы есть такой доступ, что она может запускать эксплойты на процессорный кеш? Что за абсурд
Телеграм — другая история. Там по сути Диффи-Хеллман и его вариации — когда у каждой стороны своя часть секрета, и генерируется общий, который нельзя узнать путём перехвата «половинок».

А тут что? Мы вообще не канал между процессором и RAM должны защищать (иначе да, можно было бы чипы шифрования встроить в проц и в планку памяти просто-напросто). Тут проблема в том, что процессор не настолько умный, чтобы отличить обращение «легитимного» источника к данным кэша от «нелегитимного» (или даже не так, у процессора нет времени на такие проверки, т.к. это просадит производительность; упреждающие ветки, по которым может пойти алгоритм, надо считать здесь и сейчас, а разбираться некогда). И чем поможет шифрование в нашем случае тогда?
UFO just landed and posted this here
Sign up to leave a comment.