LINUX.ORG.RU

Сообщения gns

 

И еще раз про syscalls...

Форум — Development

Читал исходники ядра. Много думал...

А дело тут вот в чем. Как бы «всем хорошо известно» и по-умолчанию предполагалось, что ядро содержит массив указателей на системные вызовы sys_call_table.

Поколения куул-хацкеров и прочих честных разработчиков разработали 100500 примерно четыре метода разыскивания адреса этой таблицы в памяти и замены соответствующего сисколла на свой. И ладно бы только куул-хацкеры! Честные коммерсанты, которые по разным причинам не хотят открывать код своих ядерных модулей, делают то же самое. И все бы хорошо, но в коде ядра 5.15-107, например, мы видим (см. arch/x86/entry/syscall_64.c)

#define __SYSCALL(nr, sym) extern long __x64_##sym(const struct pt_regs *);
#include <asm/syscalls_64.h>
#undef __SYSCALL

#define __SYSCALL(nr, sym) __x64_##sym,

asmlinkage const sys_call_ptr_t sys_call_table[] = {
#include <asm/syscalls_64.h>
};

И все хорошо, как и ожидалось.

А в 5.15-158, к примеру, картинка уже другая:

/*
 * The sys_call_table[] is no longer used for system calls, but
 * kernel/trace/trace_syscalls.c still wants to know the system
 * call address.
 */
#define __SYSCALL(nr, sym) __x64_##sym,
const sys_call_ptr_t sys_call_table[] = {
#include <asm/syscalls_64.h>
};
#undef __SYSCALL

#define __SYSCALL(nr, sym) case nr: return __x64_##sym(regs);

long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
{
	switch (nr) {
	#include <asm/syscalls_64.h>
	default: return __x64_sys_ni_syscall(regs);
	}
};

Поясняю. Теперь вместо вызова по индексу в массиве имеем «тупо свитч». Кстати, этот переход между способами вызова сисколла не однократный. В 6.1 опять используется традиционная схема. Вот мне интересно, кто-нибудь кроме меня в этом деле ковырялся? Как нам теперь сисколлы-то перехватывать надежным способом?

И да, «писать свой LSM» предлагать. Не потому, что хотим что-то скрыть, а потому, что не можем или не хотим поддерживать свой форк ядра. Да и у клиентов будет стоять тот линукс, который будет стоять. А LSMы нонче модулями не грузятся.

 kernel hacking, ,

gns
()

Gitverse — новый российский репозиторий исходного кода

Новости — Разработка
Группа Разработка

10 февраля на Open Source Day коллеги из Сбертеха анонсировали проект российского облачного сервиса для хранения исходных текстов gitverse.

Сервис размещен в России на платформе cloud.ru и предназначен, как нетрудно догадаться, в основном «для внутреннего пользования». Пока сервис работает в тестовом режиме и проходит стадию бета-тестирования. Официальное открытие обещали через неделю. Зарегистрироваться там можно, но пока по Сбер-ID. По всей видимости, после открытия сервиса правила регистрации будут изменены.

Пока реализовано хранение проектов «аля гитхаб» и реализован импорт репозиториев с других серверов (нетрудно догадаться, каких). Коллеги обещали «принцип одного окна», CI/CD и прочие плюшки. На вопрос «а пайплайн будет?» ответили, что будет, но в следующей версии.

Регистрация и участие в бета-тестировании сервиса всячески приветствуется.

>>> Подробности

 ,

gns
()

Бардак, возникающий в /etc/hosts по умолчанию

Форум — Admin

Заглянул тут в /etc/hosts и увидел там буквально следующее

127.0.0.1 localhost.localdomain localhost gshost.service.jet.msk.su.

При этом, естественно, что nslookup об наш внутренний DNS говорит, что gshost.service.jet.msk.su имеет честный адрес из нашей внутренней сети.

uname -a = Linux gshost.service.jet.msk.su 2.2.12-20 (RedHat 6.2).

Я могу понять такое поведение инсталлятора, только если при инсталляции я указал что имя хоста у меня есть, а вот сети нет. (Типа чтобы ping `hostname` правильно работал). А вот если у меня из компушки сетеваяя карта торчит, считаю _серьезным_багом_ обзывать мой локальный интерфейс моим же FQDNом. Не порядок это, и, я не побоюсь этого слова :), бардак!

gns
()

RSS подписка на новые темы