DOS4/GW — это бесплатная ограниченная версия экстендера DOS/4G, которая поставлялась с набором компиляторов Watcom C/C++. Большая часть экстендеров для DOS реализовывало спецификацию DPMI 0.9 (некоторые поздние — 0.9 и 1.0), и по спецификации являлись DPMI host'ами, т.е. программами, предоставляющими интерфейс DPMI другим программам — клиентам (которые с его помощью получали доступ к защищенному режиму процессора, 32-битному режиму, плоской адресации памяти и другим плюшкам, недоступным изначально в основной ОС — DOS). На данный момент существует свободная и открытая альтернатива DOS4/G* — DOS/32A, если вам интересны подробности, можете почитать документацию к ней.
Именно поэтому управление питанием и частотами уже довольно давно выполняется софтом, а не железом, что у Intel (ICC стал частью ME с 7.х (Sandy Bridge+), PMC вынесли в отдельную от МЕ прошивку в 11.х (Skylake+), что у AMD (SMU, Piledriver+). VRM обычно не имеет своей полноценной прошивки, вместо этого он подключен к одной из системных шин вроде SMBUS, и управляется PMC/SMU напрямую.
Что означает магическая фраза «инициализация оборудования»?
После ресета или выключения питания все железо оказывается в начальном состоянии, в котором оно зачастую работать не может, и нуждается в дополнительной настройке прежде, чем его можно будет начать использовать. Вот эта настройка и называется инициализацией, т.е. приведением железа в его начальное рабочее состояние. Инициализация простого железа типа COM-порта укладывается в несколько строк на С, а вот железо посложнее, память оперативная, к примеру, или видеокарта — это уже совсем другой разговор и там иногда нужны десятки тысяч строк кода, чтобы железка заработала как задумано. Углубляться в эту тему можно бесконечно, и там целая отрасль знаний (platform bring-up) за этой простой фразой прячется.
Куда именно сохраняются и как именно применяются «настройки биоса» (путаница UI с собственно механизмом работы)?
Раньше сохранялись в CMOS SRAM, специальной энергозависимой памяти с батарейным питанием, но потом настроек стало достаточно, чтобы чипы SRAM такого объема стали слишком дорогими, и их заменили на SPI NOR (у которых 100к циклов перезаписи и с которых можно загружаться напрямую). Я уже писал про то, зачем нужна, и как устроена NVRAM вот тут.
БИОС именно из ПЗУ исполняется очень короткое время в самом начале, когда еще нет инициализированы ни оперативная память, ни L2 cache. Как только память доступна, прошивка копируется в нее и исполняется уже оттуда.
Как ОС выполняет 16-битный код: через трамплины, т.е. ОС вызывает прерывание (потому что 16-битный сейчас только старый интерфейс BIOS Interrupt Call), обработчик переводит процессор в 16 битный режим, выполняет 16-битный код БИОСа, затем возвращает режим в оригинальный, и передает управление вызывающему коду. Вся эта прыготня довольно медленная, и нужна исключительно системам, которые либо не умеют сами использовать оборудование (и потому полагаются на код БИОСа), либо не догадываются, что оборудования на самом деле нет (т.е. оно эмулируется БИОСом целиком).
Как ОС использует оборудование: качественные ОС ничему вообще не верят, и оборудование стараются переинициализировать самостоятельно, не надеясь на милость авторов БИОСа.
Что там с маппингом памяти и DMA?
А что с ними? В БИОСе была карта памяти e820, которую ОС нужно было использовать, чтобы не возникало конфликтов между памятью ОС и памятью БИОСа и устройств. В UEFI есть своя карта памяти, и нормальный аллокатор, успешно скрывающий большую часть управления памятью от разработчика UEFI-драйверов и загрузчиков. Про DMA там отдельная большая тема с IOMMU и Bus Mastering'ом, про которую нужно книгу писать, а не коммент.
Как именно процессор умудряется проснуться от сети (и от чего именно в сети)
Процессор просыпается не от сети, а от сигнала сетевого чипа (точнее, двух чипов, NIC и PHY, первый из которых спал ровно настолько, чтобы по прежнему следить за пакетами, а второй не спал вообще, а работал от дежурного напряжения). Wake-on-LAN — это специальный пакет с MAC-адресом, и если его прием настроен, то по его приходу NIC пошлет процессору сигнал по отдельной физической ноге.
Как биос умудряется доступиться до tftp при загрузке по сети?
Так же, как и любая другая ОС, у него либо в самой прошивке стек сетевых драйверов, либо весь стек вкомпилен внутрь PXE-загрузчика.
Если детали реально интересны, могу посоветовать литературу по firmware development и platform bring-up, а также чемодан даташитов на конкретное железо.
Значит, что-то все-таки делаете неправильно, или замыкаете не ту ногу, или делаете это слишком поздно. Посоветую отключить батарею, замкнуть, воткнуть зарядное, включить и загрузиться в UEFI Shell, все должно работать. Механизм этот чипсетный, и потому отключен быть не может (прошивка может отказаться стартовать с ним, но это другая история).
Все так делаете, только смотрите не туда немного.
Проверять надо той же утилитой MEInfo, только с параметром -FWSTS, если все сработало верно, то ME окажется отключенным, и дальше уже через Intel FPT можно шить и дескриптор, и регион МЕ. При этом все утилиты (в том числе MEInfo) продолжат рапортовать о том, МЕ защищен от записи, просто защита эта перестанет работать.
Thunderbolt, uh, does not expose PCIe lanes directly. Thunderbolt is an MPLS-like packet switching network that can encapsulate PCIe TLPs over a PHY and MAC without a spec, chips without documentation, and software with barely any support.
Раскрою немного мысль уважаемой WQ: Thunderbolt — это не PCIe, это хитрый способ получить доступ к нему. С точки зрения пользователя разницы немного, а вот в деталях разница колоссальная, к примеру, весь код hot plug и enumeration у ТБ свой собственный, и зачастую сделан настолько невыносимо отвратительно, что страшно становится.
SPISPY отличный проект, конечно, но пока что до коммерческих решений еще далеко довольно. Идея использовать DRAM для хранения прошивки интересная, но они с ним мучаются сейчас и в будущем продолжат мучаться дальше.
Тем временем, вот этому эмулятору скоро исполнится 10 лет, он отлично работает все эти годы в любых ОС (через эмуляцию USB Mass Storage), умеет логировать операции в файл на самом себе, и стоит не сказать, чтобы очень дорого.
Тем не менее, я очень рад, что появляются открытые аналоги профессиональных инструментов (пусть даже они сейчас на начальном этапе), потому что от этого выигрывают все.
Опять же, как будто кто-то ожидал что-то иное… Даешь всяким гражданам с горы доступ к ядру ОС — не удивляйся, что там теперь вакханалия, потому что граждане с горы решают свои собственные задачи максимально прямым и эффективным для них способом, а понять, что этот способ ломает всю модель безопасности — это надо быть специалистом по ней, и знать как эта самая модель выглядит, а специалисты эти — дорогие, и не хотят идти к китайским ОЕМам за миску риса.
Дорого это все очень, и продать потом очень трудно, потому что для обычного пользователя хватает «у нас точно все безопасное, мамой клянемся!» и «смотрите зато какая у нас RGB-подсветка моднючая!».
Непонятно, что именно непонятно.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.
Подписываешься на твиттер Дональда Трампа, и выставляешь все, что можно продать быстро, после очередного твита про тарифы и торговую войну. Вероятность успеть вовремя — довольно высокая, но таки да, математика предлагает страдать — значит надо страдать!
В период между 1926 и 2009 года индекс S&P 500 падал на протяжение 24 из 84 лет (25% времени).
Статистика… То же самое предложение можно переформулировать вот так: 75% времени индекс рос, так что вместо попыток выиграть в рулетку у рынка, лучший способ заработать на бирже — купить каких-нибудь VTSAX или SWPPX сегодня, и держать их до самой пенсии, докупая их же на все свободные деньги по ходу. Никаких структурных продуктов, минимальные комиссии и брокеров, и управляющих фондом (не 1% в год, как на российском фондовом рынке, а 0.02%-0.05%, т.е. ~$50 затрат за 10 лет на каждые $10k вложенных), а в случае окончательного и бесповоротного карачуна всего фондового рынка (еще хуже, чем крах 1929 года) рухнут и бонды, и REITы, и деривативы, и сама мировая экономика, вместе с зарплатами, и готовиться к такому надо закупкой спичек, гречки и тушенки, а не балансировкой портфеля в сторону менее рисковых активов.
Постараюсь отсоветовать, у меня были NUC7i3/5 с KabyLake, и оба не подошли по разным причинам. Даже i5 (не говоря про i7) сильно шумит и троттлит уже при средней нагрузке, а i3, хоть и не шумит, зато задушен насмерть и пользоваться современной Windows 10 и тяжелым софтом (Visual Studio, например) очень трудно.
Все еще сижу на NUC7i3, но уже морально готов заменить его на MacMini 2018 года (еще не заменил, потому что домашний ПК нужен все меньше).
Авторы преподнесли проблемы с имплементацией отдельных библиотек как проблемы с самим алгоритмом. Очень странно слышать такие вещи от людей которые пытаются учить людей криптографии.
В прикладной криптографии (которая внутри «разработки ПО», а не «математики») нет собой разницы между алгоритмом и реализацией алгоритма, потому что никаких других алгоритмов, кроме реализованных или самостоятельно разработчиком, или разработчиками библиотек, там нет. И атакуют там именно реализации.
Так вот с точки зрения прикладного криптографа RSA — действительно плохой алгоритм, потому что его практически невозможно «держать правильным образом», о чем авторы статьи и сообщают. И не только они, вот отличный пример того, как недостатки криптографических API приводят к тому, что 70% криптографического кода имеет серьезные проблемы, которые никто из разработчиков не в состоянии заметить.
Любые работающие технологии безопасности должны быть простыми как палка, и при этом стараться максимально усложнить свое неправильное использование (при помощи системы типов, статического анализа, или других инструментов), а нынешние (а тем более прошлые) реализации RSA в большинстве своем похожи скорее на OpenSSL, чем на упомянутый авторами libsodium.
Именно так из звучит, и такую статью тоже написать не грех.
Очень много областей, где Си давно пора перестать использовать именно поэтому, но его продолжают там использовать, а когда в очередной раз приходит атакующий и все разламывает в клочья после получаса реверса — винят кого угодно, только не инструмент кривой.
Дали коновалам в руки скальпель, а теперь удивляются, что вся комната в крови…
Если посмотреть на профиль автора на SO, то становится понятно, почему за 30 лет работы (неясно откуда взявшиеся, потому что он ВУЗ закончил в 2004 году) он так и не научился пользоваться отладчиками — просто не нужно было, все проблемы решались и без них.
Это не означает, что проблем не было, это всего лишь означает, что эти "проблемы с медведями" решали совсем другие товарищи за совсем другие деньги.
Ответ сильно зависит от того, что вы на вашем процессоре делаете.
Если у вас там конечный автомат на десяток состояний, то вы его отлично отладите и так, а если у вас там РТОС на 50 процессов, активно работающая с внешним оборудованием, то система ваша явно с недостатком, т.к. даже на одну ногу можно завести отладочный интерфейс (debugWIRE у Atmel), а если отвоевать еще одну, то хватит на полноценный Test Access Port по cJTAG или SWD.
Раньше сохранялись в CMOS SRAM, специальной энергозависимой памяти с батарейным питанием, но потом настроек стало достаточно, чтобы чипы SRAM такого объема стали слишком дорогими, и их заменили на SPI NOR (у которых 100к циклов перезаписи и с которых можно загружаться напрямую). Я уже писал про то, зачем нужна, и как устроена NVRAM вот тут.
БИОС именно из ПЗУ исполняется очень короткое время в самом начале, когда еще нет инициализированы ни оперативная память, ни L2 cache. Как только память доступна, прошивка копируется в нее и исполняется уже оттуда.
Как ОС выполняет 16-битный код: через трамплины, т.е. ОС вызывает прерывание (потому что 16-битный сейчас только старый интерфейс BIOS Interrupt Call), обработчик переводит процессор в 16 битный режим, выполняет 16-битный код БИОСа, затем возвращает режим в оригинальный, и передает управление вызывающему коду. Вся эта прыготня довольно медленная, и нужна исключительно системам, которые либо не умеют сами использовать оборудование (и потому полагаются на код БИОСа), либо не догадываются, что оборудования на самом деле нет (т.е. оно эмулируется БИОСом целиком).
Как ОС использует оборудование: качественные ОС ничему вообще не верят, и оборудование стараются переинициализировать самостоятельно, не надеясь на милость авторов БИОСа.
А что с ними? В БИОСе была карта памяти e820, которую ОС нужно было использовать, чтобы не возникало конфликтов между памятью ОС и памятью БИОСа и устройств. В UEFI есть своя карта памяти, и нормальный аллокатор, успешно скрывающий большую часть управления памятью от разработчика UEFI-драйверов и загрузчиков. Про DMA там отдельная большая тема с IOMMU и Bus Mastering'ом, про которую нужно книгу писать, а не коммент.
Процессор просыпается не от сети, а от сигнала сетевого чипа (точнее, двух чипов, NIC и PHY, первый из которых спал ровно настолько, чтобы по прежнему следить за пакетами, а второй не спал вообще, а работал от дежурного напряжения). Wake-on-LAN — это специальный пакет с MAC-адресом, и если его прием настроен, то по его приходу NIC пошлет процессору сигнал по отдельной физической ноге.
Так же, как и любая другая ОС, у него либо в самой прошивке стек сетевых драйверов, либо весь стек вкомпилен внутрь PXE-загрузчика.
Если детали реально интересны, могу посоветовать литературу по firmware development и platform bring-up, а также чемодан даташитов на конкретное железо.
Проверять надо той же утилитой MEInfo, только с параметром -FWSTS, если все сработало верно, то ME окажется отключенным, и дальше уже через Intel FPT можно шить и дескриптор, и регион МЕ. При этом все утилиты (в том числе MEInfo) продолжат рапортовать о том, МЕ защищен от записи, просто защита эта перестанет работать.
Раскрою немного мысль уважаемой WQ: Thunderbolt — это не PCIe, это хитрый способ получить доступ к нему. С точки зрения пользователя разницы немного, а вот в деталях разница колоссальная, к примеру, весь код hot plug и enumeration у ТБ свой собственный, и зачастую сделан настолько невыносимо отвратительно, что страшно становится.
Тем временем, вот этому эмулятору скоро исполнится 10 лет, он отлично работает все эти годы в любых ОС (через эмуляцию USB Mass Storage), умеет логировать операции в файл на самом себе, и стоит не сказать, чтобы очень дорого.
Тем не менее, я очень рад, что появляются открытые аналоги профессиональных инструментов (пусть даже они сейчас на начальном этапе), потому что от этого выигрывают все.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.
Статистика… То же самое предложение можно переформулировать вот так: 75% времени индекс рос, так что вместо попыток выиграть в рулетку у рынка, лучший способ заработать на бирже — купить каких-нибудь VTSAX или SWPPX сегодня, и держать их до самой пенсии, докупая их же на все свободные деньги по ходу. Никаких структурных продуктов, минимальные комиссии и брокеров, и управляющих фондом (не 1% в год, как на российском фондовом рынке, а 0.02%-0.05%, т.е. ~$50 затрат за 10 лет на каждые $10k вложенных), а в случае окончательного и бесповоротного карачуна всего фондового рынка (еще хуже, чем крах 1929 года) рухнут и бонды, и REITы, и деривативы, и сама мировая экономика, вместе с зарплатами, и готовиться к такому надо закупкой спичек, гречки и тушенки, а не балансировкой портфеля в сторону менее рисковых активов.
Все еще сижу на NUC7i3, но уже морально готов заменить его на MacMini 2018 года (еще не заменил, потому что домашний ПК нужен все меньше).
В прикладной криптографии (которая внутри «разработки ПО», а не «математики») нет собой разницы между алгоритмом и реализацией алгоритма, потому что никаких других алгоритмов, кроме реализованных или самостоятельно разработчиком, или разработчиками библиотек, там нет. И атакуют там именно реализации.
Так вот с точки зрения прикладного криптографа RSA — действительно плохой алгоритм, потому что его практически невозможно «держать правильным образом», о чем авторы статьи и сообщают. И не только они, вот отличный пример того, как недостатки криптографических API приводят к тому, что 70% криптографического кода имеет серьезные проблемы, которые никто из разработчиков не в состоянии заметить.
Любые работающие технологии безопасности должны быть простыми как палка, и при этом стараться максимально усложнить свое неправильное использование (при помощи системы типов, статического анализа, или других инструментов), а нынешние (а тем более прошлые) реализации RSA в большинстве своем похожи скорее на OpenSSL, чем на упомянутый авторами libsodium.
Очень много областей, где Си давно пора перестать использовать именно поэтому, но его продолжают там использовать, а когда в очередной раз приходит атакующий и все разламывает в клочья после получаса реверса — винят кого угодно, только не инструмент кривой.
Дали коновалам в руки скальпель, а теперь удивляются, что вся комната в крови…
Это не означает, что проблем не было, это всего лишь означает, что эти "проблемы с медведями" решали совсем другие товарищи за совсем другие деньги.
Если у вас там конечный автомат на десяток состояний, то вы его отлично отладите и так, а если у вас там РТОС на 50 процессов, активно работающая с внешним оборудованием, то система ваша явно с недостатком, т.к. даже на одну ногу можно завести отладочный интерфейс (debugWIRE у Atmel), а если отвоевать еще одну, то хватит на полноценный Test Access Port по cJTAG или SWD.