EDICIóN GENERAL
242 meneos
1920 clics
Disponible Linux 4.15 con parches contra Meltdown y Spectre

Disponible Linux 4.15 con parches contra Meltdown y Spectre

Linus Torvalds ha anunciado la disponibilidad oficial de Linux 4.15. Lo primero que se puede destacar de este lanzamiento son los distintos parches incluidos para mitigar Meltdown y Spectre, los dos vectores de ataque que llevan desde comienzos de año acaparando la actualidad sobre la computación.

| etiquetas: linux , kernel , meltdown
Querrá decir kernel?
#1 Linux es el Kernel
#1 En este caso no hace falta aclararlo pero para el que no conozca bien, el nombre del kernel es Linux. Llamamos genércamente Linux a las distribuciones que contienen el kernel Linux (y los puristas se quejan mucho por ello) pero estrictamente hablando es el nombre del kernel.
#9 Puristas no, los fans del líder de un proyecto fracasado que lleva más de 30 años intentando desarrollar un sistema operativo compatible POSIX pero independiente de UNIX y que para mitigar su sensación de fracaso, y contradiciendo sus propias licencias y filosofía, intenta apropiarse de un proyecto ajeno consistente en desarrollar un sistema estilo UNIX.
#11 Llevo toda la vida en esto y no me queda claro a quién te refieres.
Más que nada por que creo que estás confundiendo churras con merinas.
¿Puedes aclarar a quién te refieres?
#12 yo diría que a Stallman. O eso parece.
#16 #14 Sí, se refiere al proyecto GNU fundado por Stallman y al núcleo Hurd
www.gnu.org/software/hurd/hurd.html
#22 Ya, pero que tiene eso de "querer apropiarse de Linux".
Solo alguien que no tenga la más remota idea de Linux y del software libre en general puede afirmar tal aberración.
#12 creo que habla de stallman, que lleva años queriendo apropiarse de linux porque claro, un kernel sin programas no vale para nada,y seamos serios, hurd es un fracaso
#24 Stallman no lleva años apropiarse de Linux.
Linux (SO) es tanto o más GNU que Linux (kernel).
La contribución de GNU a Linux (SO) es enorme.
Para empezar no habría Linux hoy en día si no fuese por el gcc de Stallman.
Además se os olvida que aparte de Linux existen otros kernel disponibles como el de BSD.
#24 Si Stallman no hubiera tenido un kernel con el que poder funcionar (Linux) posiblemente le hubiera dedicado mucho más esfuerzo a Hurd y bastante menos al resto de GNU (con lo que habríamos salido perdiendo). Y Linux tampoco hubiera llegado donde está porque Linus Torvalds habría tenido que programar todas las utilidades de GNU sin la ayuda de estos, cosa que había comenzado a hacer, pero como llegó GNU se centró en el kernel y pudo dejar ese trabajo a otros.

"Estoy haciendo un

…   » ver todo el comentario
#12 Richard Stallman, por supuesto.

GNU (Gnu is Not UNIX) es su proyecto estrella de crear un sistema operativo 100% libre compatible POSIX pero que vaya más allá del paradigma UNIX.

Para empezar, debía usar un microkernel, en principio GNU-Mach, dónde la compatibilidad POSIX sería suministrada por un servicio en espacio usuario corriendo como un proceso Mach (un diseño similar a Windows NT y a macOS X, ambos también basados en Mach). La principal diferencia es que en la mayoría de sistemas…   » ver todo el comentario
#27 Me lo figuraba. Churras <-----> Merinas.
No hay persona que haya insistido más en no apropiarse de el kernel de Linux que Stallman.
#27 No he visto nada en todo tu comentario que de a entender que se quiere apropiar de algo.
#58 Del nombre de un proyecto ajeno e independiente. Mejor dicho, quiere hacer pasar el proyecto de otros por el suyo propio, pidiendo a otros lo que él mismo no ha hecho, porque no tenía porque hacerlo, ya que la licencia no le obligaba, y Linux tampoco está obligado porque la licencia no le obliga.

Pero sobre todo, lo principal es que el SO GNU no es un SO Linux con mikrokernel Mach (eso ya ha existido y se llamaba mklinux) ni Linux es un sistema GNU con kernel monolítico tipo UNIX porque…   » ver todo el comentario
#61 " Mejor dicho" --> Te corrijo, "tu dices". Deja claro que es una opinión tuya. Sigo esperando pruebas de que ese sea el deseo de Stallman. No te moleste en escribir chorradas kilométricas. O presentas pruebas de lo que afirmas o no te va a creer ni tu padre.
#62 Lo dijo él mismo, no es una ida de olla mía.
#11 Sí, un proyecto fracasado que es el más usado en supercomputación, en servidores, lo usa la NASA, Amazon, Wikipedia, Facebook,Google, la FAA, el CERN, en conducción autónoma de vehículos, en sistemas de entretenimiento y domótica...y sin olvidarnos del sistema operativo más usado en dispositivos móviles ANDROID....todo un fracaso :palm:
#14 Creo que se refieren a GNU... no al núcleo Linux.
#20 Si estamos comentando la noticia hablamos de Linux, pero si quiere atribuirlo a GNU puedo decirle lo mismo
#23 Ya... pero al leer "sistema operativo fallido", yo entiendo que no se refieren al núcleo Linux (nunca tuvo vocación de ser un OS); sino al proyecto GNU, que si consistía en crear un OS compatible sin código de los UNIX propietarios.
#14 ¿Hoy si toca que Android es Linux?
#28 Android lleva un núcleo Linux. Punto.

es.wikipedia.org/wiki/Android
#14 El proyecto fracasado no es Linux, es GNU (el sistema operativo GNU basado en el kernel Mach, que en 36 años no ha logrado sacar una versión 1.0 operativa). O no me he expresado bien o ha fallado tu compresión lectora.
#29 GNU usa varios Kernels como kFreeBSD, Hurd o Linux que es el mas usado. Pero vamos, decir que GNU es un fracaso es un error. Lo que es un fracaso es Hurd
#38 eso es despreciar GNU. Lo que estas llamando GNU es sólo el servicio de compatibilidad POSIX. Es como si dijeras que FreeBSD es igual que macOS cambiando Darwin por kFreeBSD.

Pero es que además tienes Linux que no usan bash o glibc y siguen siendo sistemas Linux tradicionales. Es más, Linux no ha usado glibc como implementación de libc durante años.

Pero sobre todo, son proyectos diferentes e independientes y que no comparten diseño más allá de ser compatible POSIX los dos (igual que Windows).

Si fuesen consecuentes llamarían a esos Linux de la Windows Store GNU/Windows.
#40 Si Windows fuera software libre tal vez lo harían, pero como de libre tiene muy poco probablemente GNU no quiere que le relacionen con Windows ni en pintura, seguramente preferiran algo como Ubuntu/Windows (por aquello de que esos "Linux" suelen estar basados en Ubuntu y este es el responsable de eso y no GNU).

Si por GNU fuera dudo que eso existiera.
#41 Pero eso no es ser consecuente. Si Stallman quería que los sistemas operativos que compartiesen código de GNU se llamase GNU/algo lo debería haber puesto en la licencia, pero no es así y decir que el GNU "original" es igual al SO Linux cambiando Hurd por el kernel Linux es mentir. Sólo tienes que comparar una puñetera Debian GNU/Linux con una Debian GNU/Hurd. Hay más diferencias que entre OpenSuse Linux, FreeBSD y AIX.
#43 Para empezar la licencia es libre y puedes llamarlo como quieras, Android también es Linux pero no lo menciona por ninguna parte, además, para incluir algo así en la licencia necesitaría que todos los autores estuvieran de acuerdo, y Linus Torvalds creo que no está por la labor (tampoco se opone, pero dudo que aceptara a obligar a hacer tal cosa).

En cuanto a las diferencias Android es Linux pero se parece a cualquier otro SO basado en Linux bastante menos que FreeBSD o AIX. ¿Y? Sigue…   » ver todo el comentario
#46 Pero es que Linux puede o no puede usar las utilidades GNU sin dejar de ser una distribución Linux tradicional.

Android es un SO con kernel Linux pero no es un SO Linux tal como entendemos habitualmente.

Pero es que la cuestión de peso es que glibc y las gnu-utils no son la base del sistema GNU, sino que es la capa de compatibilidad POSIX y que además muchas ni tan siquiera se implementaron ni en hi para GNU, sino para diferentes sabores UNIX.

Y sobre todo, es que hi conceptualmente, ni…   » ver todo el comentario
#47 Android no es un SO Linux como lo entendemos habitualmente, posiblemente porque estos son GNU/Linux (o pueden no serlo pero lo que sí son es equivalentes) y Android no lo es (va a su bola y no hace casi nada de lo que hace una distro Linux con las utilidades GNU).

No he entendido muy bien tus tercer y cuarto párrafo. No entiendo a lo que quieres llegar, que las utilidades GNU con Linux, con Hurd o con BSD no funcionan igual porque lo que hay debajo no es lo mismo y no lo pueden hacer (incluso el que haya que poner o quitar aplicaciones) no veo en qué afecta a que esas utilidades básicas que necesita el SO las hayan programado desde el proyecto GNU en todos esos casos.
#46 Perdón por el offtopic, pero yo creo que los que tendrían que cambiarse el nombre son los sufijos de los múltiplos de 1000, ya que Kb es kilobyte de toda la vida. Si quieres cambiar los múltiplos, utiliza otra nomenclatura, pero no obligues a cambiar el original, porque aparte de hacer obsoleta la literatura anterior, no tiene sentido.

Pero igual me equivoco.
#70 Ya, pero es que lo han hecho porque los prefijos K, M,..., ya existían mucho antes como múltiplo de mil, por ejemplo Km (kilómetro, 1000 metros),..., y es sólo en informática, algo bastante reciente, cuando se ha usado como múltiplo de 1024. En el fondo lo más lógico es lo que han hecho: mantener la nomenclatura más antigua y de uso más amplio y modificar la nomenclatura más reciente y específica, la informática.

Eso sí, lo de la literatura va a ser un follón que va a durar décadas. :palm:
#71 Lo de los prefijos es cierto, es el sistema internacional, pero en este caso tan específico, en el que ya existe una cultura internacional homogénea al respecto ( no es lo mismo que usar onzas o galones ), me parece absurdo. También se siguen usando las millas marinas, y los nudos para velocidad marina y aérea, y no se ha muerto nadie ( bueno, sí, la Mars Climate xD ), querer revertir un estándar global de este calibre me parece absurdo, y de hecho en mi opinión no han conseguido nada.…   » ver todo el comentario
#72 Creo recordar que el problema que originó el cambio se debe a que los fabricantes de hardware utilizan múltiplos de 1000 en vez de múltiplos de 1024. De ahí que si compras una unidad de 1TB (según el fabricante) no tenga un TiB ni de lejos (y la culpa no es del formateo, por mucho que ellos afirmen eso). Y creo recordar que a pesar de haber sido denunciados en varias ocasiones por ello resulta que han ganado los juicios, con lo que pueden seguir usando múltiplos de 1000 por su cara bonita.

Así que no quedaba otra, o usar una unidad que para los fabricantes es una cosa y para los consumidores es otra o cambiar de unidades.

Lo de los jueces y la informática eso sí que no tiene explicación.
#73 Eso puede influir también, pero es cierto que en algunos ámbitos no se puedan permitir tales ambigüedades en la nomenclatura ( véase el caso de la ya mentada Mars Climate, el tiro al plato más caro de la historia :-D ), y también el sector de transmisión de datos vía internet, que tradicionalmente ha usado siempre kilobits de base 10, con lo cual ya tenemos el pollo montado.

Mi opinión es que es más sencillo mantener en este caso lo que ya todo el mundo había aceptado como un estándar. Lo de los discos duros, en realidad da un poco igual cuando le coges el tranquillo, cuando todo el mundo sabe que sus TB no son los mismos que los del resto, ya calculas un 20% menos a ojo, el truco no va a durar toda la vida...
#74 Hay un montón de servicios, aplicaciones,'sistemas operativos, fabricantes que utilizan medidas en bytes y no hay forma de saber si usarán múltiplos de 1000 o de 1024.

Como dices es tu primer párrafo no se pueden permitir ambigüedades, no puedes depender de aplicar un truco a ciegas sin saber si vas a acertar o no.

Además, tampoco es un 20% de diferencia, esta crece conforme aumenta el valor, entre KB y KiB es de un 2,4%, entre GB y GiB es de un 7,37%,...

Pero lo peor es que hasta que no pase un tiempo, todo el mundo adopte el nuevo sistema y "desaparezcan" las aplicaciones y la bibliografía que están obsoletas tampoco lo estás. Una cagada enorme por culpa de una decisión judicial :palm:
#14 se refiere a Hurd no a Linux.
#11 ¡Hooostias!
#11 madre mia colega, tu comentario da CÁNCER.
Lider de un proyecto fracasado? Seguro que tu eres capaz de montar un kernel y un ssoo como UNIX o POSIX desde cero, y en un par de horitas... Madre mia vaya lammer...
#9, los más puristas no, Linus Torvalds mismo no es partidario del uso del termino GNU/Linux (aunque tampoco lucha contra ello) :-P
#15 Bueno, los más puristas no. Los más pedantes.
El tema de la mejora para AMD ya tocaba....

#0 las perdidas de rendimiento son iguales que las que hay en windows?
#3 No sabria decirte, no uso windows en mis equipos personales y en los de mi trabajo (donde si tengo win) el rendimiento es igual de malo antes y despues del parche, por ahora mi unico problema viene siendo que VirtualBox me dejo de funcionar con el repositorio oficial de Ubuntu, pero se arregla insralando la ultima version desde la web de VB
#3 Si usan la técnica o método "retpoline" optimizado de AMD, no solo hay pérdida sino una pequeña o mayor ganancia en procesadores Ryzen y EPYC.

Fíjate en las gráficas donde ponen "Minimal AMD retpoline" y básicamente en las barras de color gris.

www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.

Salu2
Lo acabo de instalar e Instagram va más rápido
#6 Te hemos cazado la mentira. Todo el mundo sabe que un verdadero linuxero lo primero que hubiese probado es xhamster.
#21 mentira. Hubiese compilado el kernel quitando todos los modulos y features que no necesita. Mientras, en terminal, hubiese visto xvideos en ascii
#26 parece el plus:  media
que bien. intel ya ha corregido las meteduras de pata de las semanas anteriores? o esto va de parte de linus y sus amigos?
#7 Intel no puede solucionar el problema, sólo han emitido parches de seguridad para mitigar el riesgo.
#8 y esos parches hacen que se reinicien los servidores aleatoriamente. han corregido esos problemas? ya no se reinician?
#10 Aleatoriamente no... sólo cuando es posible que pudiese ser explotado alguno de los fallos.
#8 Ha publicado y han aconsejado no aplicar esa actualización ya que provoca reinicios aleatorios.
#7 Esto va de Linus y sus amigos. Hasta que no saquen una actualización de las CPUs en condiciones seguiran afectados los equipos aunque los parches del kernel dificultan muchisimo su explotación. De todas formas al ser un problema de diseño de las CPU, me da que el "parche" de Intel va a ser más de lo mismo y tampoco solucionarán el problema.
# head /sys/devices/system/cpu/vulnerabilities/*
Y ahora mi pregunta porque tengo un poco de lío (también reconozco que no me he dejado los ojos buscando información, mea culpa): ¿para solucionar el agujero de seguridad es suficiente con actualizar Linux, es suficiente con actualizar la BIOS o es necesario actualizar las dos cosas para que sirva de algo?
#18 necesitas cambiar la CPU por una que no tenga esos agujeros. Los parches del Kernel y de Intel solo dificultan su explotación, arreglan el error para el tipo de ataque publicado, pero no sé sabe si hay más posibilidades de ataque que sigan funcionando aún con estos parches.
#30 gracias por la explicación.

Supongo que es mejor actualizar tanto firmware como sistema operativo que solo una de las dos cosas, ¿no?
#42 sí, claro, lo suyo es actualizar todo, pero viendo que intel ha recomendado no instalar alguno de los parches yo esperaría a instalarlo. Realmente es difícil de explotar, y si estás en la nube los proveedores ya han hecho lo pertinente para que no puedas acceder a la memoria de otra VM que esté funcionando en la misma máquina física.
#18 Para "solucionar" el agujero... es necesario actualizar el procesador, cuando tengan a bien sacar nuevos sin estos fallos, y/o les dé la gana sacar parches de microcódigo (estos pueden ir incluidos en una actualización de la BIOS, o cargarse con el kernel, o como sea).
Pero por el momento eso no existe, así que lo que se puede hacer es actualizar Linux (el kernel) para evitar las consecuencias más graves de estos fallos. Seguirán existiendo en el sistema afectado, pero "se supone" que no afectarán "tanto" a la seguridad de todas las cosas.
Mitigar? Suena a puta mierda.
#37 Eso decía Linus el otro día :-D
Y se deberán en algunos casos compilar (por enésima vez) controladores para el nuevo kernel

