[EMAIL PROTECTED] dijo:

[...]

> Peeeeero, eventualmente, como sería una posible soluciòn?

Nuevo nucleo.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
From [EMAIL PROTECTED]  Mon Jun 14 14:16:29 2004
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Jun 14 14:16:32 2004
Subject: Kernel Crash-Exploit descubierto 
In-Reply-To: Your message of "Mon, 14 Jun 2004 12:51:48 -0400."
        <[EMAIL PROTECTED]> 
Message-ID: <[EMAIL PROTECTED]>

Carlos Manuel Duclos Vergara <[EMAIL PROTECTED]> dijo:
> > Peeeeero, eventualmente, como sería una posible soluciòn?

[...]

> el punto seria buscar la manera de evitar que alguien pueda cambiar los 
> bits de la FPU mas que evitar que la interrupcion provoque la debacle;

La interrupcion dentro del nucleo provoca la debacle porque _no_ la
interceptan/manejan adecuadamente. Creian que interrupciones de la FPU en
el nucleo eran imposibles...

>                                                                        no 
> puse mayor atencion al codigo del ejemplo, pero habria que preguntarse:
> 1.- que privilegios requiere el codigo para ser ejecutado?

Usuario corriente.

> 2.- como es que un registro sensible como el estado de la FPU esta 
> disponible para ser cambiado?

Porque son flags de estado de la FPU, no es privilegiado de ninguna forma.

> 3.- se necesita cambiar el valor de ese registro?

Yep. Cada vez que efectuas una operacion de punto flotante cambian,
registran modo de redondeo, genero NaN, ...

> 3.a.- No: es posible cambiar el mapa de memoria y dejar ese registro en una 
> region ro?

Imposible. Son flags de la CPU.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
From [EMAIL PROTECTED]  Mon Jun 14 14:38:18 2004
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Mon Jun 14 14:38:34 2004
Subject: FC2 y usb pen drive =?iso-8859-1?q?=A1urgente!?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Mon, Jun 14, 2004 at 12:45:39PM -0400, Franco Catrin L. wrote:
> El lun, 14-06-2004 a las 12:00, Alvaro Herrera escribió:
> > On Mon, Jun 14, 2004 at 11:41:24PM +0800, mauricio vargas wrote:
> > 
> > > 1. Cuando tenía mdk 9.1 el pen drive funcionaba maravillosamente. Es
> > > decir que no es problema de kernel, a no ser que el nuevo kernel tenga
> > > algún problema con vfat (que se supone es compatible con fat16)
> > 
> > El kernel de Mdk generalmente viene con varios parches y cosillas para
> > que el escritorio funcione con las menos ranas posibles; esto no sucede
> > en otras distribuciones.  En FC2 el foco esta mas que nada en verificar
> > que Enterprise Linux o Advanced Server vayan a funcionar bien (i.e. es un
> > programa beta en escala gigante, mas que una distribucion por si sola).
> 
> Vamos Alvaro!!, es obvio que este es un problema entre la silla y el
> teclado (sda en vez de sda1), por que achacar al la distribucion por
> eso? Y por que tratar de acarrear ovejas apenas tienen un problema con
> una distribucion?

Que Mandrake, y probablemente tambien SUSE, a diferencia de casi
cualquier otra distribucion, viene preconfigurado para que todas esas
cosas "simplemente funcionen"; FC aparentemente no tiene un foco tan
fuerte en el escritorio.  No es que FC sea malo, sino que es inferior en
este aspecto.  La gente de RedHat misma ha dicho repetidamente que "para
el escritorio mejor sigan usando Windows" --- ellos quieren vender
servidores.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)

Responder a