Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Ср сен 19, 2018 9:59 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 17 сообщений ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: @KERNEL
СообщениеДобавлено: Сб авг 25, 2018 8:24 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
Добавлено в ядро функция 81, она отвечает за переопределение и установку int 0x40 прерываний, также для безопасности была создана программа @KERNEL, которая при запуске переопределяет функцию 81, чтобы последующие программы не могли ей воспользоваться, это создано в первую очередь для безопасности. До запуска программы @KERNEL все приложения могут воспользоваться функцией 81, после - нет. Программа @KERNEL запускается автоматически и прописана в /SETTINGS/AUTORUN.DAT

Описание функции:
Код:
eax = 81
ebx - номер функции 0x40 перерывания
ecx - указатель на начало импортированных данных в память ядра
edx - стартовый адрес функции при вызове 0x40
esi - указатель на конец импортированных данных в память ядра
int 0x40



Например, чтобы модифицировать функцию прорисовку текста, приведу пример кода программы на C-- Sphinx:
Код:
beginNewDrawText:
data ....
void newDrawText()
{
    code...
    EAX - указатель на старую функцию прорисовки текста
    $call eax
}
data ....
endNewDrawText:
void main()
{
    EAX = 81;
    EBX = 4;
    ECX = #beginNewDrawText;
    EDX = #newDrawText;
    ESI = #endNewDrawText;
    $int 0x40
}


Последний раз редактировалось pavelyakov Пн авг 27, 2018 1:36 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Вс авг 26, 2018 5:51 am 
Не в сети

Зарегистрирован: Вс авг 09, 2015 3:41 pm
Сообщения: 95
Цитата:
Добавлено в ядро функция 81, она отвечает за переопределение и установку int 0x40 прерываний


facepalm Это какой-то лютый пздц.

Цитата:
также для безопасности была создана программа @KERNEL, которая при запуске переопределяет функцию 81, чтобы последующие программы не могли ей воспользоваться, это создано в первую очередь для безопасности

Потрясающая безопасность. Зал плакал и аплодировал стоя.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Вс авг 26, 2018 10:21 am 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1375
Продублирую чат здесь:
Цитата:
KolibriBot « Сб авг 25, 2018 2:55 am » New SVN revision #7319 by pavelyakov in /kernel/trunk/core: Added Implementation of the function in the system - EAX = 81
pavelyakov « Сб авг 25, 2018 3:10 am » Добавил в ядро функцию модернизации int0x40, теперь можно с помощью обычного приложения функции, библиотеки, все что угодно загрузить в глобальную выделенную область ядра, загруженные функции можно выполнять через EAX = твой номер ф-ции int 0x40, присвоить в приложении можно через EAX = 81; EBX = номер ф-ции; ECX = указатель на ф-ции; EDX = размер скомпилированной ф-ции int 0x40
Serge « Сб авг 25, 2018 11:03 am » pavelyakov: backdoor в ядро?
pavelyakov « Сб авг 25, 2018 11:33 am » Serge: как и загрузка драйверов, я пока думаю над хешировании и проверки на хеш загружаемой ф-ции, чтобы нельзя было злокод исполнять.
pavelyakov « Сб авг 25, 2018 4:48 pm » Теперь ф-ции с повышенными правами (доступы к ядру) доступны до запуска программы (@KERNEL), программа @KERNEL перезаписывает ф-цию 81 (дыру к ядру)
Ray « Вс авг 26, 2018 5:53 am » pavelyakov: Откати этот ужас и пожалуйста не лезь в ядро (во всяком случае пока не научишься писать нормальный код).
0CodErr « Вс авг 26, 2018 12:12 pm » полностью согласен с Ray и Serge — такому коду в ядре делать нечего. Нужен драйвер — пиши драйвер, не нужно фигнёй заниматься.
0CodErr « Вс авг 26, 2018 12:14 pm » pavelyakov: Или создай себе branch и играйся там. Кто захочет — будет использовать твой branch, в trunk-е ИМХО такого не должно быть.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Вс авг 26, 2018 12:43 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
[/quote]
Потрясающая безопасность. Зал плакал и аплодировал стоя.[/quote]
А чем не хорошая безопасность? Вирусы максимум что могут сделать это поменять AUTORUN.DAT и удалить саму @KERNEL. Согласен, что немного костыльно, но а есть еще варианты лучше? Например есть функция загрузки драйверов, так она вообще не продумана в плане безопасности.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Вс авг 26, 2018 12:53 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
Напишите действительно осмысленно, чем ужас этот вызван, чем эта ф-ция хуже других в плане безопасности, например то же самое загрузки драйверов, и я жду от ядерщиков ответа, они молчат, хотя бывают на форуме, напишите, кто за, кто против, ведь гибкости в ядре давно не хватает, например можно каждый раз грузить библиотеку Console, а можно один раз при старте системы и ей пользоваться.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Вс авг 26, 2018 4:43 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн ноя 19, 2012 5:22 pm
Сообщения: 454
pavelyakov писал(а):
например можно каждый раз грузить библиотеку Console, а можно один раз при старте системы и ей пользоваться.