¡que bien!
#44 no sé qué pŕoblema le ves, la verdad, lo que haya que compilar que dependa del kernel son cosas que se deberían hacer de manera automática. Además, hay mejoras.
«En la ‘gran’ fotografía, 4.15 se ve perfectamente normal, con dos tercios de todos los parches de 4.15 yendo a parar a los drivers, no para mitigaciones de errores de la CPU”»
#48
**
#44 no sé qué pŕoblema le ves, la verdad, lo que haya que compilar que dependa del kernel
**
En las horas (muchos) que me he pasado yo para instalar los controladores de nvidia de mi tarjeta y funcionaran...
Simplemente no podían compilar e instalarse si estaba el controlador "nouveau" cargado en el kernel en modo texto al arrancar el PC (se ha de cargar el VESA genérico, desinstalar nouveau y que no haya rastro y luego pasar a compilar y…   » ver todo el comentario
#49 la cuestión es que salen nuevos kernels continuamente, de manera periódica así que que saquen una nueva versión no depende de Meltdown u otros bugs...
#49 Pues no sé que usarás tu, pero en mi sistema el controlador de nvidia se compila el solito automáticamente cuando hay alguna actualización, conviviendo perfectamente con nouveau, y no son horas lo que tarda, más bien segundos... De todas formas, me pregunto que tendrá que ver el que venga el kernel 4.15 con los parches para mitigar la posible explotación de la vulnerabilidad y los controladores gráficos...
#53 tardé muchas horas en poder hacer que rulara por problemas. Algunas tarjetas NVIDIA necesitan imperiosamente que el nouevau no esté presente (no todas, pero la mía es una de ellas) de ninguna forma y se afectan mútuamente

*
el kernel 4.15 con los parches para mitigar la posible explotación de la vulnerabilidad y los controladores gráficos...
**

El tener que volver a compilar con riesgo de que el sistema deje de funcionar y que algunas tarjetas NVIDIA parecen sensibles también a alguna de esas vulnerabilidades
#56 pues en realidad lo que ha hecho es ralentizar el desarrollo así que no sé que es lo que te parece mal: www.meneame.net/story/realizacion-linux-4-15-convierte-version-mas-len

Si no quieres que esté noveau desistálalo y márcalo para que no se instale. Y lo de compilar me suena raro, como si estuvieras usando gentoo. Yo uso Arch (Manjaro) y sólo compilo lo que necesito y nunca he compilado cosas gordas (kernel, drivers) precisamente porque a) se tarda la vida. b) mi ordenador no tiene espacio suficiente para compilar cosas de varios gigas.

¿Seguro que no tienes otra opción?
#60
**
Si no quieres que esté noveau desistálalo y
**
No es que no quiera sino que el driver concreto y nouveau no pueden estar presentes a la vez, O falla la composición y otras cosas... Se llevan mal, el driver propietario es que lleva montón de versiones de archivos de las X y de openGL

*
¿Seguro que no tienes otra opción?
*
No, pero ya me he acostumbrado... Cuando empecé en GNU/linux entonces la slackware 2.0 ya le cogí costumbre, controlar bibliotecas, versiones...

Es lo que hay pues en fin
#66 espero que no me pase lo mismo alguna vez porque suena difícil.
#56 Algunas no, todas, no puedes tener dos módulos cargados para el mismo dispositivo. En mi sistema, la misma instalación/actualización de nvidia mete los módulos en blacklist y carga el que yo le diga. Como he dicho, se compila en segundos el solo si hay actualización de éste o del kernel. No sé que distro usas tú, pero imagino que en tu caso usas el controlador de nvidia en lugar del que te proporciona tu distro. No necesita que esté "descargado" el controlador libre, el error que…   » ver todo el comentario
#63
+***
En mi sistema, la misma instalación/actualización de nvidia mete los módulos en blacklist y carga el que yo le diga.
**
Cierto pero en el mio tenía en modo a prueba de fallos tenía el nouveau corriendo. En algunas nvidia es necesario instalar el VESA general, desinstalar manualmente el nouevau, reiniciar, compilar e instalar el NVIDIA si es ese

*
Como he dicho, se compila en segundos el s
*
En minutos. Pero si te falla algo no puedes…   » ver todo el comentario
comentarios cerrados

menéame