Comet Ice

Could I cool down the Earth by capturing a comet and dropping it in the ocean, like an ice cube in a glass of water?

Daniel Becker

No. In fact, it's honestly sort of impressive to find a solution that would actively make the problem worse in so many different ways.

Dropping a comet into the ocean to cool the planet, famously suggested by the 2002 Futurama episode None Like It Hot,[1] wouldn't work for a few reasons.

One is that dropping things from space creates heat. When water—or anything else—falls, it gains kinetic energy. When it stops falling, that energy has to go somewhere. Generally, it turns into heat. Water that goes over Niagara Falls, for example, gains enough kinetic energy during the 50-meter plunge to warm it up by about 0.1°C by the time it reaches the bottom. (This added heat is minor compared to the cooling effects of evaporation on the way down, so the actual temperature at the bottom is likely colder.)

Outer space is a lot higher up than Niagara Falls,[citation needed] so the plunge down into the atmosphere at the bottom of Earth's gravity well adds a lot more than 0.1 degrees worth of heat. A chunk of ice from space that falls to Earth gains enough energy to warm the ice up, melt it, boil it into vapor, and then heat the vapor to thousands of degrees. If you built an icy waterfall from space, the water would arrive at the bottom as a river of superheated steam.

Small chunks of ice falling from space disintegrate and boil away before they reach the ground, warming the upper atmosphere. Large comets can reach the ground intact and be vaporized on impact as their kinetic energy is converted to heat all at once. This heat energy would be about 100 times greater than the energy needed to bring even a very cold comet up to room temperature, so a comet falling from space would heat the Earth 100 times more than it cooled it.

But let's suppose you figure out a way to lower the comet slowly, using some kind of magical crane,[2] and gently set the comet in the ocean.

Comets are more dust than ice, but they're not particularly dense. A tiny piece of a comet would float for a short time until it became waterlogged, melted, and broke apart. A full-size comet wouldn't be strong enough to support its own weight, and would collapse like a drying sand sculpture.

If the comet were placed in the ocean,[3] the added ice would cool the water down by only about a millionth of a degree. If you set the comet on land, it would soak up heat from the atmosphere—which contains much less stored heat than the oceans—briefly cooling the air by an average of one or two thousandths of a degree.

Okay, so we just need thousands of comets, right? Each one will cool the air a little bit. With a large enough supply of comets, we can keep the Earth nice and cool, as long as we make sure they're lowered slowly.

Unfortunately, comets would affect the Earth's temperature in another way. In addition to dust and water, they contain a small amount of CO2, which would be released into the atmosphere as the comet melted. This CO2[4] would change Earth's radiation balance, trapping heat near the surface and raising the planet's temperature. After a few years, the comet's greenhouse effect would have trapped more heat than the ice absorbed, and over the decades to follow, the extra heat would keep piling up.

The CO2 released from the comet would raise the temperature of the Earth for centuries. It wouldn't just cancel out the cooling effect of the ice—over time, the comet's greenhouse effect would deliver as much heat as if you'd just let it slam into the planet and vaporize.[5]

It's okay. Despite all this, your scenario could fix global warming.

Remember that hypothetical crane that lets you lower comets to the surface? Well, if you hooked it up to a generator, you could use the slowly-descending comet to produce electricity.

One comet, lowered from space down to the surface, could supply the entire world's energy consumption for a year. Sure, it would release a little CO2, but it would be nothing compared to the pollution from our current sources of energy. A comet crane generator could cut our energy-related greenhouse gas emissions to almost zero. The comet isn't the important part, the crane is.

Sadly, we don't have the technology to build comet-lowering cranes—certainly not in time to help mitigate climate change. But harvesting orbital energy like this is a neat idea! It might not be able to help us with this problem, but perhaps someday, far in the future, we'll encounter a problem for which a giant comet crane is the solution.

[1] I'm used to stuff making me feel old, but the fact that this episode aired 20 years ago is distressing in multiple ways.

[2] Magical storks deliver babies, magical cranes deliver comets.

[3] It actually wouldn't have much effect on global sea level, but the influx of cold water on the surface—and the dust released into the air—could definitely mess with the atmosphere.

[4] Along with carbon monoxide, which indirectly affects the climate in a similar way—see pg. 718-719 of the IPCC WG1 AR5 report for more.

[5]

from what if? https://ift.tt/TjQ3RaV
via IFTTT

Encontraron una vulnerabilidad en Snap que permite ejecutar codigo con privilegios root

vulnerabilidad

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días Qualys dio a conocer la noticia de que ha identificado una vulnerabilidad grave (ya catalogada bajo CVE-2022-3328) en la utilidad snap-confine, que se envía con el indicador root SUID y el proceso snapd la llama para formar un entorno ejecutable para aplicaciones distribuidas en paquetes formato snap.

Se menciona que la vulnerabilidad permite que un usuario local sin privilegios logre la ejecución del código como root en la configuración predeterminada de Ubuntu.

Curiosamente, la vulnerabilidad en cuestión se introdujo en el proceso de corregir una vulnerabilidad similar de febrero en un snap-confine.

¿Qué impacto tiene CVE-2022-3328?

Qualys detalle en su informe que la vulnerabilidad en snap-confine es causada por una condición de carrera en la función must_mkdir_and_open_with_perms(), agregada para proteger contra la sustitución del directorio /tmp/snap.$SNAP_NAME por un enlace simbólico después de la verificación del propietario, pero antes de la llamada al sistema de montaje se llama para enlazar directorios de montaje en él para un paquete en formato span.

La seguridad agregada fue cambiar el nombre del directorio /tmp/snap.$SNAP_NAME a otro directorio en /tmp con un nombre aleatorio si existe y no es propiedad del usuario root.

Al explotar la operación de cambio de nombre del directorio /tmp/snap.$SNAP_NAME, los investigadores aprovecharon el hecho de que snap-confine también crea un directorio /tmp/snap.rootfs_x para el contenido del paquete snap. mkdtemp() que elige aleatoriamente la parte «x del nombre, pero un paquete llamado «rootfs_x» puede pasar por sc_instance_name_validate (es decir, la idea es tener $SNAP_NAME establecido en «rootfs_x» y luego la operación de cambio de nombre dará como resultado la sobrescritura el directorio /tmp/snap.rootfs_x con el root en snap).

Para lograr el uso simultáneo de /tmp/snap.rootfs_xx y el cambio de nombre de /tmp/snap.$SNAP_NAME, se iniciaron dos instancias de snap-confine.

Tan pronto como la primera instancia creaba /tmp/snap.rootfs_xx el proceso se bloqueaba y se iniciaba una segunda instancia con el nombre de paquete rootfs_x, lo que provocaba que el directorio temporal de la segunda instancia /tmp/snap.$SNAP_NAME se convirtiera en /tmp/snap .rootfs_x (directorio root) de la primera instancia.

Inmediatamente después de realizar el cambio de nombre, la segunda instancia falló y /tmp/snap.rootfs_x se reemplazó con manipulación de condiciones de carrera, como en la explotación de la vulnerabilidad de febrero. Después del cambio, el bloqueo de ejecución se eliminó de la primera instancia y los atacantes obtuvieron control total sobre el directorio raíz instantáneo.

El último paso fue crear un enlace simbólico /tmp/snap.rootfs_x/tmp que fue utilizado por la función sc_bootstrap_mount_namespace() para enlazar y montar el directorio real grabable /tmp a cualquier directorio en el sistema de archivos, ya que la llamada mount() sigue enlaces simbólicos antes del montaje. Dicho montaje está bloqueado por las restricciones de AppArmor, pero para eludir este bloqueo, el exploit utilizó dos vulnerabilidades auxiliares en multipathd.

La explotación exitosa de las tres vulnerabilidades permite que cualquier usuario sin privilegios obtenga privilegios de root en el dispositivo vulnerable. Los investigadores de seguridad de Qualys verificaron la vulnerabilidad, desarrollaron un exploit y obtuvieron privilegios completos de raíz en las instalaciones predeterminadas de Ubuntu. 

Tan pronto como la Unidad de Investigación de Amenazas de Qualys confirmó la vulnerabilidad, nos involucramos en la divulgación responsable de la vulnerabilidad y nos coordinamos con los proveedores y las distribuciones de código abierto para anunciar esta vulnerabilidad recién descubierta. 

Los investigadores pudieron preparar un exploit funcional que brinda acceso al root en Ubuntu Server 22.04, que, además de la vulnerabilidad de snap-confine, también involucra dos vulnerabilidades en el proceso multipathd (CVE-2022-41974, CVE-2022-41973) relacionado con la omisión de permisos al pasar comandos privilegiados y el manejo inseguro de enlaces simbólicos.

Cabe mencionar que el problema se solucionó en el lanzamiento de snapd 2.57.6, ademas de que se han lanzado actualizaciones de paquetes para todas las ramas compatibles de Ubuntu.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/xmVpveZ
via IFTTT

Mesa 22.3.0 llega con mejoras para sombreadores, extensiones y mas

Mesa Drivers

Mesa es una biblioteca gráfica de código abierto, desarrollada que proporciona una implementación genérica de OpenGL

Hace poco se dio a conocer el lanzamiento de la nueva versión de la implementación de la API OpenGL y Vulkan «Mesa 22.3.0», siendo esta la primera versión de la rama Mesa 22.3.0 que tiene un estado experimental y que posteriormente (después de la estabilización final del código), se lanzará una versión estable 22.3.1.

En Mesa 22.3, la compatibilidad con la API de gráficos Vulkan 1.3 está disponible en anv para GPU Intel, radv para GPU AMD y en modo emulador (vn). La compatibilidad con Vulkan 1.1 se implementa en el rasterizador de software lavapipe (lvp) y Vulkan 1.0 en el controlador v3dv (GPU Broadcom VideoCore VI de Raspberry Pi 4).

