С Чего все началось?
А началось все с того, что Сергей Штылев (FIDO Net 2:5020/157.59) в эхо-конференции TALKS.ASM поместил сообщение о возможной ошибке в процессоре 6x86 фирмы Cyrix и привел соответствующий код для ее демонстрации. В этом же сообщении говорилось, что указанный код корректно обрабатывался на Intel Pentium. Особого резонанса это тогда не вызвало, поскольку затронутая проблема не показалась достаточно серьезной. У меня же возникло желание разобраться с ней детально, чтобы самому оценить ее важность. Результат изысканий явно превзошел ожидания и, кроме того, заставил по-новому взглянуть на всю существующую индустрию производства микропроцессоров, что и побудило меня написать этот материал. Итак, для начала приведу искомый код, на котором легко проверить наличие ошибки (можно назвать ее XCHG BUG или “hidden CLI bug”) : model tiny code org 100h start: sti ;разрешим внешние ;прерывания mov bx,80h ;адрес любой ;корректной ссылки на ;память jmp again ;содержимое ;IP должно быть ;больше 11Fh org 120h again: xchg ax,[bx] ;прямая или ;косвенная ссылка ;обязательна mov cx,ax ;использова;ние того же регист;ра обязательно jmp again ;зацикливаем ;последовательность ;команд end start
Выполнение цикла в конце программы приведет к тому же результату, как и в случае выполнения внутри цикла дополнительной команды CLI, (запрещающей внешние прерывания.) Таким образом, указанная последовательность команд позволяет “завесить” любую операционную систему, будучи запущенной на любом уровне привилегий процессора...
Как выяснилось, данная ошибка присутствует во всех ныне существующих процессорах линии 6x86 фирмы Cyrix: 6x86, 6x86L, 6x86MX. То же самое относится и к чипам IBM и SGS Thomson, которые выпускают свои х86-процессоры по лицензионному соглашению с Cyrix. Использование в качестве операционной системы Windows NT, UNIX, OS/2 и всех прочих уже написанных OС не спасет вас от плачевного результата. Различные операционные системы по-разному используют механизмы защиты и разграничения привилегий (где-то - большую их часть, где-то - меньшую), но все эти механизмы бессильны в нашем случае. Однако глупо пытаться обвинить во всем фирму Cyrix, требовать компенсаций и “суда Линча”. Когда этот материал попадет к вам в руки, средства массовой информации уже будут во всю трубить об аналогичной ошибке в процессорах фирмы Intel - Pentium и Pentium MMX (информация об этой ошибке получена из Internet): model tiny code org 100h start: dd 0C8C7F00Fh ;здесь достаточно 4-х ;“магических” байт... end start
Интересно другое: о наличии этой ошибки было известно в определенных кругах еще более года назад, однако никаких мер по ее ликвидации и предотвращению возможных последствий предпринято не было... И если я не привожу в пример аналогичные ошибки в процессорах фирм AMD (K5/K6) и Centaur Technology (WinChip IDT-C6) и т. п., то это еще не значит, что их там нет...
Все х86 “дырявы”, как решето вашей бабушки
Все ли помнят, какой шум поднялся после обнаружения ошибки в сопроцессоре (пресловутый “FDIV bug”) у процессора Pentium фирмы Intel? Дабы “спасти лицо” фирме пришлось бесплатно обменивать всем желающим процессоры с ошибкой на исправленную версию, что “влетело” Intel в сумму с большим количеством нулей. Гораздо меньше людей знают, что не так давно в интегрированных на кристалле сопроцессорах PentiumPro и Pentium II тоже была обнаружена ошибка, но об обмене таких процессоров речи уже не велось. И уж совсем мало тех, кто отчетливо представляет, что все эти случаи - только вершина айсберга. Попадался ли вам на глаза такой термин как errata? Этим термином в микропроцессорной индустрии принято обозначать ошибки дизайна и отклонения от спецификаций, обнаруженные в изделях уже после их выхода в свет.
Как правило, фирма-производитель заводит специальный документ (specification update), в коем без особого энтузиазма ведет подсчет обнаруженных ошибок. Эти ошибки либо исправляются в последующих версиях процессора, либо так и остаются “в кремнии”, т. е., известив (или умолчав) об ошибке, фирма посчитала свою миссию на этом вполне законченной... Как читатель уже догадался, самый длинный список ошибок - у процессоров Intel (не потому, что фирма выпускает самые плохие процессоры, просто они выпускаются гораздо большим тиражом нежели все остальные, а дальше уже начинают работать законы статистики), покороче - у всех остальных. И уже не столь важно, что у одних этот список содержит сотню-другую ошибок, у других - пару-тройку десятков. Важно то, что при действующей технологии разработки/изготовления процессоров изделий без ошибок не может быть в принципе!
Почему же так получается?
Тут в первую очередь следует провести параллель между существующей индустрией производства программного обеспечения и микропроцессорным производством, потому как процессор представляет собой программу, “навечно запечетленную в кремнии”.
Число структурных единиц в процессорах давно уже измеряется миллионами и скоро счет пойдет на десятки миллионов. А попробуйте-ка указать мне на софтверный проект такого масштаба, который был бы написан “с листа” без единой ошибки и сразу? Ошибки становятся все изощреннее, а их поиск - все более дорогим и продолжительным занятием, причем, успех здесь не гарантирован.
Когда “дыра” обнаружена в каком-нибудь Microsoft Internet Explorer’е, то фирма-разработчик может достаточно быстро выпустить исправленную версию продукта, но если она обнаружена в процессоре, мы все остаемся наедине со своим горем. В чем же дело? Неужели нельзя как-то с этим бороться? Можно. Более того, способы эти известны давно, например, тот же частично или полностью загружаемый микрокод процессора, разбиение на малые (легко тестируемые) функциональные блоки и т. п. Проблема в том, что производители процессоров озабочены взаимной “крысиной гонкой” и солидарны друг с другом на почве корпоративного эгоизма. Ситуация такова, что производителя больше всего волнует тот кусок рынка, который он сможет оттяпать у своих конкурентов, потому как на этом рынке вращаются очень большие деньги (загляните, к примеру, в ежегодно публикуемые финансовые отчеты Intel). И в погоне за нашим, читатель, кошельком, в ход идут любые методы - от искусственной патентной борьбы (как у Intel вокруг Slot One) до навязчивой рекламы в прессе и на ТВ (еще немного, и нас будет воротить от “bunny people” так же, как от прокладок “с крылышками”). Нам упорно вбивают в голову, что “300 мегагерц сейчас вам жизненно важны и необходимы”, что “процессор на 64 бита лучше чем на 32, а на 128 лучше, чем на 64”, что “ММХ - это круто, а ММХ2 будет еще круче”, и так далее, до бесконечности. Для производителя остановиться в “крысиной гонке” за мегагерцы, чтобы предпринять меры по изменению технологии для получения “безошибочных” процессоров, смерти подобно, потому как его место на рынке тут же займет другой, менее щепетильный в этом вопросе. А расплачиваться придется потребителю, т. е. нам с вами, дорогой читатель. Кто из производителей х86-процессоров сможет сейчас дать гарантию, что его изделие не имеет ошибок в защите и разграничении привилегий доступа к данным? Никто! А если таковой и обнаружится, я первый готов заключить с ним пари на наличие подобной ошибки. Представьте себе, что вы пришли купить автомобиль и спрашиваете продавца, надежно ли работают тормоза на максимальной скорости и не было ли случаев взрыва двигателя? А тот вместо ответа начинает рассказывать вам про замечательную обивку салона, чудесную механизированную пепельницу и прочие причиндалы. Думаю, что в лучшем случае такого продавца сочтут очень странным, в худшем - сумасшедшим, но почему тогда мы, компьютерщики, так легко позволяем подобное отношение к нам в микропроцессорной индустрии?
Вместо заключения
Для того чтобы понять, что с отечественной атомной индустрией что-то неладно, потребовался Чернобыль. Американцам понадобился Challenger, чтобы прояснить ситуацию в аэрокосмической промышленности, а аховое положение в Internet и средствах/системах компьютерной безопасности продемонстрировал пресловутый “червяк Морриса” (“Morris Worm”). Согласны ли вы и дальше быть заложником существующей микропроцессорной индустрии и жить на пороховой бочке?
Александр Коносевич
К автору можно обратиться по E-mail : eshslabs@omsk.net.ru.
