Вы не можете зарезервировать пользовательское адресное пространство глобально

Это перевод You cannot globally reserve user-mode address space. Автор: Реймонд Чен.

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

Это, очевидно, невозможно.

Почему очевидно? Ну, представьте, если бы это было бы возможным.

"Представьте, если бы это было возможным" - это один из логических тестов, который вы можете применить к теории или идее, чтобы посмотреть, возможно/сработает ли это. Сейчас мы используем его, чтобы определить, возможно ли предлагаемое поведение (есть и связанный с этим другой мысленный эксперимент: "представьте, что было бы, если бы всё действительно работало так").

Каковы последствия возможности глобального выделения пользовательского адресного пространства?

Ну, для начала, нет гарантий, что к моменту вашего резервирования в вашей системе вообще будет свободные для этого адреса. Возьмите в пример программу, которая использует практически всё своё адресное пространство (ей не обязательно использовать для этого реальную память - она может использовать VirtualAlloc(MEM_RESERVE)). Запустите такую программу и ни одно выделение глобальной памяти не будет успешным, пока программа не закроется.

Поэтому, даже если бы это было бы возможным - это не было бы надёжным. Ваша программа должна была бы быть подготовленной к ситуациям, когда не оставалось бы глобального свободного пространства. Поскольку вам всё равно придётся писать код отката (fallback code), то вы не сэкономили себе никакой работы.

Далее, положим, что это возможно, что у нас есть некая воображаемая функция GlobalVirtualAlloc. Ну, тогда я могу написать код, который вызывает эту воображаемую функцию в цикле, засасывая всё доступное глобальное адресное пространство, и запущу её под обычным пользователем (не администратором).

Я только что нарушил правила безопасности (общий принцип: обычный пользователь не должен влиять на других пользователей или систему. Мы уже видели сценарий, когда не-администратор может сломать программу, запущенную из под администратора, из-за небезопасного использования общей памяти).

Моя воображаемая программа забрала себе всё глобальное адресное пространство, уменьшая адресное пространство всех других программ - в том числе, работающих под администратором. Если в системе не работает много программ, то моя воображаемая программа, скорее всего, сможет выделить очень много адресного пространства таким образом. Что приведёт к эквивалентному уменьшению свободного адресного пространства в администраторских (и системных) программах. Поэтому, я могу вызывать исчерпание адресного пространства у этих программ, что приведёт к их завершению (отказ в обслуживание - denial of service).

Да, вы можете ограничить выделение глобального адресного пространства только для администраторов, но это никак не поможет ленивому программисту, поскольку программа не станет работать под обычным пользователем - и вам всё равно придётся писать код отката. Или вы можете ограничить "глобальное" выделение только пользователями в рамках той же сессии, с тем же токеном безопасности, но, опять-таки, вам всё равно придётся писать код отката, если закончится место в глобальном пространстве; вы не получили никакого выигрыша.

Мораль истории в том, что каждый процесс имеет своё собственное адресное пространство, и каждый процесс управляет им независимо от остальных процессов (конечно же, процесс может дать пользователю право PROCESS_VM_OPERATION, что позволит пользователю делать что угодно с адресным пространством процесса. Но изменения в адресном пространстве этого процесса никак не затронут остальные процесса).