Ретроспектива существующих решений

Идея

Современные операционные системы имеют развитые механизмы разделения пространств задач, пользователей, ресурсов. В свете последних событий (//Spectre//, //Meltdown//) становится понятно, что защитится от ошибок аппаратной части невозможно. В ряде случаев есть все основания полагать, что эта даже не просто какие-то проектные ошибки, а вполне //целенаправленные// закладки.

Неадекватность защит

Даже при наличии аппаратной защиты наличие нескольких миллионов вирусов под все платформы (особенно с интеграцией интернета даже в утюги и глючные стиральные машины) – также понятно, что подобные ухищрения не способны остановить распространение вирусов. Сам факт наличия полусотни антивирусов говорит о том, что удовлетворительного решения проблемы надёжности ИТ не существует.

Что ещё хуже: казалось бы в такой достаточно консервативной отрасли, как автомобилестроение на поверку тоже всё печально – примеры автомобилей, подверженных саморазгону и убивающие своих владельцев – это то, про что мы сейчас достоверно знаем. Но, как известно – 5/6 айсберга скрыта под водой.

И что совсем неприемлемо – людей убивают медицинские аппараты, которые призваны лечить их. Это не просто преступная халатность: это все признаки безумия современного ИТ, который в силу непреодолимого желания извлечения максимальной прибыли не заметил, как убил себя. Да, остатки движения вперёд ещё есть, но уже всем понятно – без принципиального герметичного, “своего” полного стека – все мы стали заложниками абсурдной сложности, которая в рамках текущей ситуации решена быть не может.

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

Современные механизмы защиты памяти искусственно перегружены. Первые машины с виртуальной памятью выполняли оперирование виртуальными страницами на уровне программной реализации лишь с небольшой аппаратной поддержкой. Переход к 64 битам сопровождался одновременным отказом от страничной сегментации памяти. На отдельных платформах сегментация памяти не была предусмотрена с самого начала. Такое решение является вполне закономерным и косвенно указывает на направление развития аппаратных средств. Сам факт наличие механизмов защиты зачастую не является стройным //продуманным// архитектурным решением.

Защита по уровням привилегий процессов начиналась с внедрения многих уровней защиты. Так, начиная с 80386 традиционно в процессоре реализовано 4 кольца защиты. При всём при этом, в памяти аппаратно реализовано //только два// уровня защиты и в таком состоянии это архитектурное недоразумение дожило до наших дней. В то же время, на мобильных платформах Apple// вообще нет никаких колец защиты//, а надёжность платформы в существенной доле достигается через строгие организационные меры. В тоже время, целесообразно считать полный отказ от защиты критических частей системы ошибочным шагом.

Разделение процессов //неизбежный// механизм. Также в многозадачных современных системах (как показывает практика) давно не приветствуется изменяемый на лету код (хотя такое до сих пор встречается), есть явное разделение на статические данные и динамические, как прогрессивный взгляд на организацию вычислительных процессов.

Кроме того, между процессами с целью ускорения обмена данными всё ещё активно используется обмен ссылками на общую память (shared memory). Таким образом создание дополнительных мер по изоляции процессов друг от друга также является достаточно тяжёлым, зачастую //неоправданным// механизмом, так как не гарантирует надёжное разделение данных между процессами.

Поддержание изоляции процессов

Достаточно эффективными методами поддержания целостности сегментов памяти являются быстрые подсчёты контрольных сумм. Например, CRC32 и SHA-256 – одновременное совпадение двух разных контрольных сумм является практически невозможным совпадением. При этом, следует иметь в виду, что динамические данные таким образом контролировать невозможно, что накладывает явные ограничения на поддержание целостности инвариантов памяти (сам исполняемый процесс должен об этом позаботиться). Проверку контрольных сумм следует выполнять перед передачей следующему процессу потока исполнения, после предыдущего. С высокой вероятностью следует отказаться от механизма аппаратной виртуальной памяти, как плохо переносимой. Например, в ОС Линукс из-за особенностей работы различной аппаратуры – пришлось ввести //три уровня// виртуальной памяти. При нехватке физической памяти при необходимости вытеснения неактивной задачи – выгружать сегмент памяти (или его часть), средствами самой операционной системы. С учётом изложенного, надёжной изоляции процессов с непосредственным доступом к памяти добиться невозможно.

Доступ к аппаратуре в современных условиях также крайне сложный процесс. Без уровня аппаратной абстракции работать с огромным парком моделей и их разновидностей аппаратуры всех видов не предоставляется возможным. Даже работа с сетевой картой требует наличия реализованного TCP/IP стека, что вызовет сложности почти непреодолимого размера. Подобный функционал должен быть вынесен в “драйвер” – резидентный модуль ядра ОС, а по сути точно такая же программа, как и все остальные, но находящаяся в недоступном адресном пространстве для всех остальных программ. HAL обеспечивается ядром системы, стандартизирует работу программ.

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

Что с неизбежностью приводит к мысли: прямой доступ к аппаратуре должен быть категорически запрещён.

2023-10-23 11:18:15