Versión para imprimir
Acabo de leer esta noticia, no voy a mentir, la mitad de lo que dicen me pasa muy por arriba y por ahí es tremendamente sensacionalista y me la comí enterita, pero lo que más me preocupó es que aparentemente el patch que van a implementar implicaría aislar parte de la memoria disponible lo cual resultaría en procesadores "entre 5 y 30% más lentos".
https://gizmodo.com/report-all-intel...-mi-1821728240
Lo dejo por acá para que alguien con sabiduría nos ilumine.
No estoy siguiendo de cerca esto pero lo mas curioso es que los patchs que menciona Tomcat afectan la performance de todo procesador x86, incluso los AMD, que en principio son inmunes al estar correctamente diseñados.
Por que sera que sucede esto..?
https://www.techpowerup.com/240187/a...kernel-patches
Espero que no sean tan hinchahuevos de meter el parche a prepo y dejen deshabilitarlo a los que vamos por el lado rojo.
Arranco el bardo:
Aguante amd vieja!
Intel come.
Enviado desde mi Redmi 3S mediante Tapatalk
hagan lo que hagan intel siempre gana
capaz que tiene relacion con el sistema operativo que corren todos los procesadores intel que se hablo hace un tiempo
edit: minix https://www.networkworld.com/article...-to-intel.html
edit2: estoy tirando fruta wexd
Yo tambien vi eso y no entendia nada...
Que aparezca @REN o @SEndero Luminoso y nos empapen de una guerra de opiniones encontrados.
Queremos shubia en el foro.
En caso de que el problema sea solucionable a través del SO (cosa que no creo), es bien simple, pasaran a existir 2 forks de todo sistema operativo de aquí en mas, uno para Intel y otro para AMD, posiblemente este de AMD se use para Intel también si arreglan el defecto en futuros diseños. Aunque en realidad posiblemente toda empresa (que serán las mas afectadas por lo que vi dada la falla, no el usuario normal) que tenga un Intel y no sea un sistema critico lo tire a la basura, pero igual siempre habrá equipos que simplemente son muy difíciles de cambiar por lo cual un fork independiente sera necesario.Cita:
Iniciado por DESCHAIN
Y cuando digo no creo que sea solucionable a través del SO es porque por lo que eh visto lo que hacen a través del SO es simplemente dejar de realizar determinadas instrucciones, las deshabilitan, y eso no es una solución.
También, los únicos "patch" que hay hoy serian para Linux.
P.D. Vi que hay una supuesta versión beta de windows con patch.
P.D.2: Lo de los forks es en caso de que no quieran discriminar que tipo de CPU es.
SEndero, lo lógico sería que hubiera ese fork como bien decís, peeero el resultado no está siendo ese.
Cmentaba en forma sarcástica en el sentido de que Intel esta esgrimiendo su influencia en el mercado de software, y si se publican "soluciones" que tengan impacto negativo en performance, se está asegurando de que afecten en la misma medida a procesadores AMD y no solo sus micros con diseño defectuoso.
Acá el el bug "demostrado o explotado"...
https://pbs.twimg.com/media/DSn30-UW4AEV13B.jpg
https://twitter.com/brainsmoke/statu...61799875502080
También, pequeña coincidencia https://www.fool.com/investing/2017/...-of-stock.aspx
Segun lo que entendi y lei esta muy relacionado al set VT de Intel. Asumo que apagando la virtualizacion desde BIOS deberia mitigar el problema, pero no creo que ni el problema ni el parche que come rendimiento afecten al usuario normal.
FuenteCita:
Meltdown and Spectre exploits impact Intel, ARM, and AMD processors
Aca estan los papers originales de los que reportaron la falla y varios links para informarse mejor:
https://meltdownattack.com/
y esta entrada del blog de Project Zero esta muy intersante e informativa:
https://googleprojectzero.blogspot.c...with-side.html
alguien que haga un video
:buscemi:
En los link de arriba encontré esto:
- Linux, on an i7 6700, calling the getpid syscall 100,000,000 times:
- Before the patch: ~3.8 seconds.
- After the patch: ~15 seconds.
- PostgreSQL, a database application, i7-6820HQ, SELECT 1 benchmark:
- Before the patch: 420490.162391 transactions per second
- After the patch: 350746.065039 transactions per second
Para juegos aparentemente el Fix no afecta para nada (en Linux).
Por lo que leí rápidamente eliminan ciertas instrucciones en procesadores Intel.
Como que recortas el micro y en las pruebas la perdida de rendimiento es notoria.
https://www.phoronix.com/scan.php?pa...l-Gaming-Tests
Ese articulo es básicamente cualquiera.Cita:
Iniciado por lordfps
Versión resumida en fotito...
https://www.techpowerup.com/img/gjPnHPXOLZEN8Hrm.jpg
https://lkml.org/lkml/2018/1/3/797
Código:From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.
Why is this all done without any configuration options?
A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.
I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.
.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.
Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?
Because if that's the case, maybe we should start looking towards the
ARM64 people more.
Please talk to management. Because I really see exactly two possibibilities:
- Intel never intends to fix anything
OR
- these workarounds should have a way to disable them.
Which of the two is it?
Linus
Sobre Meltdown:
Cita:
Implications
A short summary of what this security bug means:
- Code utilizing this exploit works on Windows, Linux, etc., as this is not a software- but a hardware issue.
- It is possible to dump arbitrary kernel memory with unprivileged user space applications.
- Reading kernel memory implies reading the memory of the whole system on most 64 bit operating systems, i.e. also memory from address spaces of other processes.
- Fully virtualized machines are not affected (guest user space can still read from guest kernel space, but not from host kernel space).
- Paravirtualized machines are affected (e.g. Xen PV).
- Container solutions like Docker, LXC, OpenVZ are all equally affected.
- The Linux KPTI / KAISER patches mitigate Meltdown effects on Linux.
- Most modern processors, in particular with Intel microarchitecture since 2010, are affected.
- We have no evidence that this attack is successfully deployable on ARM or AMD, although the underlying principle applies to all contemporary superscalar CPUs.
- Meltdown is distinct from the Spectre attacks, which became public at the same time.
Por ahi lei como que la arquitectura de AMD no permite hacer llamadas especulativas directo a la memoria del kernel y por eso zafaba, capas es humo que tiraron, no se si alguno leyo lo mismo para confirmar o desmentirlo?
https://spectreattack.com/spectre.pdfhttps://uploads.tapatalk-cdn.com/201...983b3a7ace.jpg
Enviado desde mi Redmi 4X mediante Tapatalk
Interesante va a hacer el malon que entrara en proceso de GTIA en el mundo. . . de eso no me imagino que safen.
Arranca lindo el 2018
Enviado desde mi SM-J120M mediante Tapatalk