Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Sep 22, 2019 5:44 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next
Author Message
 Post subject: @KERNEL
PostPosted: Sat Aug 25, 2018 8:24 pm 
Offline
User avatar

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

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



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


Last edited by paulcodeman on Mon Aug 27, 2018 1:36 pm, edited 1 time in total.

Top
   
 Post subject: Re: @KERNEL
PostPosted: Sun Aug 26, 2018 5:51 am 
Offline

Joined: Sun Aug 09, 2015 3:41 pm
Posts: 112
Quote:
Добавлено в ядро функция 81, она отвечает за переопределение и установку int 0x40 прерываний


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

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

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Sun Aug 26, 2018 10:21 am 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Продублирую чат здесь:
Quote:
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-е ИМХО такого не должно быть.


Top
   
 Post subject: Re: @KERNEL
PostPosted: Sun Aug 26, 2018 12:43 pm 
Offline
User avatar

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Sun Aug 26, 2018 12:53 pm 
Offline
User avatar

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Sun Aug 26, 2018 4:43 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 455
pavelyakov wrote:
например можно каждый раз грузить библиотеку Console, а можно один раз при старте системы и ей пользоваться.

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

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

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 1:02 am 
Offline
Mentor/Kernel Developer
User avatar

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 1:03 am 
Offline

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

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

Нет, вы только посмотрите на это https://vk.com/kolibri_next?w=wall-165380057_69
Spoiler: Show
Attachment:
1.PNG
1.PNG [ 36 KiB | Viewed 1583 times ]
Дожили! Решение он принимает :lol: Тут логичнее администратору принять решение о доступе автора к svn.

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 10:07 am 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Решение нужно было принимать тут, на официальном форуме, и естесственно, до модификации trunk-а.

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 2:04 pm 
Offline

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

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

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


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

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

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

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 2:24 pm 
Offline
User avatar

Joined: Wed Apr 15, 2015 11:13 pm
Posts: 253
theonlymirage wrote:
Первая реализация это было ужасно... После исправления и @KERNEL это выглядит на троечку...
Мне понравилось как это было дерзко и уверенно. Идея, но не ту, которую преследовали авторы, мне нравится. Авторы активны и работают, в этом они молодцы. Теперь о плохом.
И тут у меня слишком много вопросов, мыслей и текста... Поэтому я пробегу очень поверхностно.

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

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


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

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

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

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

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 2:49 pm 
Offline
Kernel Developer

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 2:52 pm 
Offline

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

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

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

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

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

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


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 3:18 pm 
Offline
User avatar

Joined: Wed Apr 15, 2015 11:13 pm
Posts: 253
Автор ни хера не смыслит в программировании просто. - ну ок тебе виднее. Странно, только почему-то работает все..


Top
   
 Post subject: Re: @KERNEL
PostPosted: Mon Aug 27, 2018 3:51 pm 
Offline
User avatar

Joined: Wed Apr 15, 2015 11:13 pm
Posts: 253
Serge wrote:
pavelyakov
Всё же лучше эту функцию из ядра убрать, перенести в бранч. В Колибри есть легальный способ грузить свой код в kernelspace. А в нынешнем виде функция грузит двоичный блоб - без релокации, без импорта из ядра. Очень ограниченное применение и много сложностей в написании блоба.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited