Какое-то простое решение вроде:
eax - номер функции
ebx - формат что-то вроде dword ' png'
edx - ссылка на буффер ... байт для декодирования
esi - адрес источника
edi - адрес для раскодированного изображения
Хотелось бы функцию декодирования png, gif на уровне ядра.
-
Last edited by EAX on Wed Jul 06, 2022 11:50 am, edited 1 time in total.
Сделать это на уровне ядра будет не правильно.
Конвертирование в PNG/BMP с ограничениями есть в библиотеке libimg.
Конвертирование в PNG/BMP с ограничениями есть в библиотеке libimg.
Из хаоса в космос
Обращение к библиотеке скорее всего занимает много байт машинного кода.
Хотелось бы простое решение в ассемблерном стиле типа int 40 и menuet os.
В конце концов есть же функции для от рисовки прямоугольников, линий и прочих мелочей.
Хотелось бы простое решение в ассемблерном стиле типа int 40 и menuet os.
В конце концов есть же функции для от рисовки прямоугольников, линий и прочих мелочей.
Одно дело примитивы, другое дело высокоуровневые вещи.
Это не будет сделано в ядре.
Это не будет сделано в ядре.
Из хаоса в космос
Ядро может также ссылаться на библиотеку.
Ну ладно, тогда ничего спонсировать не буду.
вот объясните зачем это в ядре, ядро на мой взгляд итак перегружено достаточно бесполезными вещами а тут ещё и добавление декодирование туда добавить хотите.
Аргументы против: так как это будет в ядре, использоваться SSE MMX инструкции точно не будут, для того чтобы всё на пентиуме первом работало, при декодировании это займёт больше времени чем при использовании библиотеки(это связано с переключением контекста), это может стать потенциальной проблемой безопасности, из за которой ядро станет нестабильным
Аргументы за: Проще для ассемблерных программ
Аргументы против: так как это будет в ядре, использоваться SSE MMX инструкции точно не будут, для того чтобы всё на пентиуме первом работало, при декодировании это займёт больше времени чем при использовании библиотеки(это связано с переключением контекста), это может стать потенциальной проблемой безопасности, из за которой ядро станет нестабильным
Аргументы за: Проще для ассемблерных программ
> Обращение к библиотеке скорее всего занимает много байт машинного кода.EAX wrote:Обращение к библиотеке скорее всего занимает много байт машинного кода.
Хотелось бы простое решение в ассемблерном стиле типа int 40 и menuet os.
В конце концов есть же функции для от рисовки прямоугольников, линий и прочих мелочей.
А теперь сравните сколько по времени займет вызов загруженной библиотечной функции и вызов системной функции ядра (затраты на переключение контекста).
Часто бывает, что стараясь уменьшить размер кода, получается проигрыш в производительности. Здесь как раз этот случай.
Еще один аргумент: добавляя в ядро вещи вроде декодера картинок, появляются новые возможности для атаки.
Подсунул ядру заведомо некорректную картинку - исполнится произвольный код в пространстве ядра или в лучшем случае система упадет.
The best way to predict the future is to create it.
Можно простейший декодер на основных непривилегированных командах. Можно так же один декодер например png.Doczom wrote:вот объясните зачем это в ядре, ядро на мой взгляд итак перегружено достаточно бесполезными вещами а тут ещё и добавление декодирование туда добавить хотите.
Аргументы против: так как это будет в ядре, использоваться SSE MMX инструкции точно не будут, для того чтобы всё на пентиуме первом работало, при декодировании это займёт больше времени чем при использовании библиотеки(это связано с переключением контекста), это может стать потенциальной проблемой безопасности, из за которой ядро станет нестабильным
Аргументы за: Проще для ассемблерных программ
Возможно подводные камни есть.
При большом желании наверняка есть и другие способы обрушить ядро.rgimad wrote:> Обращение к библиотеке скорее всего занимает много байт машинного кода.EAX wrote:Обращение к библиотеке скорее всего занимает много байт машинного кода.
Хотелось бы простое решение в ассемблерном стиле типа int 40 и menuet os.
В конце концов есть же функции для от рисовки прямоугольников, линий и прочих мелочей.
А теперь сравните сколько по времени займет вызов загруженной библиотечной функции и вызов системной функции ядра (затраты на переключение контекста).
Часто бывает, что стараясь уменьшить размер кода, получается проигрыш в производительности. Здесь как раз этот случай.
Еще один аргумент: добавляя в ядро вещи вроде декодера картинок, появляются новые возможности для атаки.
Подсунул ядру заведомо некорректную картинку - исполнится произвольный код в пространстве ядра или в лучшем случае система упадет.
Думаю что машинный код функции декодирования занимает около 200-400 байт, вызов библиотеки может чуть меньше но не намного.
Т.е. что сам декодер вставить в код, что библиотеку вызвать разница небольшая.
Короче я не настаиваю.
Last edited by EAX on Wed Jul 06, 2022 11:53 am, edited 1 time in total.
Да... трындец вы токсичные ребята. Теперь понятно, почему в проекте так мало участников, и застой уже с десяток лет.
- Attachments
-
-
765.PNG (7.89 KiB)Viewed 5218 times
-
> непривилегированных командахEAX wrote:Можно простейший декодер на основных непривилегированных командах. Можно так же один декодер например png.
Возможно подводные камни есть.
Имеет значение привилегированный РЕЖИМ или нет.
Та же команда mov не является привилегированной, но в режиме ядра доступ ко всей памяти ядра имеет.
The best way to predict the future is to create it.
Так ты же первый резко кинул фразуEAX wrote:Да... трындец вы токсичные ребята. Теперь понятно, почему в проекте так мало участников, и застой уже с десяток лет.
не обсудив спокойно и аргументированно.EAX wrote:Ну ладно, тогда ничего спонсировать не буду.
The best way to predict the future is to create it.
EAX
Я сам спонсирую проект Колибри и потратил на это более 1000$. Спонсировать - это не покупать. Ты не первый кто приходит и думает, что может здесь кого-то купить.
Обида - это манипуляция. Ты решил нами манипулировать? Мы должны расстроиться, что ты не будешь спонсировать? Если умные люди сказали "нет" - прими это. Ты не хочешь чтобы проект стал лучше, а хочешь удовлетворения своих капризов. Кто так поступает? Ребенок.
Ты получил ответ должно твоему поведению.
Ты пришёл к нам в дом и хотел навязать свои правила. А так кто делает? Тут я промолчу.
Получив жесткий ответ, ты продолжил разговор не со мной, а обрушился критикой на весь проект, который не принял твои гениальные идеи.
Просто уходи и не позорься.
Я сам спонсирую проект Колибри и потратил на это более 1000$. Спонсировать - это не покупать. Ты не первый кто приходит и думает, что может здесь кого-то купить.
Обида - это манипуляция. Ты решил нами манипулировать? Мы должны расстроиться, что ты не будешь спонсировать? Если умные люди сказали "нет" - прими это. Ты не хочешь чтобы проект стал лучше, а хочешь удовлетворения своих капризов. Кто так поступает? Ребенок.
Ты получил ответ должно твоему поведению.
Ты пришёл к нам в дом и хотел навязать свои правила. А так кто делает? Тут я промолчу.
Получив жесткий ответ, ты продолжил разговор не со мной, а обрушился критикой на весь проект, который не принял твои гениальные идеи.
Просто уходи и не позорься.
Вряд ли кто помнит, что был такой персонаж