Principales novedades de Mesa 22.3.0

En esta nueva versión que se presenta se añadió el controlador freedreno para las GPU Qualcomm Adreno es compatible con la API de gráficos OpenGL 4.5 y el controlador del emulador (vn) es compatible con la API Vulkan 1.3.

Otro de los cambios que se destaca de esta nueva versión es que se agregó soporte para GPU GFX11/RDNA3 (serie Radeon RX 7000) en RADV (AMD) Vulkan Driver, ademas de que se agregó compatibilidad con los formatos de píxeles R8G8B8, B8G8R8 y R16G16B16, así como con los formatos de búfer de vértice de 64 bits.

Tambien podremos encontrar que en Mesa 22.3.0 el controlador Rusticl se incluye con la implementación de la especificación OpenCL 3.0, que define la API y las extensiones del lenguaje C para organizar la computación paralela multiplataforma. El controlador está escrito en Rust, desarrollado utilizando la interfaz Gallium proporcionada en Mesa y actúa como un análogo de la interfaz Clover OpenCL presente en Mesa.

Clover lleva mucho tiempo en estado de abandono y rusticl se posiciona como su futuro reemplazo. La compatibilidad con Rust y Rusticl está deshabilitada de forma predeterminada y requiere compilación con opciones explícitas «-D gallium-rusticl=true -Dllvm=enabled -Drust_std=2021«. Cabe mencionar que al compilar, se requieren el compilador rustc, bindgen, LLVM, SPIRV-Tools y SPIRV-LLVM-Translator como dependencias adicionales.

Ademas de ello, el controlador RadeonSI tiene soporte para renderizado de subprocesos múltiples a través de OpenGL habilitado de forma predeterminada, mientras que el controlador Panfrost implementa la capacidad de almacenar en caché los sombreadores en el disco y agrega soporte para la GPU Mali T620.

De los demás cambios que se destacan en Mesa 22.3.0:

  • Se presenta Mesa-DB, un nuevo tipo de caché de sombreado que almacena datos en un solo archivo.
  • El controlador es compatible con la especificación OpenGL 3.1 y OpenGL ES 3.1.
  • El código para el trazado de rayos se ha optimizado.
  • Se agregó soporte para el indicador extendedDynamicState2PatchControlPoints, que define el soporte para la extensión VK_EXT_extended_dynamic_state2.
  • Analizador de trazado de rayos Radeon integrado.
  • Se agregó soporte para extensiones OpenGL: GL_ARB_shader_clock para llvmpipe, GL_KHR_blend_equation_advanced_coherent para zinc, GL_NV_shader_atomic_float para llvmpipe.
  • Se agregó soporte para las extensiones de Vulkan: VK_KHR_shader_clock para lavapipe, VK_EXT_attachment_feedback_loop_layout para RADV, lavapipe, VK_KHR_global_priority para RADV, VK_EXT_load_store_op_none para RADV, VK_EXT_mutable_descriptor_type para RADV, VK_EXT_shader_atomic_float para lvp, VK_EXT_shader_atomic_float2 para lvp, VK_EXT_image_robustness para v3dv., VK_EXT_extended_dynamic_state3 para lavapipe, RADV y ANV, VK_EXT_extended_dynamic_state2 para RADV.

Finalmente si estás interesado en conocer más al respecto sobre esta nueva versión de los controladores Mesa, puedes consultar los detalles en el siguiente enlace.

¿Cómo instalar los drivers de video Mesa en Linux?

Los paquetes de Mesa se encuentran en todas las distribuciones de Linux, por lo que su instalación puede realizarse ya sea descargando y compilando el código fuente (toda la información al respecto aquí) o de una forma relativamente sencilla, la cual depende de la disponibilidad dentro de los canales oficiales de tu distribución o de terceros.

Para los que son usuarios de Ubuntu, Linux Mint y derivados pueden añadir el siguiente repositorio en donde los controladores son actualizados de manera rápida.

sudo add-apt-repository ppa:kisak/kisak-mesa -y

Ahora vamos a actualizar nuestro listado de paquetes y repositorios con:

sudo apt update

Y finalmente podemos instalar los drivers con:

sudo apt upgrade

Para el caso de los que son usuarios de Arch Linux y derivados estos los instalamos con el siguiente comando:

sudo pacman -S mesa mesa-demos mesa-libgl lib32-mesa lib32-mesa-libgl

Para quienes sean usuarios de Fedora 32 pueden utilizar este repositorio, por lo que deben de habilitar corp con:

sudo dnf copr enable grigorig/mesa-stable

sudo dnf update

Finalmente, para los que son usuarios de openSUSE, pueden instalar o actualizar tecleando:

sudo zypper in mesa

from Linux Adictos https://ift.tt/4P6bAsN
via IFTTT