LINUX.ORG.RU

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

 , , , z386,

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

6

6

Энтузиасты смогли успешно извлечь и дизассемблировать микрокод процессора Intel 80386, который из-за отсутствия документации считался «чёрным ящиком». Бинарный образ микрокода был воссоздан с привлечением AI по фотографиям кристалла в высоком разрешении, а логика работы разобрана через трассировку соединений на кристалле. Постепенно были определены структура микрокоманд (μ-ops), поля, порядок исполнения и маркеры конца инструкций. Наработки проекта опубликованы на GitHub как общественное достояние.

Выявлено, что в CPU 80386 каждая инструкция полностью исполняется через микрокод, в то время как в 8086 и современных процессорах часть инструкций обрабатывается напрямую. Кроме того, в отличие от процессоров 8086, в 80386 микрокод не реализует алгоритмы напрямую, а в основном настраивает аппаратные ускорители (умножитель, делитель, быстрый сдвиг, PTU (Protection Test Unit)).

В ходе исследования также была обнаружена возможная проблема с безопасностью при обработке битовой карты прав доступа к вводу/выводу (IO permission bitmap): при 4-байтовом обращении к портам проверялись биты прав доступа только для первых 3 байтов, а доступ к 4-му байту не проверялся, что теоретически допускало обращение к аппаратным регистрам, доступ к которым должен был быть запрещён.

На основе опубликованного микрокода разработан открытый CPU z386, реализованный на языке SystemVerilog и работающий с использованием FPGA. Вместо реализации каждой инструкции в форме отдельного RTL (wikipedia.org) (Register-transfer level) в z386 реализованы аппаратные структуры, которыми управляет оригинальный микрокод. Производительность подготовленной реализации соответствует быстрому 386 ПК (~70MHz). Под управлением z386 удалось успешно запустить DOS 6/7, DOS/4GW, DOS/32A и игры, такие как Doom и Cannon Fodder.

>>> Подробности на opennet



Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 1)

Под управлением z386 удалось успешно запустить

Если z386 полностью программно совместим, то что значит удалось успено запустить? А что-то неуспешно? Но тогда почему.

praseodim ★★★★★
()
Ответ на: комментарий от praseodim

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

VIT ★★
()

Когда-то очень давно я увлекался подобными вещами. Безо всякого ИИ.

sparkie ★★★★★
()

Главное что начало положено))

REDDERa
()

такие как Doom

У меня был живой 386 на 33 МГц, дум там еле работал, но это меня не останавливало - маленькое окошко либо low detail и вперед ^_^ На 70 МГц вряд ли сильно лучше, но всё же лучше

Мои типичные проекты под FPGA они в 15-20 раз больше ресурсов занимают, а 386 влез в такой объем логики? Наверное он не так сложен спустя 40 лет кажется, но для тех времен для тех средств проектирования и верификации это должно быть серьезное достижение. Не преуменьшаю достижение авторов проекта, проект z386 крут, но сейчас интереснее изучать строение RISC-V и работать именно с ним

I-Love-Microsoft ★★★★★
()

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

EvAn
()
Ответ на: комментарий от VIT

Крутизна немеряная, лет бы 30 назад этой информации цены бы не было.

а для чего?
если тогда уже во всю были х86 шестого поколения своих разработок у всех кому не лень

madcore ★★★★★
()

Окей, смогут ли китайцы выпускать при этом x86 совместимые процессоры без лицензирования? Как-то сомневаюсь

One ★★★★★
()
Ответ на: комментарий от praseodim

Если z386 полностью программно совместим, то что значит удалось успено запустить? А что-то неуспешно? Но тогда почему.

Значит, что вряд ли делали настоящую полную верификацию, но методом тыка что-то запустили. Вот вопрос, что не удалось запустить, хороший.

aiqu6Ait ★★★★★
()

В ходе исследования также была обнаружена возможная проблема с безопасностью при обработке битовой карты прав доступа к вводу/выводу (IO permission bitmap): при 4-байтовом обращении к портам проверялись биты прав доступа только для первых 3 байтов, а доступ к 4-му байту не проверялся, что теоретически допускало обращение к аппаратным регистрам, доступ к которым должен был быть запрещён.

Сейчас взломы понесутся.