Могу ошибаться, но библиотеки и так грузятся лишь раз. Последующие загрузки библиотеки(в другой уже проге) открывают доступ к памяти с библиотекой. При условии, что библиотека во время работы не пишет в свою память. Если пишет, то выделяется новая память, туда грузится библиотека и там пусть хоть что делает. В идеальном случае в оперативе лишь одна копия библиотеки.
По поводу безопасности в КОС - ситуация плачевная, так что волноваться не о чем :) Создать функцию в ядре, а потом закрыть её же с помощью @KERNEL - не логично. По поводу гибкости и вообще существования этой функции - идея мне нравится, но реализация слишком прямолинейная. В Виндовс существую хуки и прочая куча функций. Вот так просто открыть возможность к изменению работы прерываний - недопустимо для программ в юзерспэйсе(ИМХО, конечно). Тут бы посмотреть, какие именно функции ядру нужны. Раз у нас монолитное ядро, то и функций в него приходится впихивать по самое нимагу. Те же хуки в конце концов можно реализовать. Назначить свою функцию, которая будет вызываться при нажатии кнопки, выводе текста и прочее и прочее. Но как сейчас функция не кажется мне удобной.
Спойлер: Показать
void newDrawText()
{
code...
}

- здесь скрывается дублирование кода из ядра только с изменениями, не так ли? Иначе как ещё вывести текст? А если я после своего code... захочу ещё и вызвать родной код ядра? Как мне узнать, куда прыгнуть дальше? Так что извини, но такая функция излишне. Идея хорошая, но не так это надо реализовать.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 1:02 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1204
pavelyakov
С одной стороны о безопасности говорить глупо поскольку её и так нет.
С другой стороны тема не раскрыта: зачем это всё вообще?


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 1:03 am 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1375
Вот так вот админам раздавать доступ к svn всем подряд.
Самим же потом устранять дополнительные проблемы, если конечно ещё заинтересованы в развитии проекта.
По какой-то удивительно странной традиции любая, даже самая нелепая чепуха может спокойно оказаться в trunk-e,
и администрация на это так же спокойно никак не отреагирует.
Ну кроме:
Цитата:
— Эмм.. ну это типа... не есть хорошо
— Да-да, лучше было так не делать :(
— Это не правильно, нужно обязательно переделать!
— ...
ну и т.п. А код остаётся в trunk-e, а у его автора остаётся возможность плодить такое снова.

Всё это очень не серьёзно. Нас и так мало, а после подобных ситуаций вряд ли будет становиться больше.
Вы бы захотели присоединиться к проекту, где происходит такое?
Трудно представить, чтобы такое могло произойти в линуксах или *BSD.

Нет, вы только посмотрите на это https://vk.com/kolibri_next?w=wall-165380057_69
Спойлер: Показать
Вложение:
1.PNG
1.PNG [ 36 КБ | 279 просмотров ]
Дожили! Решение он принимает :lol: Тут логичнее администратору принять решение о доступе автора к svn.

pavelyakov, рекомендую сперва изучить матчасть.
Для начала, как ты думаешь
    Почему драйвера имеют именно такой формат, а не, скажем, просто сырой бинарник?
    Что такое релокации и для чего они нужны?
    Что такое базовый адрес и на что это влияет?
    Где будут размещены статические данные?
    По какому адресу они будут загружены?
    Будут ли они вообще куда-нибудь загружены в твоей НЕДОреализации?
Дальнейшее изобретение велосипедов и подстановка костылей так или иначе приведёт к созданию чего-то, по своей сути отдалённо напоминающего pe\elf\coff, что и было уже реализовано задолго до тебя: сначала MSCOFF, затем StrippedPE.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 10:07 am 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 187
Решение нужно было принимать тут, на официальном форуме, и естесственно, до модификации trunk-а.

По существу: такую функциональность можно было бы разрешить драйверу, то есть добавить экспортную функцию ядра, которая бы подменяла (или добавляла новую) функцию int 0x40. Таким образом код, заменяющий функцию ядра, был бы расположен в драйвере, что более логично. Другое дело, что этому коду понадобятся сто тыщ новых экспортных функций для реализации своего функционала, но это мы оставим додумать автору идеи.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 2:04 pm 
Не в сети

Зарегистрирован: Сб апр 22, 2017 6:11 pm
Сообщения: 121
Первая реализация это было ужасно... После исправления и @KERNEL это выглядит на троечку...
Мне понравилось как это было дерзко и уверенно. Идея, но не ту, которую преследовали авторы, мне нравится. Авторы активны и работают, в этом они молодцы. Теперь о плохом.
И тут у меня слишком много вопросов, мыслей и текста... Поэтому я пробегу очень поверхностно.

Необходимости в функции 81 нет, тем более когда по умолчанию она прикрыта @KERNEL. Ф81 может быть полезна только очень малому кругу разработчиков в очень определённый период их жизни. ;) В релизе эта функция совсем не нужна, как написали выше - получится backdoor. И здесь не стоит вопрос почему другие системные функции и драйвера дырявые, они в отличии от ф81 выполняют прямую пользу и поэтому необходимы конечному пользователю. Ф81 конечному пользователю не нужна, даже программистам системы. Это прикольная, но не нужная возможность.
Исправление безопасности этой функции (в будущем) проблематично. Если попадание ebx в таблицу syscall'ов можно проверить, то заданный адрес и размер новой функции это беда (что если задать память ядра? или всю память? или указать стек? и т.д.)

