@KERNEL

Internal structure and you change requests/suggestions
  • Добавлено в ядро функция 81, она отвечает за переопределение и установку int 0x40 прерываний
    facepalm Это какой-то лютый пздц.
    также для безопасности была создана программа @KERNEL, которая при запуске переопределяет функцию 81, чтобы последующие программы не могли ей воспользоваться, это создано в первую очередь для безопасности
    Потрясающая безопасность. Зал плакал и аплодировал стоя.
  • Продублирую чат здесь:
    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-е ИМХО такого не должно быть.
  • [/quote]
    Потрясающая безопасность. Зал плакал и аплодировал стоя.[/quote]
    А чем не хорошая безопасность? Вирусы максимум что могут сделать это поменять AUTORUN.DAT и удалить саму @KERNEL. Согласен, что немного костыльно, но а есть еще варианты лучше? Например есть функция загрузки драйверов, так она вообще не продумана в плане безопасности.
    Технологии меняют мир, а я - меняю технологии.
  • Напишите действительно осмысленно, чем ужас этот вызван, чем эта ф-ция хуже других в плане безопасности, например то же самое загрузки драйверов, и я жду от ядерщиков ответа, они молчат, хотя бывают на форуме, напишите, кто за, кто против, ведь гибкости в ядре давно не хватает, например можно каждый раз грузить библиотеку Console, а можно один раз при старте системы и ей пользоваться.
    Технологии меняют мир, а я - меняю технологии.
  • pavelyakov wrote:например можно каждый раз грузить библиотеку Console, а можно один раз при старте системы и ей пользоваться.
    Могу ошибаться, но библиотеки и так грузятся лишь раз. Последующие загрузки библиотеки(в другой уже проге) открывают доступ к памяти с библиотекой. При условии, что библиотека во время работы не пишет в свою память. Если пишет, то выделяется новая память, туда грузится библиотека и там пусть хоть что делает. В идеальном случае в оперативе лишь одна копия библиотеки.
    По поводу безопасности в КОС - ситуация плачевная, так что волноваться не о чем :) Создать функцию в ядре, а потом закрыть её же с помощью @KERNEL - не логично. По поводу гибкости и вообще существования этой функции - идея мне нравится, но реализация слишком прямолинейная. В Виндовс существую хуки и прочая куча функций. Вот так просто открыть возможность к изменению работы прерываний - недопустимо для программ в юзерспэйсе(ИМХО, конечно). Тут бы посмотреть, какие именно функции ядру нужны. Раз у нас монолитное ядро, то и функций в него приходится впихивать по самое нимагу. Те же хуки в конце концов можно реализовать. Назначить свою функцию, которая будет вызываться при нажатии кнопки, выводе текста и прочее и прочее. Но как сейчас функция не кажется мне удобной.
    Spoiler:void newDrawText()
    {
    code...
    }
    - здесь скрывается дублирование кода из ядра только с изменениями, не так ли? Иначе как ещё вывести текст? А если я после своего code... захочу ещё и вызвать родной код ядра? Как мне узнать, куда прыгнуть дальше? Так что извини, но такая функция излишне. Идея хорошая, но не так это надо реализовать.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • pavelyakov
    С одной стороны о безопасности говорить глупо поскольку её и так нет.
    С другой стороны тема не раскрыта: зачем это всё вообще?
  • Вот так вот админам раздавать доступ к svn всем подряд.
    Самим же потом устранять дополнительные проблемы, если конечно ещё заинтересованы в развитии проекта.
    По какой-то удивительно странной традиции любая, даже самая нелепая чепуха может спокойно оказаться в trunk-e,
    и администрация на это так же спокойно никак не отреагирует.
    Ну кроме:
    — Эмм.. ну это типа... не есть хорошо
    — Да-да, лучше было так не делать :(
    — Это не правильно, нужно обязательно переделать!
    — ...
    ну и т.п. А код остаётся в trunk-e, а у его автора остаётся возможность плодить такое снова.

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

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

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

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

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

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

    Если авторы не в силах объяснить/убедить, что это очень нужный функционал, то сообщество обязано удалить этот код из ядра. Сейчас, как минимум, этот код занимает память, заплатка @KERNEL съедает ресурсы при старте системы, а применения этому нет.
  • theonlymirage wrote:Первая реализация это было ужасно... После исправления и @KERNEL это выглядит на троечку...
    Мне понравилось как это было дерзко и уверенно. Идея, но не ту, которую преследовали авторы, мне нравится. Авторы активны и работают, в этом они молодцы. Теперь о плохом.
    И тут у меня слишком много вопросов, мыслей и текста... Поэтому я пробегу очень поверхностно.

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

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

    Если авторы не в силах объяснить/убедить, что это очень нужный функционал, то сообщество обязано удалить этот код из ядра. Сейчас, как минимум, этот код занимает память, заплатка @KERNEL съедает ресурсы при старте системы, а применения этому нет.
    На этой неделе предоставлю реальные примеры и пользы этой функции, и позже отвечу на эти вопросы, удалить ф-цию эту не сложно и всегда можно, но смысл это сейчас делать даже не попробовав? С учетом развития проекта это не критично, мое мнение.
    Технологии меняют мир, а я - меняю технологии.
  • pavelyakov
    Всё же лучше эту функцию из ядра убрать, перенести в бранч. В Колибри есть легальный способ грузить свой код в kernelspace. А в нынешнем виде функция грузит двоичный блоб - без релокации, без импорта из ядра. Очень ограниченное применение и много сложностей в написании блоба.
  • theonlymirage wrote:Зачем при голосовании писать однобоко? Делать больший акцент только на одной точке зрения? Как функция 81 поможет вам "продолжать развитие операционки добавляя кучу фич"? И почему здесь нет ответа на этот вопрос?
    Вторая точка зрения полноценно не представлена, на ней не сделан акцент, зато ей приписаны отрицательные качества. Цитата: "либо убрать (функцию 81) и оставить дальше её (Колибри ОС) в неизменном состоянии".
    Получилась тема для голосования, где вы можете легко обмануть пользователей.
    А ведь там ещё и кто-то плюсует это, что как бы косвенно намекает на компетентность опрашиваемых.
    theonlymirage wrote:Если я правильно понял, то авторы хотели:
    Цитата:
    планируется перенести все библиотеки из Lib в глобальную область
    (цитата из новости в vk). Как вы будете переносить константы и глобальные переменные этих библиотек с помощью ф81?
    Это вообще всё чушь полная. Автор ни хера не смыслит в программировании просто. :lol:

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

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

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

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

    В OpenBSD уделяется огромное внимание качеству документации. Любая ошибка в man-странице считается серьёзной и немедленно исправляется. Также большое внимание уделяется простоте и ясности кода — поскольку разработчики небезосновательно полагают, что чем проще код, тем меньше вероятность пропустить ошибку. [/quote]Было бы здорово и нам придерживаться аналогичного принципа в KolibriOS.
  • Автор ни хера не смыслит в программировании просто. - ну ок тебе виднее. Странно, только почему-то работает все..
    Технологии меняют мир, а я - меняю технологии.
  • Serge wrote:pavelyakov
    Всё же лучше эту функцию из ядра убрать, перенести в бранч. В Колибри есть легальный способ грузить свой код в kernelspace. А в нынешнем виде функция грузит двоичный блоб - без релокации, без импорта из ядра. Очень ограниченное применение и много сложностей в написании блоба.
    Окей будет сделано вечером.
    Технологии меняют мир, а я - меняю технологии.
  • Who is online

    Users browsing this forum: No registered users and 4 guests