После роста производительности, самое большое достоинство одноуровневой памяти — всеобъемлющая возможность совместного доступа. Впрочем, это и самый большой ее недостаток. Если каждый пользователь системы имеет доступ к большому единому адресному пространству, требуются гарантии от несанкционированного доступа к тем объектам или информации, на которые у этих пользователей нет прав. В главе 5 мы говорили, что такая защита осуществляется в AS/400 указателями. Давайте теперь рассмотрим указатели и их функции более подробно.

Итак, доступ к объекту MI обеспечивается путем разрешения указателя. Указатели имеют длину 16 байт (128 бит). Разрешенный системный указатель содержит возможность прямой адресации системного объекта, то есть в нем находится 64-разрядный виртуальный адрес. Указатели других типов (пространства, данных, команд и процедур) также содержат виртуальные адреса.

Указатели находятся в ассоциированном пространстве системного объекта. В этом же пространстве содержатся данные, к которым имеет доступ и которые может изменить программа MI. Доступ и модификация данных в ассоциированном пространстве законны; изменение указателя — нет. Если бы программа MI могла изменять содержимое указателя, то была бы нарушена защита. Адрес в указателе мог бы быть изменен так, чтобы указывать на еще какой-нибудь объект или структуру, доступ к которой запрещен. Конечно, все это касается пользовательских программ, в которых команды MI заданы непосредственно; и не имеет отношение к программам на ЯВУ, таких как RPG или Cobol.

Когда разрабатывалась структура указателя, способами защиты были избраны устранение ассемблера MI, перевод некоторых команд в разряд привилегированных и удаление из указателей полномочий. Как говорилось в главе 7, все эти усиления уровней защиты привносились в AS/400 с течением времени. Но даже такая степень защищенности не дает стопроцентной уверенности в том, что содержимое указателя не подвергнется несанкционированным изменениям.

В главе 5 отмечалось, что ассоциированное пространство, содержащее указатели, занимает отдельный сегмент системного объекта. Первоначально в System/38 мы хотели использовать два сегмента: один — для данных, а второй —для указателей. Но такой подход снижал производительность системы. При использовании объекта было необходимо считывать с диска страницы, как сегмента данных, так и сегмента указателей, что повышало накладные расходы. Кроме того, два сегмента требовали некоторого увеличения размеров памяти. Единственным плюсом ассоциированного сегмента указателей была надежда, что он может защитить указатели от модификации пользователями. Но оказалось, что это не так.

Скоро выяснилось, что мы не можем защитить ассоциированный сегмент указателей от изменений. При той степени защиты, которая планировались для System/38 (уровень 30), пользователь, имевший право доступа к объекту, мог работать с его содержимым с помощью ассемблера MI. Помещение указателей в отдельную часть объекта не предоставляло дополнительной защиты. Пришлось искать другое решение.

Аппаратная защита указателей

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

Первоначально использовать в аппаратуре System/38 такой тип защиты памяти не планировалось: никто не думал, что он понадобится, ведь защита проектируемой системы выполнялась на уровне объектов. Однако, когда стало понятно, что некая форма аппаратной защиты все же нужна, мы рассмотрели возможность защиты блока размером в одну страницу. Но, во-первых, это было дорого, а, кроме того, такой подход не вполне соответствовал планам разработчиков. В идеале, нам виделась защита для каждых 16 байтов памяти, так как указатель занимает именно столько. Но чтобы сделать систему производительной, хотелось иметь возможность размещать указатели где угодно, но тогда отдельный аппаратный массив разрядов защиты для каждых 16 байтов памяти становился неприемлем по стоимости. Наконец, нашлось решение: использовать для защиты памяти дополнительные разряды, предназначенные для кода коррекции ошибок ECC (error correcting code).