Аналогичный функционал для пересборки и перезапуска ядра уже есть, да он подольше, но с учётом времени старта системы и её скоростью это не критично.
Если я правильно понял, то авторы хотели:
Цитата:
планируется перенести все библиотеки из Lib в глобальную область
(цитата из новости в vk). Как вы будете переносить константы и глобальные переменные этих библиотек с помощью ф81? Все остальные вопросы по этой теме уже задали выше, например:
0CodErr писал(а):
Для начала, как ты думаешь
Почему драйвера имеют именно такой формат, а не, скажем, просто сырой бинарник?
Что такое релокации и для чего они нужны?
Что такое базовый адрес и на что это влияет?
Где будут размещены статические данные?
По какому адресу они будут загружены?
Будут ли они вообще куда-нибудь загружены в твоей НЕДОреализации?


Среди всего прочего, усиливается разногласие: Kolibri-Next (Kolibri-N) всё хочет оторваться и начать свою жизнь.
Цитата:
голосование при котором будет принято решение оставить в ядре её и продолжать развитие операционки добавляя кучу фич, либо убрать и оставить дальше её в неизменном состоянии.

Зачем при голосовании писать однобоко? Делать больший акцент только на одной точке зрения? Как функция 81 поможет вам "продолжать развитие операционки добавляя кучу фич"? И почему здесь нет ответа на этот вопрос?
Вторая точка зрения полноценно не представлена, на ней не сделан акцент, зато ей приписаны отрицательные качества. Цитата: "либо убрать (функцию 81) и оставить дальше её (Колибри ОС) в неизменном состоянии".
Получилась тема для голосования, где вы можете легко обмануть пользователей. Между тем я предлагал опрос, который в интересах пользователей и важен разработчикам.
Цитата:
Было бы здорово провести в VK опросы на тему:
1) "я хотел(-а) применить/воспользоваться Колибри ОС для " решения таких-то задач, "но, мне помешало " то, что в Колибри ОС нет/отсутствует/сделано так-то и вот это.
2) я бы повседневно использовал(-а) или нашёл (нашла) повседневное применение Колибри, если бы ... список важных пунктов ...

