Puertos I/O

[Arkangel_0x7C5]

la direccion de los TSS se encuentra en la GDT que se obtiene con la instruccion SGDT.

Te explico, si estas arrancando bajo el SO. el procesador tiene varios modos de ejecucion a parte de los de modo largo y demas. Se les llama anillos de ejecucion. cuando arrancas estas en el anillo 0 (Modo Kernel) en el que puedes ejecutar todas las instrucciones que quieras. pero al cargar el SO carga las aplicaciones en el anillo 3 (Modo Usuario) que es el que menos permisos de ejecucion tiene

Saludos

[cpu2]

Vale, no puedo ejecutar esas instrucciones porque al comparar CPL dice que estoy en el anillo 3.
Así que no puedo hacer nada?

Pero ensamblando el código y hacer un módulo y compilarlo junto al kernel, no tendría que dar problemas no?
No tendría que añadir nada más solo el in?

Un saludo.

[Eternal Idol]

¿Probaste el primer resultado de openbsd ioperm en Google?

http://wiki.gudinna.com/200

[0xDani]

¿Probaste el primer resultado de openbsd ioperm en Google?

http://wiki.gudinna.com/200

Ese código parece hacer referencia a llamadas específicas de la arquitectura i386; y él ya dijo que estaba usando un amd64 y no encontraba una equivalente para esta arquitectura.

Saludos.

[Eternal Idol]

Ese código parece hacer referencia a llamadas específicas de la arquitectura i386; y él ya dijo que estaba usando un amd64 y no encontraba una equivalente para esta arquitectura.

Saludos.

P.D: Probaré esa función en un i386 que tengo, ya os contaré como fue.

Por cierto, si no hay equivalente por algo sera.

[cpu2]

Por cierto, si no hay equivalente por algo sera.

Exacto, hay esta el problema con la amd64.

Código [Seleccionar] Expandir

http://old.nabble.com/remove-amd64-ioperm-td35476935.html

¿Probaste el primer resultado de openbsd ioperm en Google?

Quiero implementarlo en ASM, no quiero funciones escritas en C.

Del manual de AMD:

If the CPL is higher than IOPL, or the mode is virtual mode, IN checks the I/O permission bitmap in
the TSS before allowing access to the I/O port.

Si estoy en modo usuario, anillo 3, CPL es mayor que IOPL y por eso no tengo permisos para acceder al puerto, para eso tengo que utilizar ese bitmap del que habla el manual?
Al estar en modo kernel anillo 0, CPL no sería mayor que IOPL y tendría acceso a los puertos sin la necesidad de chequear el bitmap permission?

Un saludo y gracias a todos por el interés.

[Eternal Idol]

Quiero implementarlo en ASM, no quiero funciones escritas en C.

Eso no representa ningun problema, desensambla el resultado en C y listo. Lo unico que hace es llamar a un servicio y seguramente es un int 0x80, un syscall/sysenter o lo que sea.

Si estoy en modo usuario, anillo 3, CPL es mayor que IOPL y por eso no tengo permisos para acceder al puerto, para eso tengo que utilizar ese bitmap del que habla el manual?
Al estar en modo kernel anillo 0, CPL no sería mayor que IOPL y tendría acceso a los puertos sin la necesidad de chequear el bitmap permission?

Un saludo y gracias a todos por el interés.

¿No hay otro servicio para obtener este dato? De ser asi yo que vos haria el parche, un modulo de modo Kernel no es un programa, es otro paradigma diferente.

[cpu2]

Eso no representa ningun problema, desensambla el resultado en C y listo. Lo unico que hace es llamar a un servicio y seguramente es un int 0x80, un syscall/sysenter o lo que sea.

Ya no puedo usar ioperm, fue eliminado de la arquitectura amd64.

¿No hay otro servicio para obtener este dato? De ser asi yo que vos haria el parche, un modulo de modo Kernel no es un programa, es otro paradigma diferente.

Creo que no, si estoy en ring 3 tendré que acceder a ese bitmap tal y como dice el manual.

Un saludo.

[Eternal Idol]

Ya no puedo usar ioperm, fue eliminado de la arquitectura amd64.

Por logica no es una buena idea que programas de modo Usuario accedan al hardware directamente, eso se hacia en la epoca en que no habia multitarea y la sincronizacion no era lo que es ahora. Es una lastima que no hayas dicho que pretendes hacer EXACTAMENTE desde el primer mensaje del hilo. ¿Es una prueba? ¿Es solo por verlo funcionar? ¿O prentedes hacer un software que se ejecute en produccion? Desde que mencionaste el parche asumo que es lo primero y para eso hacerlo en x86 es suficiente ... aunque tal vez lo queres para tu propio uso nada mas ... vaya uno a saber.

Creo que no, si estoy en ring 3 tendré que acceder a ese bitmap tal y como dice el manual.

Justamente si estas en modo Usuario no podes acceder, la gracia esta en que solo se puede acceder desde modo Kernel, asi es como se implementa la proteccion.

[cpu2]

Por logica no es una buena idea que programas de modo Usuario accedan al hardware directamente, eso se hacia en la epoca en que no habia multitarea y la sincronizacion no era lo que es ahora. Es una lastima que no hayas dicho que pretendes hacer EXACTAMENTE desde el primer mensaje del hilo. ¿Es una prueba? ¿Es solo por verlo funcionar? ¿O prentedes hacer un software que se ejecute en produccion? Desde que mencionaste el parche asumo que es lo primero y para eso hacerlo en x86 es suficiente ... aunque tal vez lo queres para tu propio uso nada mas ... vaya uno a saber.

Es un poco de todo, el código del primer mensaje del hilo no es más que una prueba, queria obtener la temperatura sin tener que utilizar systat sensors ni ninguna función escrita en C o interrupción, un ASM puro.

Las funciones como scanf o commandos como systat sensors, en algún momento tendrán que comunicarse con los puertos i/o, bueno más bien el núcleo, scanf con el teclado que es el predeterminado y systat sensors con el sensor de temperatura, mi idea era hacer mis propias funciones a medida de mi avancé.

Pero no puedo utilizar ese ioperm no fue implementado en amd64, no lo quiero hacer en el x86, esa funcion si puede dar permisos y yo desde ASM no, pues vaya.

Justamente si estas en modo Usuario no podes acceder, la gracia esta en que solo se puede acceder desde modo Kernel, asi es como se implementa la proteccion.

Si, tienes razón ya me he dado cuenta, ya se donde esta el I/O permission bitmap se encuentra en la TSS en el registro TR, devuelve 16 bytes, obtienes la dirección con la instrucción ltr:

Código (asm) [Seleccionar] Expandir

pushq %rax
pushq %rax
movq %rsp, %rdi
ltr (%rdi)

Ahora en teoria tendría que tocar el bitmap y volver a cargarlo en el registro TR.
Pero el resultado es un Bus error (core dumped) que hace referencia a la dirección de ltr. Bueno el manual lo deja bien claro.

This instruction must be executed in protected mode when the current privilege level is 0. It is only
provided for use by operating system software.

Así que la única forma de poder hacer lo que pretendo es en ring 0, o de un ioperm que no dispongo?

Un saludo.