Que Linus diga que un parche remitido al kernel es basura y critique a las partes involucradas no es nada del otro jueves. El asunto sin embargo cobra más interés, cuando se refiere a una de las vulnerabilidades de hardware más importante de los últimos años (una de las variantes de Spectre), que tiene como principal protagonista a Intel y sus procesadores.

Como nos temíamos nada más salir este asunto, era previsible que los movimientos de Intel para corregir este fallo iban a estar más motivados por las preocupaciones legales y de marketing, que por el mero aspecto técnico.

Es mucho más sencillo derivar toda la culpabilidad hacia el lado del software y sus desarrolladores, que tener que afrontar posibles importantes indemnizaciones, por la caída de rendimiento de sus equipos.

Y esa percepción se intuye en las listas del kernel, donde Intel ha mandado un “feo” parche, por razones que no están todo claras. En palabras del Guardián de Linux:

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make sense. That makes all your arguments questionable and suspicious. The patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

¿Que está pasando? ¿Qué está ocurriendo? ¿De que clase de brujería estamos hablando? Bueno, el asunto no es solo que el parche haga cosas locas o innecesarias según Torvalds y otros hackers del kernel, sino que viene preparado para ser habilitado de forma optativa y no predeterminada.

Una linda manera de echarle la culpa al sistema operativo a la hora de realizar los tests de rendimiento y del fabricante de lavarse las manos. Eso en el mejor de los casos.

The whole IBRS_ALL feature to me very clearly says “Intel is not serious about this, we’ll have a ugly hack that will be so expensive that we don’t want to enable it by default, because that would look bad in benchmarks”.

So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint.

Y ya que Torvalds menciona el aspecto técnico, otra de las quejas en la lista del kernel es que el parche propuesto por Intel, es inferior en rendimiento –y en gran medida redundante– respecto a la solución que ya se está implementando en Linux, conocida como Retpoline.

Linux 4.15: Otra versión candidata más

Dejamos atrás el misterio, y volvemos al desarrollo más ordinario del kernel. Ayer debía ser el lanzamiento de Linux 4.15. En su lugar tenemos una nueva versión candidata, la novena de esta rama.

I really really wanted to just release 4.15 today, but things haven’t calmed down enough for me to feel comfy about it, and Davem tells me he still has some networking fixes pending.

Laura Abbott found and fixed a very subtle boot bug introduced this development cycle only yesterday, and it just didn’t feel right to say that we’re done.

So I’m doing an rc9 instead. I don’t particularly like to, but I like it even less releasing something that doesn’t seem baked enough.

 

Algo que no veíamos desde el año 2011 (Linux 3.1):

I really expect no more delays after this. We’ve had rc9’s before, but they have been pretty rare (the last one was 3.1-rc9 back in 2011 – that release went all the way to rc10, and I really don’t think we’ll do that this time _despite_ all the CPU bug mitigation craziness).

Habrá que esperar por tanto unos días más, a que se acabe de cocinar Linux 4.15.

Imagen | John Dalton (CC-BY-SA-2.0)