spqr ★★★★
()
Ответ на: комментарий от VIT

Эльбрус было бы легче делать.

с чего бы?
Бабаян тогда регулярно докладывал, что процессор готов и всегда производительнее текущих флагманов интел в какую-то константу раз
осталось только сколько-то лярдов, чтобы отлить в кремнии
тем более, он же говорил, что это интел воровала их наработки

тут интереснее, что в 386 был vliw, если я верно понял, а потом они перешли на risc

madcore ★★★★★
()
Ответ на: комментарий от madcore

Не нужно понимать буквально. Я не имел в виду конкретно Эльбрус. Я имел в виду случаи, где надо своё, но хорошо бы совместимое, не надо шестого поколения, но и не risc-v или z80.

VIT ★★
()
Последнее исправление: VIT (всего исправлений: 1)
Ответ на: комментарий от VIT

разработать х86-совместимый проц тогда не было какой-то проблемой, всё упиралось в лицензию
возможно, не было проблемой ещё в конце 80-х, во времена судебных тёрок с амд

madcore ★★★★★
()
Ответ на: комментарий от VIT

riscv-то нынешний покруче процессора середины 80-х годов будет.

Те экземпляры riscv64 на которых я пару лет назад гонял регрессионные тесты постгреса по производительности соответстввали примерно Pentium III. И это надо сказать были далеко не самые флагманские на то время платы.

А что до совместимости - gcc на этот процессор портировали? Да. LLVM портировали? Да, rustc есть? тоже наличествуют. Ну и зачем нужна какая-то еще совместимость, если для этой архитектуры есть и ubuntu, и debian?

Хотя, пожалуй, будущее за loongarch64.

vitus ★★
()
Ответ на: комментарий от vitus

Хотя, пожалуй, будущее за loongarch64.

там тоже лицензия

madcore ★★★★★
()
Ответ на: комментарий от madcore

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

VIT ★★
()
Ответ на: комментарий от madcore

были же даже у нас КМ1810ВМ86М

Серийно выпустить аналог 286-го у нас так и не успели. Несколько лет назад читал, что искали сейчас экземпляры для музея, смогли что-то найти из чипсета для 286-го, но сам процессор увы. Про 386-й я только слышал байки, что были попытки его скопировать, но столкнулись уже с серьезными проблемами в технологии, поэтому хотели составной из двух чипов сделать.

praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 2)
Ответ на: комментарий от praseodim

конкретно КМ1810ВМ86М - это не 286, что-то типа 186
а 286 да, только опытные образцы были

madcore ★★★★★
()
Ответ на: комментарий от VIT

30 лет назад оригиналом были pentium pro и pentium mmx

madcore ★★★★★
()
Ответ на: комментарий от vitus

Со скоростью вычислений всё давно уже хорошо. Вот с надежностью - куда хуже. А у 386 есть то, чего нет ни у risc ни у loongarch, ни у arm - сегментный механизм защиты памяти. Помещаем массив в отдельный сегмент и каждое обращение к нему будет аппаратно проверяться на соответствие границам. Передача управления тоже возможна только в заранее объявленные точки, а не в произвольное место в пространстве памяти процесса. Это тоже проверяется аппаратно. Ни то ни другое задействовать автор линукса не осилил ибо весьма сложно. А вот некоторые дос-экстендеры это умели и у меня был практический опыт написания кода под них. И действительно - чуть в коде ошибка как он начинает падать именно на аппаратных исключениях.

watchcat382 ★★
()
Ответ на: комментарий от VIT

Хотя, пожалуй, будущее за loongarch64.

Почему?

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

watchcat382 ★★
()
Ответ на: комментарий от madcore

зачем 30 лет назад делать лучше, чем 386?

Проц без софта - не особо интересен. А 30 лет назад софт был по большей части только под х86. Это сейчас развелось куча хорошего софта, переносимого на уровне исходных текстов.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Я не склонен отдавать технологическое первенство только по национальному признаку. Если эта архитектура имеет явное преимущество над подобными многоядерными архитектурами от Apple, Google, Amazon, Microsoft, или Nvidia, я бы хотел об этом узнать.

VIT ★★
()
Ответ на: комментарий от watchcat382

сегментный механизм защиты памяти.

