Как с точки зрения ядра Linux пользовательская программа взаимодействует с графическим процессором CUDA?
chmod недостаточно, так как пользователь может просто изменить режим.
Сначала запретите пользователю редактировать файл:
- chmod go -w «-имя файла -»
- chown «какой-то -другой -пользователь» «-имя файла -»
Теперь пользователь все еще может удалить файл, так что давайте остановим это. (файл удаляется, если он удален из содержащего его каталога. Мы должны остановить это.)
- chown «какой-то -другой -пользователь» «-, содержащий каталог -»
- chmod +t «-, содержащий каталог -»
Теперь сделайте так, чтобы пользователь мог писать в содержащую -директорию
- chown «-имя пользователя -» «-, содержащий каталог -»
- chmod g+w «-, содержащий каталог -»
Вы ничего не можете сделать, чтобы остановить казнь. Вы не можете установить бит выполнения, но если пользователь может прочитать файл, он может его скопировать. Если они могут скопировать его, то они могут сделать его исполняемым.
Приложение запрашивает у ядра mmapнабор буферов при запуске, создание этого сопоставления является привилегированной операцией.
Нормальная работа просто заполняет эти буферы данными (, такими как текстуры, вершины или команды ), и, наконец, делает один вызов ядра, чтобы запустить представленную очередь команд. Этот начальный строб является единственным выполняемым доступом к регистру, все остальное находится в общей памяти.
Графический процессор имеет свой собственный рудиментарный MMU, чтобы гарантировать, что команды не могут ссылаться на данные, принадлежащие другому контексту, за исключением случаев, когда это желательно (, например. компоновщик, который объединяет цель рендеринга из игры с целью рендеринга из оверлея и записывает результат в экранный буфер on -).
Для вычислений -только рабочих нагрузок тот же механизм работает нормально, просто очередь команд заканчивается не «отправить данные на экран», а «вернуть данные на хост».