OSDev

как защитить код от использования этих комманд,
и ещё интересно использование расширений в разных режима,

по существу проблема такая, если реализуется многозадачность и по прерыванию таймера PIT реализуется выполнение задач,
т.е. по очереди перебераются задачи с использованием far call и возврат к меджеру задач осуществляется командой ret,
то возникают такие проблемные моменты как например использование команды IRET в этом случае менеджер задач дойдёт до программы где эта комманда используется и на этом остановится, или если будет использоваться команды LGDT, LIDT то вся многозадачность вылетает в трубу,
в связи с такими обстоятельствами необходимо как то защитится от таких комманд и как вот это сделать.

к тому же хотелось бы узнать что можно использовать в каком режиме.

Ответы на все эти вопросы есть в документации. Читайте её, уже не первый раз говорю.
В защищенном режиме есть 4 уровня привилегий ("кольца" с 0-го по 3-е). 3 уровень привилегий - уровень пользователя. Тут меньше всего прав. Больше всего на нулевом.
Некоторые команды не доступны с 3 кольца (на котором должны работать приложения).
А многозадачность обычно организуется в виде переключения по таймеру, т.е. задача по времени работает между двумя прерываниями таймера (если говорить про самые распространенные многозадачные ОС).

ну Привилегированные команды ладно, с этим понятно, но Iret то будет работать или нет или он будет работать как обычный ret
а дополнительные расширения, их можно использовать в любом режиме.

iret для возврата берёт ещё и флаги процессора из стека помимо адреса, так что если ты перепутаеш её с ret то сразу будет ошибка критическая.
Нарушение порядка пользования стеком всегда приводит к ошибке критической



LGDT, LIDT и многозадачность ни как не связаны
Вообще многозадачность это массив с задачами(программами), которые работают одновременно, так можно на это посмотреть. Но это только кажется что работают одновременно, из за того, что процессор за секунду может выполнить много задач и нам кажется, что они выполнены одновременно.

Если даже выполняется одна задача долгое время, то её прерывают, например постоянными срабатываниями прерываний(от сюда и название), прерывание записывает адрес задачи и флаги процессора в стек и запускает обработчик адрес которой записан в LIDT, в обработчике находится обычная функция, которая выполняется и выходят из неё iret

Кстати после вызова функции командой call в стеке только адресс и после её завершения результат её работы можно сохранить в флагах процессора

Например в момент выполнения какой то функции сработает прерывание от мыши, то та функция прервётся и нарисуется на экране курсор в новой координате, или от веб камеры картинка придёт на экран, и т.д. Прерывают постоянно все устройства, но пользователю этого не заметно

FPU это вообще мат сопроцессор с которым проц очень связан и для него есть свои команды, например если захочеш посчитать числа с плавающей точкой то придётся пользоваться им, так как сам процессор не делает этого. От режима процессора он не зависит

В общем случае, многозадачные системы работают так. Я опишу программное переключение задач; по моему мнению, оно позволяет лучше понять сам процесс, да и это единственный вариант в 64-битном режиме.

Задачи работают в третьем кольце защиты (в CS дескриптор с CPL 3). Когда наступает прерывание - неважно, аппаратное или программное, инструкцией int - процесс находит в IDT дескриптор, соответствующий вектору. Дальше я буду исходить из того, что был найден interrupt gate - trap gate отличается только тем, что не запрещает прерывания, а остальные используются редко.

Процессор берет из дескриптора адрес обработчика (селектор и адрес, CS:EIP) и смотрит, произошло ли переключение уровня привилегий. Если да, то процессор меняет стек (SS:ESP) на тот, что указан в SS для нового уровня привилегий (т.е., обычно, SS0:ESP0) и сохраняет в него (обычным push) прошлое значение SS и ESP. Затем, независимо от того, был ли сменен уровень, процессор сохраняет прошлое значение EFLAGS, CS и EIP в стек. Некоторые исключения (вроде GP и PF) сохраняют в стек еще в этот момент код ошибки. Затем процессор загружает новый CS и переходит к выполнению обработчика прерывания, предварительно запретив прерывания.

Обработчик прерывания выполняется уже на нулевом (обычно) уровне привилегий и может использовать все инструкции. Первое, что он делает - выталкивает код ошибки, если он есть, сохраняет в стек все остальные регистры (сегментные кроме CS и SS, все РОНы), а затем разбирается с тем, что делать. В системах с вытесняющей многозадачностью, например, прерывание от таймера выбирает следующую готовую к выполнению задачу.

Если в результате выполнения обработчика возникла необходимость переключить задачу, то состояние регистров (и запихнутых самим процессором, и сохраненных в начале обработчичка) копируется в служебную структуру в памяти ядра (контекст задачи), а затем на его место в стеке копируется контекст новой задачи.

Выход из обработчика выполняется одинаково независимо от того, было переключение или нет. Обработчик прерывания выталкивает все сохраненные им регистры, а затем вызывает iret. Iret выталкивает EIP, CS, EFLAGS и смотрит, отличается ли уровень привилегий нового CS от старого. Если да, то процессор вытаскивает новые значения регистров ESP и SS из стека. После этого он передает выполнение прерванному коду.

Таким образом, для задач факт переключения задачи невидим - с их точки зрения, они выполняются параллельно.

А зачем дублировать сохраненные "в начале обработчика" регистры? DS, ES и все РОНы я сохраняю еще "в начале обработчика", FS, GS и EIP в подпрограмме переключения (причем EIP неявно - это делает call, вызывающий подпрограмму). В структуре потока сохраняется только ESP, все остальное, получается, - в ядерном стеке потока.

Это неправда. Данные поля TSS статичные, т.е. они могут быть изменены только программным путем.

А, да? Тогда исправлю. У меня состояние указателя стека всегда возвращалось к исходному, поэтому не заметил ошибку.

При обычном возврате (не при выходе из вложенной задачи) iret может только понижать привилегии. При попытке их повысить будет генерироваться исключение.