OberonCore

В одном непрерывном куске памяти подряд расположены metadata, code и область для глобальных переменных.

Сейчас память выделяется одним mmap, и получается, что на одной странице могут оказаться и данные, и код. Из-за этого не получается разделить права: хотелось бы, чтобы код был PROT_READ|PROT_EXEC, а данные — PROT_READ|PROT_WRITE. Но mprotect работает постранично, и получается, что память приходится помечать RWX.

В Linux и FreeBSD это ещё разрешено, но в OpenBSD с политикой W^X это не работает.

Есть ли способ реализовать настоящую модель W^X (чтобы код был только RX, а данные только RW), не меняя генерацию объектных файлов? Или всё-таки нужно править компилятор/эмиттер и добавлять paddings, чтобы code и metadata всегда выравнивались на границу страницы?

Не знаю каков формат объектного файла у BlackBox, а в "Виртовской модели" (см. Проект Оберон) переменные находятся по отрицательным смещениям. Если константы и код выровнять по началу страницы, то всё остальное будет выше, т.е. в другой странице. Вроде бы ни каких проблем нет.

Загрузчик можно переписать, чтобы код и данные раздельно грузил. Но интерфейс к ядру придется изменить.

Я так понял, нужно поменять реализацию StdLoader.Fixup?

И еще вызовы Fixup. Там память выделяется двумя блоками, потом в один из них загружается код вместе с данными, а в Fixup передаются адреса внетри блока.

И в самом Fixup такое же размещение подразумевается

Спасибо. Похоже всё работает.

Сделал 4 (page-aligned) области памяти вместо 2-х:
d (desc), m (meta + code + var) →d (desc), m (meta), c (code), v (var)

mod.mad + mod.ms → mod.cad
mod.mad + mod.ms + mod.cs → mod.vad

права доступа:

• desc: write, read
• meta: read
• code: exec, read
• var: write, read

BlackBox заработал в OpenBSD 7.7 (пока только CLI, GUI не пробовал)

В моём "ретро"-репозитории


Но ещё в Kernel есть такое место:


которое используется в Kernel.UnloadMod:

Что с этим делать?

Область дескрипторов оставить, остальные три освободить.Так же сейчас работает.

а ещё можно кому-то сходить в LC и забрать из евойной Kernel полноценный сканер объектов модуля, который позволяет безопасно освобождать всю память модуля, а не как сейчас — оставляя каждый раз мусор и протекая. для этого чуть-чуть изменён формат объектных файлов (обратно совместим, старые объектные файлы будут выгружаться по старому алгоритму, потому что там недостаточно информации) и добавлен новый сканер на выгрузку. формат хипа я не менял.

но fossil-репозиторий с LC недоступен...

вообще-то должен быть доступен. для клонирования вообще проверки отключены, а для веб-интерфейса надо пройти простенький челлендж, даже печеньки включать не надо. если вас не пускает даже в челлендж — попробуйте тор. потому что украинские ip — как ни смешно — блокируются с российской стороны в оба направления. сюда вот я через тор хожу, и до меня многие из рф достучаться не могут напрямую. от провайдера/хостера зависит, насколько я понял.

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

только дошло. про «кому-то сходить» — это я не ехидничал, а имел в виду, что там всё равно придётся разбираться (хотя большинство кода в одной кучке, но и смотреть изменения в писалке объектных файлов придётся, например, и небольшие, хоть и совместимые, изменения записи модуля в Kernel), так что я имел в виду: «кому-то, у кого есть время и вдохновение».

Из Казахстана: вчера был редирект на fuck.off, сегодня был доступен, сейчас снова редирект.
С российского VPN: вчера вроде бы был редирект на fuck.off, сегодня работает.
С VPN USA: недоступен (соединение с сервером устанавливается, но после отправки запроса не получается ответ).

да не надо туда браузером ходить: просто фоссилом напрямую клонировать. там довольно дубовая защита от «аи»-ботов, которые мне сервер чуть не завалили, а fossil clone/pull пускают напрямую. только не после посылания — тогда надо денёк выждать, кулдаун будет.

впны же в большинстве своём поблочены, потому что приходят с помоек типа digital ocean, которые мне сервер постоянно долбят попытками поиска «сплоетов», за то и забанено всё скопом.

там в веб-интерфейсе реально делать нечего: вы после клона сделаете fossil ui reponame — и получите точно такой же, но локальный. фоссил склонирует всё, что есть — и код, и вики, и билетики.

и, кстати, там в Docu/Kernel.odc есть небольшое описание того, как работает менеджер памяти: «Memory Manager Details (WIP)» в конце. совсем мало, но лучше, чем ничего. можете себе забрать, они у нас одинаковые.

впрочем, мой менеджер памяти чуть-чуть лучше оригинального в плане управления кластерами: он в состоянии их отдавать системе, если они долго не использовались. и ещё там есть важный фикс: когда выделяется большой кластер (очень большой массив, например), и потом GC его собирает, то оригинальный BBCB использует этот «огромный кластер» для выделения маленьких объектов. и может заякорить его низачем вместо чтобы вернуть системе. оно не то чтобы фатально (оригинал довольно плохо умеет кластеры возвращать), но неприятно. это у меня тоже починено.

ещё я оттуда COM к чёртовой бабушке выпилил (как и из компилятора), но если надо — восстановить не особо проблема, я думаю.

Нужно освободить 3 области:

• meta
• code
• var

Как было:

mod.refs = meta address
mod.data = var address
mod.dsize = var size

mod.data + mod.dsize - mod.refs = var address + var size - meta address = meta size + code size + var size (так как это всё было в одном куске памяти)

Сейчас вместо этого нужно вызвать:

• InvalModMem(meta size, meta address)
• InvalModMem(code size, code address)
• InvalModMem(var size, var address)

meta address = mod.refs
code address = mod.code
var address = mod.dsize

похоже code size — это mod.csize с выравниванием по 4 Б:
code size = ((mod.csize - 1) DIV 4 + 1) * 4

var size = mod.dsize

но где взять meta size?
mod.rsize — это только часть meta size

ну так получается, что рефсайз — это конечный адрес модуля минус мод.рефс, нет?

Что такое конечный адрес модуля?

meta = refs + Export + Pointers + Perpare Type Descriptors + Import List + Names + Const
(см. DevCPE.OutCode)

mod.refs = meta address
mod.rsize — похоже это только refs size

Похоже придётся при выделении памяти для meta добавить 4 Б в самом начале этого куска памяти для хранения meta size.

Похоже на то. Размеры областей нигде не сохраняются. Ну, можно еще в поле Module.ext запихнуть, но это как-то того.