это тяжёлое наследие защищённого режима 286, ничем оно не лучше страничной защиты, а хуже
а если тебе кажется, что под каждый массив править gdt/ldt и жонглировать селекторами безопаснее, то флаг в руки

Ни то ни другое задействовать автор линукса не осилил

осилил, см. реализацию tcbhead_t

madcore ★★★★★
()
Ответ на: комментарий от VIT

архитектура имеет явное преимущество над подобными

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Да, как и всё китайское, они вероятно будут немного похуже западного.

это миф
качество у китайцев ровно такое, сколько заложено в цену

madcore ★★★★★
()
Ответ на: комментарий от madcore

ничем оно не лучше страничной защиты

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

осилил, см. реализацию tcbhead_t

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

watchcat382 ★★
()
Ответ на: комментарий от madcore

Качество у китайцев - достаточное для большинства применений. К примеру давно уже никому не нужны предметы одежды, которые можно передать по наследству детям,а то и внукам. Хотя еще несколько десятков лет назад такое вполне практиковалось. Бытовая техника, способная проработать лет тридцать - тоже не очень-то востребована из-за ее цены. Хотя такая еще существует в небольшом количестве. В случае компьютеров наверно будет ближе аналогия с инструментом. Зачем покупать дико дорогой профессиональный инструмент (допустим шуруповерт) если не работаешь мастером-отделочником по восемь часов ежедневно? Обычному хоббисту ресурса дешевого китайского шуруповерта хватит на годы. Вот и с процами также будет - большинство будет покупать китайские потому что их производительности будет им достаточно.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

ошибки переполнения буферов и/или передачи управления куда-нибудь не туда - находят просто регулярно.

Сейчас shadow-stack и соответствующие инструкции есть в x86 для контроля корректности вызовов-возвратов.

algo
()
Ответ на: комментарий от watchcat382

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

madcore ★★★★★
()
Ответ на: комментарий от algo

Как я уже выше сказал - в x86 много чего полезного есть. Вот только ОС это плохо используют.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Китайские процы будут иметь главное преимущество - ценовое.

Для некоторых потребителей они будут иметь всё тот же недостаток, они китайские. Нужно что-то большее чем цена.

VIT ★★
()
Ответ на: комментарий от madcore

все потребности покрывает страничная защита

Увы - нет. Насколько нет - мы видим по количеству постоянно находимых ошибок переполнения всяческих буферов. В случае помещения буфера в отдельный сегмент переполнить его просто не получится - сработает аппаратное исключение и ошибка будет замечена.

минус - грануляция 4К

И это тоже.

фар-указатель на каждый чих? да от такого даже компиляторы с ума сойдут

Те, которые это умели - почему-то с ума не сходили. Повторюсь, что я лично когда-то писал код под дос-экстендер и пользовался этими возможностями. Всё работало. Более того, линкер от gcc сегменты умеет. Просто это не используется в линуксе.

будет сложение обнаруживать ошибки при статическом анализе

Вот тут спорить не буду ибо не силён в алгоритмах статического анализа.

сломанную арифметику указателей

В пределах сегмента она вполне работает. А за пределы сегмента и не должна. Попытка прибавить к указателю столько, что он вылезет за границу сегмента - должна вызывать ошибку.

это сильно медленнее

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

А миф о медленности сегментного механизма пошел вот как раз от первых 386 - потому что у них не было эффективного кэширования и за каждым обращением в таблицы они лазали в RAM. Даже уже у последних 386(и всех последующих) обращения к таблицам кэшировались. Но миф о медленности уже успел возникнуть и растиражироваться в научно-популярной литературе.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Передача управления тоже возможна только в заранее объявленные точки, а не в произвольное место в пространстве памяти процесса.

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

GAMer ★★★★★
()
Ответ на: комментарий от VIT

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

Нужно что-то большее чем цена.

В случае процов - важно наличие достаточного ассортимента софта, на них работающего. Сейчас с этим всё стало хорошо - написано очень много всего, переносимого на уровне исходных текстов.

watchcat382 ★★
()
Ответ на: комментарий от GAMer

Это сейчас много где

Что и говорит о нужности этого функционала, а не как там выше утверждали что якобы никому не надо ни проверки границ массивов ни точек входа.

Но где это используется существующими ОС и софтом?

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

watchcat382 ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.