[uylug-varios] linus, un amigazo ... de la nsa ??

[Fernando Da Rosa]

Eduardo:

Muy interesante.

Finalmente es importante destacar el valor de pensar con cabeza propia y no
seguir ciegamente a nadie.

Saludos
Fernando



El 10 de septiembre de 2013 12:15, Eduardo Trápani <etrapani at gmail.com>escribió:

> > ¿Dónde empiezo una petición para elevar el cociente intelectual y del
> > kernel de las personas? Chicos, id a leer drivers/char/random.c.
> [...]
> > los números aleatorios que obtiene de /dev/random. Respuesta muy corta:
> > sois ignorantes”.
>
> Yo invito a leer el hilo donde se discutió eso, con la participación de
> Linus. Es muy inteligente en mandar leer el código de *hoy*. Lo que no
> dice es que lo que está hoy ahí no es lo que él quería. (más abajo van
> los enlaces y la cita para que vean por ustedes mismos).
>
> Theodore Ts’o dice: "Estoy muy contento de haber resistido la presión de
> los ingenieros de Intel para que /dev/random se basara únicamente en la
> instrucción RdRand."
>
> ¿Saben quién estaba de acuerdo con esos ingenieros de Intel? Sí, Linus,
> que quería darles "el beneficio de la duda" y devolver directamente lo
> que diera el generado sin pasar por el pool[1]:
>
> > And for x86 CPU's with the RDRAND capability bit, I'd give
> > Intel the benefit of the doubt and just make it do a single "rdrand"
> > and return the full 64 bit (or is it a 32-bit interface? I should
> > know, but I didn't look it up).
>
> Ahora puede decir lo que quiera. Pero de lo que dijo y apoyó no lo salva
> nadie. Lo que nos "salvó" fue Ts'o que siguió peleando y no quiso darle
> "el beneficio de la duda" a Intel. Con razón dice estar contento, fue un
> visionario en cierta manera.
>
> No hay backdoor, pero pudo haber habido. Hay fuse, pero pudo no haber
> habido. Linus es humano y le emboca y le erra. Eso sí, maneja tan bien
> el asunto que las cosas buenas entran igual y las malas eventualmente
> quedan afuera.  Y ahí estamos, sin acceso exclusivo al generador de
> Intel y con fuse. Felices :). Aplaudible totalmente su laburo de
> coordinador. Y lo mejor de lo que dice arriba es el "nosotros".
>
> De repente los demás tendríamos que aprender y no jorobar tanto con lo
> que Linus quiere o deja de querer (y Linus ser más dulce, pero ya no
> sería Linus ;)). El kernel es un equipo al que además entra y sale gente
> según los subsistemas y el hardware. Sí, Linus hubiese dado la
> posibilidad de un backdoor. Le falló la paranoia. ¿Y? Para que eso
> entrara tenían que estar de acuerdo los otros mantenedores y no
> estuvieron. Ahí entra el "nosotros".
>
> Y hay algo medio filosófico en esto, algo relacionado con velocidad e
> inmediatez. Linus quería la mayor velocidad (por eso tira abajo también
> el argumento arquitectónico de Matt) aceptando esa entrada sin
> verificar. Queremos todo ya, pero el costo de la rapidez y facilidad (no
> había que hacer ningún cálculo) podía haber sido medio alto. Es como una
> indicación de que algún día vamos a tener que empezar a frenar un poco
> para ver a dónde vamos tan apurados ... (perdón, me fui medio lejos).
>
> Eduardo.
>
> [1] http://article.gmane.org/gmane.linux.kernel/1173542
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>



-- 
Fernando da Rosa
fernando.darosa at gmail.com
http://www.fedaro.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130910/ded8f8c3/attachment-0002.htm>