И разумеется тщетно, даже нет отрицательных отзывов по этой мысли. ;)

Если авторы не в силах объяснить/убедить, что это очень нужный функционал, то сообщество обязано удалить этот код из ядра. Сейчас, как минимум, этот код занимает память, заплатка @KERNEL съедает ресурсы при старте системы, а применения этому нет.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 2:24 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
theonlymirage писал(а):
Первая реализация это было ужасно... После исправления и @KERNEL это выглядит на троечку...
Мне понравилось как это было дерзко и уверенно. Идея, но не ту, которую преследовали авторы, мне нравится. Авторы активны и работают, в этом они молодцы. Теперь о плохом.
И тут у меня слишком много вопросов, мыслей и текста... Поэтому я пробегу очень поверхностно.

Необходимости в функции 81 нет, тем более когда по умолчанию она прикрыта @KERNEL. Ф81 может быть полезна только очень малому кругу разработчиков в очень определённый период их жизни. ;) В релизе эта функция совсем не нужна, как написали выше - получится backdoor. И здесь не стоит вопрос почему другие системные функции и драйвера дырявые, они в отличии от ф81 выполняют прямую пользу и поэтому необходимы конечному пользователю. Ф81 конечному пользователю не нужна, даже программистам системы. Это прикольная, но не нужная возможность.
Исправление безопасности этой функции (в будущем) проблематично. Если попадание ebx в таблицу syscall'ов можно проверить, то заданный адрес и размер новой функции это беда (что если задать память ядра? или всю память? или указать стек? и т.д.)

Аналогичный функционал для пересборки и перезапуска ядра уже есть, да он подольше, но с учётом времени старта системы и её скоростью это не критично.
Если я правильно понял, то авторы хотели:
Цитата:
планируется перенести все библиотеки из Lib в глобальную область
(цитата из новости в vk). Как вы будете переносить константы и глобальные переменные этих библиотек с помощью ф81? Все остальные вопросы по этой теме уже задали выше, например:
0CodErr писал(а):
Для начала, как ты думаешь
Почему драйвера имеют именно такой формат, а не, скажем, просто сырой бинарник?
Что такое релокации и для чего они нужны?
Что такое базовый адрес и на что это влияет?
Где будут размещены статические данные?
По какому адресу они будут загружены?
Будут ли они вообще куда-нибудь загружены в твоей НЕДОреализации?


Среди всего прочего, усиливается разногласие: Kolibri-Next (Kolibri-N) всё хочет оторваться и начать свою жизнь.
Цитата:
голосование при котором будет принято решение оставить в ядре её и продолжать развитие операционки добавляя кучу фич, либо убрать и оставить дальше её в неизменном состоянии.

Зачем при голосовании писать однобоко? Делать больший акцент только на одной точке зрения? Как функция 81 поможет вам "продолжать развитие операционки добавляя кучу фич"? И почему здесь нет ответа на этот вопрос?
Вторая точка зрения полноценно не представлена, на ней не сделан акцент, зато ей приписаны отрицательные качества. Цитата: "либо убрать (функцию 81) и оставить дальше её (Колибри ОС) в неизменном состоянии".
Получилась тема для голосования, где вы можете легко обмануть пользователей. Между тем я предлагал опрос, который в интересах пользователей и важен разработчикам.
Цитата:
Было бы здорово провести в VK опросы на тему:
1) "я хотел(-а) применить/воспользоваться Колибри ОС для " решения таких-то задач, "но, мне помешало " то, что в Колибри ОС нет/отсутствует/сделано так-то и вот это.
2) я бы повседневно использовал(-а) или нашёл (нашла) повседневное применение Колибри, если бы ... список важных пунктов ...

