В настоящее время 58 и 70 сис. функции выполняют схожие функции. 58 сис. функция досталась нам от MENUET.
Сейчас, все новые программы используют 70 сис. функцию.
Предлагаю удалить 58 сис. функцию, и больше не оборачиваться на совместимость.
Программы, у которых есть исходники, и они присутствуют на SVN будут переписаны на 70 сис. функцию.
Удаление 58 сис. функции из ядра.
Для информации: среди подфункций 58-й функции есть LBA-чтение с IDE-дисков 58.16, у которого отсутствует аналог в 70-й функции и которое используется программой hdread, исходники которой отсутствуют.
ЗЫ на всякий случай: лично мне пофиг на судьбу 58-й функции в целом и приложения hdread в частности, так и голосовал.
ЗЫ на всякий случай: лично мне пофиг на судьбу 58-й функции в целом и приложения hdread в частности, так и голосовал.
Можно добавить такую-же подфункцию в функцию 70 если есть необходимость, так что я тоже проголосовал за третий вариант. Главное код работы с LBA не удалять.
Имхо, сначала нужно сделать аналог функции 58.12, и только потом уже удалять. Ибо удалить - самое легкое...
ушёл...
Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите.
Когда-нибудь эту дырку придется так или иначе затыкать.
ИМХО имеет смысл сохранить LBA-сервис как опциональную подфункцию SysFn 70 для экспериментальных и встроенных версий ядра, отключив ее (условно-компилируемым блоком) в транке.
Кому надо - тот легко сможет подключить ее для собственных нужд.
Когда-нибудь эту дырку придется так или иначе затыкать.
ИМХО имеет смысл сохранить LBA-сервис как опциональную подфункцию SysFn 70 для экспериментальных и встроенных версий ядра, отключив ее (условно-компилируемым блоком) в транке.
Кому надо - тот легко сможет подключить ее для собственных нужд.
А сделать так, чтобы функции 58 и 70 были совместимы между собой, а может быть просто были синонимами (в смысле подфункций) нельзя?
P.S.
Цитата: "Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите."
Если развивать систему в микроядерном направлении, то можно идти другим путём - проверять полномочия приложения выполнять тот или иной системный вызов (в смысле - из потенциально опасных).
P.S.
Цитата: "Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите."
Если развивать систему в микроядерном направлении, то можно идти другим путём - проверять полномочия приложения выполнять тот или иной системный вызов (в смысле - из потенциально опасных).
Нельзя. Они не только отличаются номером функций подфункций. По сравнению с 70 функцией 58 вообще косорукий и одноногий инвалид. В 70 функции есть аналог VFS, 58 вообще не умеет возвращать директории в виде форматированного списка - она тупо возвращает содержимое либо файла либо папки в виде RAW данных. При работе с ней приложению (файловому менеджеру к примеру) приходилось самому разбираться со всей хитрой внутренней структурой каталогов FAT, про NTFS и Ext вообще речи не было на общесистемном уровне.FireWall wrote:А сделать так, чтобы функции 58 и 70 были совместимы между собой, а может быть просто были синонимами (в смысле подфункций) нельзя?
К микроядерности это никакого отношения не имеет. В целом ряде древних систем с монолитным ядром системные вызовы делились на привилегированные и непривилегированные; первые были доступны ограниченному кругу задач (например, привилегированная задача могла убить любую задачу в системе, а непривилегированная -- только любую задачу своего же пользователя).FireWall wrote:Если развивать систему в микроядерном направлении, то можно идти другим путём - проверять полномочия приложения выполнять тот или иной системный вызов (в смысле - из потенциально опасных).
В принципе аналог 58.12 вроде бы придумал.
viewtopic.php?p=29459#p29459
Только
Да и 58.12 вроде бы использует приложение hdview замечательного товарища Trans'а. Приложение не имеет исходников. Кто-нибудь может с ним связаться?
viewtopic.php?p=29459#p29459
Только
и я бы оставил эту возможность только драйверам, сделав экспорт соответствующих функций ядра.art_zh wrote:Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите.
Да и 58.12 вроде бы использует приложение hdview замечательного товарища Trans'а. Приложение не имеет исходников. Кто-нибудь может с ним связаться?
Asper
Можно сделать условную компиляцию. Правда этот вопрос надо еще проработать.В принципе аналог 58.12 вроде бы придумал.
viewtopic.php?p=29459#p29459
Толькои я бы оставил эту возможность только драйверам, сделав экспорт соответствующих функций ядра.art_zh wrote:Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите.
Связаться вряд ли, но при желании можно переписать с нуля - ничего в ней сложного нет (учитывая наличие Box_Lib сейчас), только времени на все не хватает.Да и 58.12 вроде бы использует приложение hdview замечательного товарища Trans'а. Приложение не имеет исходников. Кто-нибудь может с ним связаться?
Вобщем 59 функция выглядит так:
в syscall.inc добавил:
Файл kernel.mnt.txt надо переименовать в kernel.mnt, форум блокирует "неизвестные" ему расширения.
Формат функции 59.
Программа считывающая MBR (винчестера или флешки) и опционально записывающая загрузочный сектор указанного устройства в файл /sys/bootsector.bin. Путь к устройству для считывания MBR зашито в коде программы (для смены устройства нужна перекомпиляция программы). P.S. Я по прежнему считаю, что этой функции быть не должно в "нормальном" ядре.
Code: Select all
syscall_LBA_read_write:
cmp [lba_read_enabled], 1
je @f
mov eax, 10 ; LBA access denied
ret
@@:
test edi, edi
jnz @f
mov eax, 7 ; No pointer to buffer
ret
@@:
test esi, esi
jnz @f
.err_dev_name:
mov eax, 1 ; No pointer to device name
ret
@@:
movzx eax, byte [esi+4]
sub al, '0'
inc al
cmp dword [esi], '/hd/'
je @f
cmp dword [esi], '/bd/'
jne .err_dev_name
dec al
add al, 0x80
@@:
mov [hdpos], eax
push ebx edi
mov eax, ecx
xchg ebx, edi
test edi, edi
jz .read
cmp edi, 1
je .write
pop edi ebx
mov eax, 2 ; Unknown function
ret
.read:
call hd_read
jmp .out
.write:
call hd_write
.out:
pop edi ebx
xor eax, eax
cmp [hd_error], 0
je @f
mov eax, 11 ; Device error
@@:
ret
Code: Select all
dd syscall_LBA_read_write ; 59-LBA read and write
Файл kernel.mnt.txt надо переименовать в kernel.mnt, форум блокирует "неизвестные" ему расширения.
Формат функции 59.
Программа считывающая MBR (винчестера или флешки) и опционально записывающая загрузочный сектор указанного устройства в файл /sys/bootsector.bin. Путь к устройству для считывания MBR зашито в коде программы (для смены устройства нужна перекомпиляция программы). P.S. Я по прежнему считаю, что этой функции быть не должно в "нормальном" ядре.
Я за то, чтобы такая функция была в официально в ядре. Всё равно нету никакого ограничения доступа. Может просто добавить функцию включения/выключения возможности прямого доступа к диску?
ушёл...
Зачем функцию? Можно сделать компиляцию по умолчанию без этой функции, а при необходимости компилировать с функцией.
Неверное размышление. Выражаясь иносказательно - если всем разрешено носить личное оружие это не значит, что любому должна быть доступна атомная бомба. А такая функция по умолчанию - это атомная бомба для данных жесткого диска.Всё равно нету никакого ограничения доступа.
А может добавить в ядро диалог (только не смейтесь):
Code: Select all
Программа XYZ пытается получить прямой доступ к диску "/hd0/1". Разрешить?
{Да} {Нет}
ушёл...
Падсталом...
Виста+Семерка - кошмарим юзера!
Виста+Семерка - кошмарим юзера!
Who is online
Users browsing this forum: Ahrefs [Bot] and 2 guests