И разумеется тщетно, даже нет отрицательных отзывов по этой мысли. ;)

Если авторы не в силах объяснить/убедить, что это очень нужный функционал, то сообщество обязано удалить этот код из ядра. Сейчас, как минимум, этот код занимает память, заплатка @KERNEL съедает ресурсы при старте системы, а применения этому нет.

На этой неделе предоставлю реальные примеры и пользы этой функции, и позже отвечу на эти вопросы, удалить ф-цию эту не сложно и всегда можно, но смысл это сейчас делать даже не попробовав? С учетом развития проекта это не критично, мое мнение.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 2:49 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3951
pavelyakov
Всё же лучше эту функцию из ядра убрать, перенести в бранч. В Колибри есть легальный способ грузить свой код в kernelspace. А в нынешнем виде функция грузит двоичный блоб - без релокации, без импорта из ядра. Очень ограниченное применение и много сложностей в написании блоба.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 2:52 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1375
theonlymirage писал(а):
Зачем при голосовании писать однобоко? Делать больший акцент только на одной точке зрения? Как функция 81 поможет вам "продолжать развитие операционки добавляя кучу фич"? И почему здесь нет ответа на этот вопрос?
Вторая точка зрения полноценно не представлена, на ней не сделан акцент, зато ей приписаны отрицательные качества. Цитата: "либо убрать (функцию 81) и оставить дальше её (Колибри ОС) в неизменном состоянии".
Получилась тема для голосования, где вы можете легко обмануть пользователей.
А ведь там ещё и кто-то плюсует это, что как бы косвенно намекает на компетентность опрашиваемых.
theonlymirage писал(а):
Если я правильно понял, то авторы хотели:
Цитата:
планируется перенести все библиотеки из Lib в глобальную область
(цитата из новости в vk). Как вы будете переносить константы и глобальные переменные этих библиотек с помощью ф81?
Это вообще всё чушь полная. Автор ни хера не смыслит в программировании просто. :lol:

Товарищи администраторы!
А какого собственно хрена у него до сих пор есть доступ к svn, и он продолжает туда и дальше коммитить своё Г#$НО?

И на будущее, ИМХО доступ к svn следует давать только после того, как будет показан код, доказана его целесообразность, будет проведена оценка его преимуществ и недостатков. Вот тогда и следует решать, принимать такой патч или же нет.

Процитирую уже не в первый раз wiki https://ru.wikipedia.org/wiki/OpenBSD#% ... 0%BA%D0%B8
Цитата:
Особенности разработки

OpenBSD отличается от других свободных BSD-систем своей системой разработки. Никакой код не может попасть в систему извне случайно; любые изменения просматриваются ответственными за соответствующую часть системы лицами. Любая ошибка, найденная в одном месте, вызывает пересмотр всего аналогичного кода.

В OpenBSD уделяется огромное внимание качеству документации. Любая ошибка в man-странице считается серьёзной и немедленно исправляется. Также большое внимание уделяется простоте и ясности кода — поскольку разработчики небезосновательно полагают, что чем проще код, тем меньше вероятность пропустить ошибку.
Было бы здорово и нам придерживаться аналогичного принципа в KolibriOS.


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 3:18 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
Автор ни хера не смыслит в программировании просто. - ну ок тебе виднее. Странно, только почему-то работает все..


Вернуться к началу
 Заголовок сообщения: Re: @KERNEL
СообщениеДобавлено: Пн авг 27, 2018 3:51 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср апр 15, 2015 11:13 pm
Сообщения: 217
Serge писал(а):
pavelyakov
Всё же лучше эту функцию из ядра убрать, перенести в бранч. В Колибри есть легальный способ грузить свой код в kernelspace. А в нынешнем виде функция грузит двоичный блоб - без релокации, без импорта из ядра. Очень ограниченное применение и много сложностей в написании блоба.

Окей будет сделано вечером.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 17 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB