OpenWrt ya se encuentra trabajando en su propio rúter inalámbrico

OpenWrt One

OpenWrt One (AP-24.X)

Con motivos de celebración del vigésimo aniversario del proyecto OpenWrt, los desarrolladores de la distribución dieron a conocer mediante las listas de correo, una iniciativa en la cual proponen la creación de un rúter inalámbrico, el cual será desarrollado por la comunidad llamado OpenWrt One (AP-24.X).

Se menciona que este rúter se basará en hardware similar a las placas Banana Pi, específicamente en las BPi-R4, que cuentan con firmware abierto (excepto el firmware del chip inalámbrico), U-Boot y son compatibles con el Kernel de Linux, ademas de que el objetivo es proporcionar una plataforma abierta y accesible con un costo que no exceda los $100.

La configuración propuesta para OpenWrt One incluye las siguientes especificaciones de hardware:

  • SOC: MediaTek MT7981B
  • Wi-Fi: MediaTek MT7976C (2×2 2,4 GHz + 3×3/2×2 + DFS de espera cero 5Ghz)
  • RAM: 1 GiB DDR4
  • Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
  • Ethernet: 2x RJ45 (2,5 GbE + 1 GbE)
  • USB (host): USB 2.0 (puerto tipo A)
  • USB (dispositivo, consola): Holtek HT42B534-2 UART a USB (puerto USB-C)
  • Almacenamiento: M.2 2042 para NVMe SSD (PCIe gen 2 x1)
  • Botones: 2x (reset + usuario)
  • Interruptor mecánico: 1x para selección de arranque (recuperación, regular)
  • LED: 2x (controlados por PWM), 2x Led ETH (controlados por GPIO)
  • Vigilante de hardware externo: EM Microelectronic EM6324 (controlado por GPIO)
  • RTC: NXP PCF8563TS (I2C) con soporte de batería de respaldo (CR1220)
  • Alimentación: USB-PD-12V en el puerto USB-C (802.3at/afPoE opcional a través del módulo
  • RT5040)
  • Ranuras de expansión: mikroBUS
  • Certificación: Cumplimiento FCC/EC/RoHS
  • Caja: el tamaño de PCB es compatible con BPi-R4 y el diseño de la caja se puede reutilizar
  • JTAG para SOC principal: 10 pines con paso de 1,27 mm (ARM JTAG/SWD)
  • Conectores de antena: 3x MMCX para fácil uso, montaje y durabilidad
  • Esquemas: estarán disponibles públicamente (licencia por determinar)
  • Cumplimiento de GPL: 3b.
  • Precio: apuntando a menos de $100

Además de ello, se menciona que una de las características clave es el enfoque en la durabilidad y protección del dispositivo contra daños, ya que el rúter ofrecerá múltiples modos de recuperación, fácil acceso a la consola y la implementación de un monitor de vigilancia de hardware externo basado en el chip EM Microelectronic EM6324 conectado a través de GPIO.

Adicionalmente, para aumentar la confiabilidad, se ha optado por el uso simultáneo de dos unidades Flash de diferentes tipos: NAND para el cargador de arranque U-Boot y la imagen de Linux, y NOR Flash protegido contra escritura con un cargador de arranque adicional y una imagen de recuperación. Un interruptor de hardware permitirá elegir entre el arranque desde NOR o NAND. La inclusión de una ranura M.2 para NVMe proporcionará la posibilidad de arrancar distribuciones adicionales como Debian y Alpine desde NVMe.

La idea

No es nuevo. Hablamos de esto por primera vez durante las Cumbres OpenWrt en 2017 y también 2018. Quedó claro a principios de diciembre de 2023 mientras jugueteando con dispositivos estilo Banana Pi que ya son bonitos cerca de lo que queríamos lograr en ’17/’18. Los PI de banana han crecido en popularidad dentro de la comunidad. Arrancan usando un Trusted autocompilado Firmware-A (TF-A) y U-Boot ascendente (gracias MTK/Daniel) y algunas de las placas ya son totalmente compatibles con el kernel de Linux upstream. 
Los únicos componentes que no son de código abierto son el firmware PHY y Wi-Fi de 2,5 GbE, blobs que se ejecutan en núcleos separados que son independientes del SoC principal
ejecutando Linux y las rutinas de calibración DRAM que se ejecutan temprano durante el arranque.

Para mantener la hora precisa, el dispositivo incorporará un RTC basado en NXP PCF8563TS con una batería de respaldo. La venta y distribución del dispositivo estarán a cargo de la organización sin fines de lucro Software Freedom Conservancy, la cual se dedica a recaudar fondos de patrocinio y brindar protección legal al proyecto OpenWrt.

La idea es que BPi distribuya el dispositivo utilizando los canales ya establecidos y por cada dispositivo vendido se hará una donación a nuestro fondo SFC destinado a OpenWrt. Este dinero luego se puede utilizar para cubrir los gastos de alojamiento o tal vez una cumbre OpenWrt.

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/zfMp5o2
via IFTTT

La infraestructura de PyTorch fue comprometida

PyTorch

logo de PyTorch

Hace poco se dieron a conocer los detalles sobre un ataque que sufrió la infraestructura utilizada en el desarrollo del marco de aprendizaje automático PyTorch. Dentro de los detalles técnicos revelados, se menciona que el atacante logró extraer claves de acceso que le permitieron colocar datos arbitrarios en el repositorio de GitHub y AWS, reemplazar código en la rama principal del repositorio y agregar un backdoor a través de dependencias.

Este incidente plantea riesgos significativos, ya que la suplantación de versiones de PyTorch podría ser utilizada para atacar a grandes empresas como Google, Meta, Boeing y Lockheed Martin, que utilizan PyTorch en sus proyectos.

Hace cuatro meses, Adnan Khan y yo explotamos una vulnerabilidad crítica de CI/CD en PyTorch , una de las plataformas de aprendizaje automático líderes en el mundo. Utilizado por titanes como Google, Meta, Boeing y Lockheed Martin , PyTorch es un objetivo importante tanto para los piratas informáticos como para los estados-nación.

Afortunadamente, aprovechamos esta vulnerabilidad antes que los malos.

Así es como lo hicimos.

Sobre el ataque, se menciona que este se reduce a la capacidad de ejecutar código en servidores de integración continua que realizan reconstrucciones y ejecutan trabajos para probar nuevos cambios enviados al repositorio. El problema afecta a proyectos que utilizan controladores externos «Self-Hosted Runner» con GitHub Actions. A diferencia de las GitHub Actions tradicionales, los controladores autohospedados no se ejecutan en la infraestructura de GitHub, sino en sus propios servidores o en máquinas virtuales mantenidas por los desarrolladores.

La ejecución de tareas de compilación en sus servidores permite organizar el lanzamiento de código que puede escanear la red interna de una empresa, buscar en el FS local claves de cifrado y tokens de acceso, y analizar variables ambientales con parámetros para acceder a almacenamiento externo o servicios en la nube y con ello que a través de estos controladores, el atacante pudo ejecutar tareas de compilación en servidores propios, lo que permitió escanear la red interna de una empresa para buscar claves de cifrado y tokens de acceso.

En PyTorch y otros proyectos que utilizan Self-Hosted Runner, los desarrolladores pueden ejecutar trabajos de compilación solo después de que sus cambios hayan sido revisados. Sin embargo, el atacante logró eludir este sistema enviando primero un cambio menor y luego, una vez aceptado, obtenía automáticamente el estado de «colaborador» que permitía ejecutar código en cualquier entorno de GitHub Actions Runner asociado con el repositorio o la organización supervisora. Durante el ataque, se interceptaron claves de acceso de GitHub y claves de AWS, lo que permitió al atacante comprometer la infraestructura.

El enlace al estado de «colaborador» resultó ser fácil de eludir: basta con enviar primero un cambio menor y esperar a que se acepte en la base del código, después de lo cual el desarrollador recibe automáticamente el estado de participante activo. cuyas solicitudes de extracción pueden probarse en la infraestructura de CI sin una verificación por separado. Para lograr el estado de desarrollador activo, el experimento incluyó cambios cosméticos menores para corregir errores tipográficos en la documentación. Para obtener acceso al repositorio y almacenamiento de las versiones de PyTorch, durante un ataque al ejecutar código en el «Self-Hosted Runner», se interceptó el token de GitHub utilizado para acceder al repositorio desde los procesos de compilación (GITHUB_TOKEN permitía acceso de escritura), así como las claves de AWS involucradas para guardar los resultados de la compilación.

Como tal, se menciona que este problema no es específico de PyTorch y afecta a otros proyectos grandes que utilizan configuraciones predeterminadas para «Self-Hosted Runner» en GitHub Actions.

Además de ello, se ha mencionado la posibilidad de ataques similares en proyectos de criptomonedas, blockchain, Microsoft Deepspeed, TensorFlow y otros, con consecuencias potencialmente graves. Los investigadores han presentado más de 20 solicitudes en programas de recompensas por errores, buscando recompensas por valor de varios cientos de miles de dólares.

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/D6CUOVb
via IFTTT

Linux Mint 21.3 Edge ya disponible con el kernel Linux 6.5

Linux Mint 21.3 Edge

El momento más importante en lo que va de año para el Clem Lefebvre, su equipo y los usuarios de su sistema operativo tuvo lugar el pasado 14 de enero. En ese momento llegó Linux Mint 21.3 en su edición principal, es decir, la basada en Ubuntu LTS y con todo tal y como se espera. Más tarde tienen que llegar también otras dos ISOs: las de la versión basada en Debian (LMDE) y la Edge.

La primera de las dos ha sido anunciada hace unos instantes, y no hay mucha información porque no es necesario. La ISO Edge es básicamente lo mismo que la versión normal con base Ubuntu LTS a la que le añaden un kernel más actualizado para que pueda soportar hardware de equipos más nuevos. Es el equivalente al Hardware Enablement (HWE) de Canonical, cuando una versión LTS de Ubuntu actualiza su kernel e incluso se lanzan nuevas imágenes con un núcleo más moderno.

Linux Mint 21.3 Edge usa Linux 6.5

El kernel que usa Linux Mint 21.3 Edge es Linux 6.5, el mismo que hay en Ubuntu 23.10. Está marcado como EOL, pero esto es lo habitual en Ubuntu, quien añade un kernel mainline y es mantenido por Canonical hasta que suben a otro más actualizado o la versión que lo usa también deja de recibir soporte. Hay personas que pueden sentirse algo decepcionadas y habrían preferido que se usara Linux 6.6, pero no ha podido ser.

Linux Mint 21.3 Edge, como «Virginia» que es, incluye Cinnamon 6.0 como principal novedad. Aunque esta vez la nueva versión del escritorio tiene competencia en lo más destacado, ya que se ha incluido soporte inicial para Wayland. Entre otras novedades, hay disponibles nuevas «acciones» de Nemo y gestos para hacer zoom en el escritorio.

La imagen de Linux Mint 21.3 «Virginia» se puede descargar desde el siguiente botón.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

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

MX Linux 23.2, ya disponible, está ahora basado en Debian 12.4

MX Linux 23.2

Los desarrolladores de MX han lanzado hace unos instantes MX Linux 23.2. Esta es la segunda actualización de mantenimiento de «Libretto», y ha llegado mes y medio después de la v23.1. La versión de enero introdujo entre sus novedades más destacadas el soporte para la Raspberry Pi 5, y esta de febrero ha llegado, sobre todo, para corregir errores en esta versión que sigue basada, como no podía ser de otra manera, en Debian 12 .

«Bookworm» llegó en junio de 2023, y desde entonces Debian ha lanzado varias actualizaciones de mantenimiento. MX Linux 23.2 está basado en Bookworm, pero en ya su cuarta actualización de punto, más concretamente Debian 12.4. Lo que tenéis a continuación es una lista con las novedades más destacadas que ha introducido la tercera -dos y la cero- versión de Libretto.

Novedades más destacadas de MX Linux 23.2

  • Actualizaciones del instalador para la generación de fstab, simplificación de la interfaz gráfica y correcciones para los usuarios de la función «toram» live.
  • Nueva herramienta «MX Locale», para la gestión de la información de la configuración regional del sistema, el idioma predeterminado del sistema, etc.
  • Nueva herramienta «papirus-folder-colors», que es una pequeña y divertida herramienta para crear temas de la familia papirus con diferentes colores de carpetas.
  • La versión AHS Xfce incluye el kernel liquorix 6.6, firmware actualizado y librerías mesa.
  • La opción de auto-actualización se encuentra en MX-Packageinstaller ->Popular Apps -> Kernels.
  • La iso de KDE/plasma sustituye webcamoid por kamoso.
  • Las isos Xfce y fluxbox reemplazan webamoid por guvcview.
  • Correcciones en los temas mx-comfort para algunas aplicaciones que tenían texto blanco sobre fondo blanco y texto negro sobre fondo negro.
  • Paquetes «build-essential» ahora incluidos en iso, para aquellos usuarios que necesiten compilar algun driver y no puedan conectarse.
  • Pipewire 1.0
  • Manual actualizado.
  • Nueva opción de fondo de pantalla «MX LINUX Desert Landscape».
  • Muchas muchas actualizaciones de idiomas

Entre otras novedades, la versión principal (Xfce) y la Fluxbox se han actualizado al kernel 6.1 más reciente, mientras que la AHS usa el kernel 6.6 liqourix. Todas las ISOs se han actualiado con los últimos paquetes que llegan de repositorios de Debian y MX. La versión para la Raspberry Pi usa el último software disponible para su arquitectura.

Todas las novedades están disponibles para los usuarios existentes si actualizan por el medio habitual

Descargas disponibles en la nota de este lanzamiento.

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

Meshtastic, un proyecto de red de comunicaciones descentralizada para zonas de difícil acceso

Meshtastic

Capturas de pantalla de Meshtastic en Android

Hace poco se dio a conocer la noticia del desarrollo de un proyecto que permite utilizar las radios LoRa «Long Range», una tecnología de comunicación inalámbrica de bajo consumo de energía y larga distancia, diseñada para permitir la comunicación de dispositivos en el Internet de las cosas (IoT) y otras aplicaciones que requieren una transmisión de datos eficiente y de larga distancia.

Con el nombre de «Meshtastic», este proyecto tiene la finalidad de ofrecer una plataforma de comunicación abierta con el objetivo de establecer una red de mensajería descentralizada y autosuficiente, en la cual cada nodo se comunica directamente con sus nodos vecinos, sin depender de enrutadores centralizados.

El proyecto se desarrolla bajo la pauta de utilizar los transceptores basados en el protocolo LoRa, lo que permite la transmisión de datos a larga distancia sin necesidad de licencias y con el plus de alcanzar velocidades de varios kilobits por segundo y distancias de hasta cientos de kilómetros.

Como tal, el proyecto no tiene la finalidad de ser utilizado para las comunicaciones de las personas en general, ya que como se mencionó, la velocidad de los datos enviados se limitan a kbps. Es por ello que esta iniciativa, se presenta como una solución ideal para organizar las comunicaciones en zonas de difícil acceso, operaciones de búsqueda y rescate, coordinación de grupos en actividades turísticas o deportivas, en zonas sin infraestructura o en condiciones de mala cobertura del territorio por operadores celulares.

Meshtastic

Funcionamiento de Meshtastic

Se menciona que el largo alcance de las transmisiones es gracias al uso de transceptores autónomos que transmiten mensajes y funcionan con paneles solares, y los propios participantes pueden tener dispositivos LoRa locales que transmiten señales y se controlan conectándose a teléfonos inteligentes a través de Bluetooth.

La red Meshtastic permite a cada usuario participante realizar varias acciones dentro del sistema. Estas acciones incluyen el envío y recepción de mensajes de texto, así como la utilización de herramientas de geolocalización. Gracias a la estructura de red en malla, los mensajes se transmiten a lo largo de una cadena, asegurando que todos los miembros del grupo puedan recibir mensajes incluso del participante más distante. Esto ocurre independientemente de la capacidad de establecer un canal de comunicación directa con dicho participante.

Además de ello, se destaca que se permite el envío tanto de mensajes de difusión, que son recibidos por todos los participantes, como de mensajes direccionados a un participante específico. Para garantizar la seguridad de las comunicaciones, los mensajes transmitidos se cifran mediante claves PSK preseleccionadas (clave precompartida) utilizando el algoritmo AES256.

En cuanto al protocolo de transmisión, su funcionamiento es sencillo: cada paquete se envía en modo transmisión, y las ondas se analizan para confirmar la recepción por parte de uno de los participantes. En caso de que no se reciba la confirmación, se realizan tres intentos de envío adicionales después de un tiempo de espera predeterminado. Cuando un paquete es recibido, se verifica si ha llegado en el pasado; en caso afirmativo, se ignora, y en caso contrario, se retransmite a otros participantes. Con cada transmisión del paquete, el contador de saltos disminuye, y cuando llega a cero, la retransmisión del paquete se detiene. Este enfoque asegura una comunicación confiable y eficiente en la red Meshtastic.

Por la parte de las características clave del proyecto se destacan las siguientes:

  • Mensajería Descentralizada
  • Geolocalización y GPS
  • Seguridad de Mensajes utilizando claves precompartidas (PSK) y el algoritmo AES256, garantizando la seguridad de la comunicación.
  • Largo alcance ( récord de 254 km por kboxlabs )
  • No se requiere teléfono para la comunicación en malla
  • Comunicación descentralizada: no se requiere enrutador dedicado
  • Excelente duración de la batería
  • Enviar y recibir mensajes de texto entre miembros de la malla.

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

Para los interesados en el código del proyecto, deben saber que se ofrece el código para los transceptores y está disponible bajo la licencia GPLv3, y se han desarrollado aplicaciones móviles para plataformas Android e iOS, así como una interfaz web y una biblioteca Python para facilitar la automatización del envío y recepción de mensajes.

from Linux Adictos https://ift.tt/5CnopxK
via IFTTT

Vcc, un compilador basado en Clang diseñado para generar código ejecutable en Vulkan

logo de vcc

Vcc: el compilador de Vulkan Clang

En el panorama de las API de gráficos, los lenguajes de sombreado han enfrentado una limitación, pues a pesar de la posibilidad de escribir código en un subconjunto común entre GLSL, HLSL y C++, las restricciones actuales estas presentes.

Es por ello que nace Vcc (Vulkan Clang Compiler) el compilador Vulkan Clang, el cúal es un proyecto que estuvo en desarrollo durante 3 años, surge como una respuesta a estas limitaciones y desafíos. Este proyecto busca no solo superar las restricciones expresivas, sino eliminar el concepto mismo de lenguajes de sombreado.

Al incorporar la familia completa de lenguajes C/C++ a Vulkan, Vcc introduce características nunca antes vistas en los sombreadores de Vulkan, como punteros físicos, punteros genéricos, llamadas a funciones reales y un completo flujo de control.

Esta iniciativa busca cerrar la brecha de software entre las API de gráficos y de computación. Al hacer que Vulkan sea compatible con otras API de computación de GPU, Vcc se presenta como un paso importante hacia la unificación de la programación en gráficos y computación, alineándose con la adopción masiva y la calidad de implementación que caracterizan a Vulkan.

Sobre VCC

Vcc es un compilador basado en Clang diseñado para generar código ejecutable en Vulkan, tiene como objetivo, el posicionarse como un compilador capaz de traducir código C++ en una representación que pueda ejecutarse en GPU que soporten la API de gráficos Vulkan. A diferencia de los modelos de programación de GPU basados ​​en los lenguajes de sombreado GLSL y HLSL, Vcc toma la idea de eliminar por completo el uso de lenguajes de sombreado separados y brinda la capacidad de compilar directamente código C/C++ para Vulkan.

Aunque podría considerarse un competidor de GLSL y HLSL, la verdadera intención detrás de este proyecto va más allá, pues Vcc busca incorporar la familia de lenguajes C/C++ a Vulkan, presentando una serie de características en los sombreadores de Vulkan.

Vcc es simplemente una interfaz para Shady, un IR y un compilador diseñado para ampliar SPIR-V con soporte para las construcciones antes mencionadas. Shady se presenta como un IR relativamente convencional e incluye soporte para analizar LLVM IR. Maneja la reducción y emulación de todas las funciones adicionales que no se encuentran en las versiones actuales de SPIR-V 3 .

Por supuesto, hay una serie de características únicas que sólo se encuentran en los sombreadores. Estos se exponen en Vcc mediante intrínsecos y anotaciones, lo que permite escribir código que interactúe con las diversas características del canal Vulkan.

El proceso de compilación en Vcc implica la utilización de los componentes del proyecto LLVM y Clang como interfaz. Para su ejecución en la GPU, Vcc desarrolla su propia representación de sombreador intermedia «Shady», junto con un compilador dedicado para convertir el código a esta representación. Este enfoque permite la compilación de código C/C++ estándar y se complementa con funciones integradas específicas para aprovechar las capacidades de la GPU.

Vcc destaca por admitir funciones nativas de C/C++ para controlar el flujo del programa, incluso permitiendo el uso de la instrucción «goto». Asimismo, proporciona la capacidad de llamar funciones, ejecutar funciones de manera recursiva y utilizar diversos tipos de punteros, como punteros físicos, punteros etiquetados y punteros de función. Además, se facilita la realización de operaciones aritméticas en punteros y la determinación de diseños de tipos en la memoria.

La representación intermedia de sombreador Shady se basa en SPIR-V 3 y se expande para admitir construcciones especiales que son inherentes a las características de C/C++. La emulación se utiliza para implementar capacidades avanzadas que no son directamente aplicables a SPIR-V. Vcc incluye funciones y anotaciones integradas para permitir que los programas utilicen de manera eficiente las capacidades específicas de los sombreadores, proporcionando así un entorno versátil y potente para el desarrollo de aplicaciones GPU.

Finalmente, cabe mencionar que no todo es color de rosa y es esencial tener en cuenta algunas limitaciones de la implementación. Por ejemplo, Vcc no admite excepciones de C++, y la funcionalidad de malloc/free no está disponible. Además, existe una restricción en la portabilidad de funciones y punteros entre el sistema host y la GPU. Estas consideraciones son cruciales al planificar el desarrollo de aplicaciones que utilicen Vcc para garantizar una implementación eficaz y libre de problemas.

Si estás interesado en poder conocer más al respecto, puedes consular el sitio web y para los interesados en el código, deben saber que está disponible aquí.

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

LeftoverLocals, una vulnerabilidad en GPUS que permite el robo de datos 

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 poco, los investigadores de Trail of Bits (una firma de seguridad) dieron a conocer mediante una publicación de blog que detectaron un problema en las GPU de AMD, Apple, Qualcomm e Imagination, que hace posible que alguien obtenga datos de la memoria de la tarjeta gráfica, incluso si fueron creados por un programa diferente.

Bautizada como LeftoverLocals, esta vulnerabilidad afecta a las unidades de procesamiento de gráficos y con lo cual un atacante puede robar una cantidad significativa de datos.

Sobre LeftoverLocals

Catalogada ya bajo «CVE-2023-4969» y con una puntación de «8», hacen de LeftoverLocals, es una vulnerabilidad sumamente peligrosa, ya que permite la recuperación de datos de la memoria local de la GPU, que persisten después de que se haya ejecutado otro proceso y podrían contener información sensible.

Lo que hace de LeftoverLocals una vulnerabilidad peligrosa, es que afecta a una variedad de dispositivos ampliamente utilizados, muchos de los cuales seguían sin parchear y que puede ser explotada en entornos multiusuario, donde controladores para diferentes usuarios se ejecutan en la misma GPU, además de que podría ser explotada por malware para monitorear la actividad de los procesos que se ejecutan en la GPU, identificando datos procesados por el kernel de la GPU.

LeftoverLocals surge debido a un aislamiento insuficiente de la memoria local de la GPU y la incapacidad de limpiar dicha memoria después de la ejecución de procesos en la GPU. Esto permite que un proceso malicioso identifique datos residuales en la memoria local después de que otro proceso se ha ejecutado o lea datos de un proceso actualmente en ejecución.

Se menciona que, la esencia de LeftoverLocals radica en memoria local en una GPU que actúa como una caché para almacenar cálculos intermedios y puede variar en tamaño desde decenas de kilobytes hasta varios megabytes para cada unidad informática. El ataque implica ejecutar un controlador (kernel) en la GPU que copia periódicamente el contenido de la memoria local disponible en la memoria global (VRAM). Dado que la memoria local no se borra al cambiar entre procesadores en la GPU y se comparte entre diferentes procesos dentro de la misma unidad de cálculo de la GPU, puede contener datos residuales de otros procesos.

Con la finalidad de probar la vulnerabilidad, los investigadores de Trail of Bits han desarrollado algunos prototipos de exploits para diferentes GPU, utilizando las API OpenCL, Vulkan y Metal para acceder a la GPU. Aunque llevar a cabo un ataque desde un navegador a través de WebGPU es difícil debido a las comprobaciones dinámicas de límites de matriz agregadas por WebGPU, los investigadores han demostrado cómo la vulnerabilidad puede utilizarse para determinar datos de salida de otros usuarios y crear canales de comunicación ocultos entre diferentes procesos.

Ademas de ello, se menciona que la cantidad de datos filtrados depende del marco específico de la GPU y del tamaño de su memoria local. Por ejemplo, la relativamente grande AMD Radeon RX 7900 XT pierde alrededor de 5.5 MB o alrededor de 181 MB por cada consulta LLM, según los investigadores.

Dado que las GPU se utilizan cada vez más para acelerar las aplicaciones de inteligencia artificial y aprendizaje automático, los investigadores advirtieron que fallas como LeftoverLocals podrían convertirse en un objetivo importante.

«En general, la introducción del aprendizaje automático plantea nuevas superficies de ataque que los modelos de amenazas tradicionales no tienen en cuenta y que pueden conducir a un acceso implícito y explícito a datos, parámetros del modelo o resultados resultantes, aumentando la superficie de ataque general del sistema», señala el informe. escribieron los investigadores.

Trail of Bits señaló que se han implementado soluciones para esta vulnerabilidad en algunos dispositivos de Apple, y se espera una actualización de controladores de AMD en marzo, por su parte Qualcomm ha informado que ha solucionado el problema para la GPU Adreno a630 en la actualización de firmware 2.07, mientras que Imagination ha proporcionado una solución en el nuevo DDK 23.3 lanzado en diciembre.

Por otra parte, se menciona que no se ven afectadas las GPU de NVIDIA, Intel y ARM. En los controladores OpenCL de código abierto de Mesa para GPU AMD, la memoria se borra después de cada inicio del kernel, pero este método se considera ineficaz en algunos casos.

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/7UbRWYv
via IFTTT

Esta es, en mi opinión, la mejor manera de instalar aplicaciones web si usas un navegador basado en Chromium en Linux

Aplicaciones web gracias a Bash

Hace unos días publicamos un artículo en el que comparábamos tres maneras diferentes de usar aplicaciones web. Por un lado, desde el navegador tal cual; por otro, instalando la aplicación y usándola en una ventana separada; y por último haciendo uso de Webapp Manager, lo que creo que es lo mejor con diferencia. Hoy os traigo una opción diferente, una que se basa en parte en la XApp de Linux Mint.

Las aplicaciones instaladas desde el navegador pesan un poco más que lo que crea Webapps Manager. Tienen una ventaja, y es que se puede acceder a las extensiones fácilmente y funcionan todas, como por ejemplo un ecualizador que yo no he hecho funcionar -tampoco he buscado mucho- en las aplicaciones 100% separadas. Pero, por lo general, lo que crea Webapps Manager está a un nivel superior. Lo que pasa es que, por lo menos para los navegadores basados en Chromium más populares, lo único que hace es crear un archivo .desktop con una orden que le dice al navegador que lance una aplicación en un perfil aislado. Conseguir eso es lo que vamos a explicar hoy aquí.

Aplicaciones web en perfil aislado y sin instalar nada

Lo malo de la aplicación de Linux Mint, por ponerle algún pero, es que instala el software principal y algunos módulos de Python extra. Es peccata minuta para el que usa muchas aplicaciones web y además quiere elegir el navegador base, pero si nos es suficiente con Chrome, Brave, Vivaldi o Edge, todo lo que instalemos está de más.

Como decíamos, el secreto está en examinar qué hacen esas aplicaciones, analizar el archivo .desktop y crear uno parecido. Esto, que se puede hacer manualmente a partir del primer archivo que nos crea Webapp Manager, copiando y editando lo necesario, podemos automatizarlo usando Bash. El código sería el siguiente:

#!/bin/bash
echo "SSBash

¿Qué quieres hacer?
1. Crear aplicación web
2. Eliminar app existente
3. Salir"
read opcion
if [ "$opcion" == "1" ]; then
    echo "Nombre de la aplicación:"
    read nombre_app
    id_app=$(echo "$nombre_app" | tr -d ' ')
    echo "Comentario:"
    read comentario
    echo "Categoría":
    read categoria
    echo "URL de la aplicación web (sin https/http):"
    read url
    echo "Ruta al icono de la app":
    read icono
    echo "Navegador:
     1. Chrome
     2. Chromium
     3. Brave
     4. Edge
     5. Vivaldi
     6. Chrome (flatpak)
     7. Chromium (flatpak)
     8. Brave (flatpak)
     9. Edge (flatpak)
    10. Vivaldi (flatpak)
    11. ungoogled-chromium (flatpak)"
    read navegador_elegido

    case $navegador_elegido in
        1) navegador="Chrome" && ejecutable="google-chrome-stable --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        2) navegador="Chromium" && ejecutable="chromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        3) navegador="Brave" && ejecutable="brave --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        4) navegador="Edge" && ejecutable="microsoft-edge --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        5) navegador="Vivaldi" && ejecutable="vivaldi-stable --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        6) navegador="Chrome-flatpak" && ejecutable="flatpak run com.google.Chrome --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        7) navegador="Chromium-flatpak" && ejecutable="flatpak run org.chromium.Chromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        8) navegador="Brave-flatpak" && ejecutable="flatpak run com.brave.Browser --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        9) navegador="Edge-flatpak" && ejecutable="flatpak run com.microsoft.Edge --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        10) navegador="Vivaldi-flatpak" && ejecutable="flatpak run com.vivaldi.Vivaldi --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        11) navegador="ungoogled-chromium-flatpak" && ejecutable="flatpak run com.github.Eloston.UngoogledChromium --app="https://$url" --class=WebApp-$id_app --name=WebApp-$id_app --user-data-dir=$HOME/.config/SSBash/$navegador-'$id_app'";;
        *) echo "Opción no válida. Seleccionando Chrome por defecto." && navegador="Chrome";;
    esac

    cadena_aleatoria=$(head /dev/urandom | tr -dc a-z0-9 | head -c 30 ; echo '')
    acceso_directo=$navegador-$id_app-$cadena_aleatoria.desktop
    touch $acceso_directo
    mkdir -p "$HOME/.config/SSBash/$navegador-$id_app/img/"
    cp $icono "$HOME/.config/SSBash/$navegador-$id_app/img/"
    nombre_imagen=$(basename "$icono")
    echo "[Desktop Entry]
    Version=1.0
    Name=$nombre_app
    Comment=$comentario
    Exec=$ejecutable
    Icon=$HOME/.config/SSBash/$navegador-$id_app/img/$nombre_imagen
    Terminal=false
    Type=Application
    Categories=$categoria
    StartupNotify=true
    StartupWMClass=WebApp-$id_app" >> "$acceso_directo"

    chmod +x $acceso_directo
    mv $acceso_directo ~/.local/share/applications/

    echo "
    La aplicación '$nombre_app' debería haberse instalado.  Por favor,
    comprueba el archivo desktop en ~/.local/share/applications/
    y, tras ejecutarlo, que existe el perfil en ~/.config/SSBash/."
elif [ "$opcion" == "2" ]; then
    if [ -n "$(ls -A "$HOME/.config/SSBash/")" ]; then
        echo "¿Qué aplicación web quieres eliminar?" && ls $HOME/.config/SSBash/
        read app_eliminar
        if [ -n "$app_eliminar" ] && [ -e "$HOME/.config/SSBash/$app_eliminar" ]; then
            desktop_eliminar=$(echo "$app_eliminar" | tr -d ' ')
            rm -rf $HOME/.config/SSBash/"$app_eliminar"/
            rm $HOME/.local/share/applications/$desktop_eliminar*
            echo "La aplicación con id '$app_eliminar' ha sido eliminada."
        else
            echo "La apliación con id '$app_eliminar' no está en la lista."
        fi
    else
        echo "No hay aplicaciones web instaladas."
    fi
elif [ "$opcion" == "3" ]; then
    echo "Hasta la próxima."
else
    echo "Opción no válida".
fi

Explicando el código

El script o programa son menos de 100 líneas, y en él incluso se pueden eliminar las aplicaciones creadas. Es un poco rudimentario, pero hace lo que queremos. Se ejecuta con «bash nombre-del-archivo» -en donde hayamos pegado el código anterior- y todo pasa en el terminal. Se pueden editar las líneas de los navegadores y añadir otros basados en Chromium.

Empieza mostrando un nombre, y cada uno puede poner lo que más le guste. Como este tipo de aplicaciones son SSB por Site-Specific Browser y lo usado es Bash, pues SSBash no suena mal. Luego nos consulta si queremos crear una aplicación web o eliminar alguna de las que ya tenemos. Si le decimos que queremos crearla, nos pedirá el nombre de la aplicación, un comentario para los paneles que los soporten, a qué categoría pertenece, la URL del servicio, ruta al icono y luego un navegador web.

Creando una webapp con SSBash

Lo única diferencia que hay entre navegadores es el comando que los lanza, pero las banderas son iguales en todos los casos: crea una aplicación con su clase y un perfil aislado; luego creará el archivo .desktop con una cadena de caracteres aleatoria para evitar coincidencias, lo que se considera una buena práctica; a continuación crea una carpeta para la imagen que será el icono, rellena el archivo .desktop con todo lo necesario, le da permiso de ejecución y lo mueve a la carpeta `~/.local/share/applications/, que es en donde suelen estar los accesos directos propios y de algún otro software como las AppImage. Al lanzar la aplicación por primera vez se completará la creación del perfil.

Algunas precauciones

Si elegimos la opción de eliminar, el software consulta lo que hay en la carpeta de configuración, nos lo muestra y, tras poner exactamente una de las opciones, eliminará el .desktop y la carpeta con el perfil aislado. Está comprobado que funciona, pero ni yo ni LXA nos responsabilizamos de las posibles pérdidas de datos -más que nada accesos directos- que puedan tener lugar. Si alguien no quiere correr ningún riesgo, se pueden eliminar borrando el archivo .desktop de ~/.local/share/applications/ y el perfil de ~/.config/SSBash/nombre-de-la-app. Otra opción es hacer una copia de seguridad del contenido de ~/.local/share/applications/ antes de eliminar una app, comprobar que funciona y luego ya usarlo como se diseñó.

Como decía, es un poco rudimentario y no se gestionan los posibles errores. En ocasiones, dependiendo de la imagen o donde está, es probable que se vea algún fallo, en cuyo caso recomiendo revisar qué hay en el archivo .desktop.

Dos datos que me parece que hay que saber: Opera no está soportado, pero se pueden añadir otros basados en Chromium y probar; y, para que esto sea lo más simple posible, los iconos no los descarga ni nada, hay que buscarlos, descargarlos e indicar la ruta a ellos. Tampoco incluye una opción para instalar aplicaciones como lo hace el navegador… porque eso ya lo hace el navegador.

¿Y las extensiones?

Es posible instalar extensiones en este tipo de aplicaciones web, pero algunas no funcionarán. Por ejemplo, esas del ecualizador que actúan sólo en las pestañas en donde los activamos. Sí funcionarán las extensiones que funcionen en todo el navegador.

Para instalarlas, lo que hay que hacer es abrir una ventana nueva del navegador, lo que se puede conseguir con Ctrl-T o haciendo clic secundario sobre cualquier enlace y abriendo en una pestaña nueva. Se abrirá el navegador en cuestión, y esto permitirá ir a la Chrome Web Store e instalar cualquier extensión. Una vez instaladas podemos cerrar esos navegadores «completos» y volver a usar la aplicación web con la extensión incluída.

Otra manera de tener aplicaciones web

Esta es otra manera de tener aplicaciones web. Y al ejecutarse en un perfil aislado, no se comparte ni historial ni extensiones ni nada, e incluso podemos forzar el cierre del navegador base y no pasa nada. Si alguien prefiere que las aplicaciones sean de Firefox, entonces es mejor usar Webapp Manager.

Lo único a tener en cuenta es que cada perfil/app ocupa un espacio y suele superar los 100mb. Por todo lo demás, creo que merece la pena.

.barra {display: flex;justify-content: flex-end;height: 25px; background-color: #333;border-radius: 5px 5px 0 0;}.rojo, .naranja, .verde{width: 12px;height: 12px; position: relative;border-radius: 50%;top: 7px; margin: 0 3px;}.rojo{background-color: rgb(248, 82, 82); margin-right: 7px;}.naranja{background-color: rgb(252, 186, 63);}.verde{background-color: rgb(17, 187, 17);}.terminal{background-color: black !important;color: white !important;border-radius: 5px !important;}pre{font-family:monospace !important; padding: 0 10px 10px; line-height: 1.5em; overflow: auto; background-color: black !important; color: #0ee80e !important}

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

¿Por qué chromeOS Flex no soporta aplicaciones de Android?

chromeOS Flex

Hace ya casi dos años desde que Google puso a disponibilidad de cualquiera que quisiera probarlo chromeOS Flex. Es como chromeOS, pero para otros ordenadores. Más o menos. O más menos que más. No soporta aplicaciones de Android, entre otras cosas, y hay gente que se pregunta por qué, y que si no sería mejor para la compañía incluirlo en la versión Flex.

La respuesta puede ser más corta o más larga. La corta es que hacen lo mismo que Apple: prefieren que el que quiera usar chromeOS tal y como se diseñó lo haga en un Chromebook, dispositivos que venden ellos. Entonces, ¿qué sentido tiene chromeOS Flex? Lo tiene, y es el mismo que el de los servicios de Google: obtener información de uso.

chromeOS Flex es una opción para dispositivos antiguos

La combinación perfecta para Google es cuando alguien les compra un Chromebook y le deja chromeOS instalado. De esta manera ganan un poco de dinero con la venta del aparato y mucho más con la información que reciben del uso que hacemos de ellos.

La otra opción que no quieren dejar pasar es la de la información. Vale, no les compramos un aparato a ellos ni a un fabricante que les aporta algún beneficio, pero no nos permite disfrutar de la experiencia completa de chromeOS. Entre lo que ofrece, el sistema operativo basado en aplicaciones y herramientas web, soporte para ejecutar aplicaciones de Linux (por lo general, Debian) y soporte para aplicaciones de Android. Si queremos resucitar un equipo antiguo sólo obtendremos al experiencia web, y ellos «sólo» recibirán datos de uso.

Quizá sea mejor una distribución ligera…

Digo que quizá lo sea por no afirmarlo con rotundidad. chromeOS no es que sea muy pesado, pero en comparación hay distribuciones ligeras que están mejor. Sería muy diferente si permitieran usar aplicaciones de Android, pero no es el caso en la versión Flex. Por lo tanto, si lo que vamos a obtener instalando chromeOS Flex es un sistema operativo con herramientas web y sin poder instalar programas de Linux ni apps de Android, creo que la decisión está clara.

Que uno quiera más o menos de Google es otra cuestión.

También es un tema aparte eso de coger chromeOS Flex y activarle el soporte que Google capa por defecto, pero eso es algo que probablemente hagamos en otro artículo (si comprobamos que es fácil y merece la pena).

A la cuestión que nos traía hoy por aquí, pues eso, Google no quiere ofrecer la experiencia completa si no puede llevarse el combo completo. ¿Tiene sentido? Probablemente, o de lo contrario lo harían de otra manera. ¿Para qué iba uno a comprar un Chromebook si puede instalar su sistema en cualquier otro aparato?

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

Nitrux 3.2.1 «se» ya fue liberada y estas son sus novedades

Nitrux

Nitrux continua con la migración hacia Maui Shell

Los desarrolladores de la distribución Linux «Nitrux» comenzaron el año lanzando una nueva versión estable del sistema, llegando este a su nueva versión «Nitrux 3.2.1» con nombre clave «se» que mencionan que hace referencia un «entorno más seguro», debido a la implementación en todo el sistema de la política de contraseñas utilizada en Calamares y otros cambios relacionados con la seguridad.

Para quienes desconocen de esta distribución, deben saber que está construida sobre la base del paquete Debian, las tecnologías KDE y el sistema de inicio OpenRC. Esta distribución se destaca por el desarrollo de su propio escritorio «NX», que es un complemento sobre el entorno KDE Plasma del usuario, además de que el proceso de instalación de aplicaciones está basado en el uso de paquetes AppImages.

Principales novedades de Nitrux 3.2.1 «se»

Esta nueva versión que se presenta de Nitrux 3.2.1 introduce varias mejoras significativas, incluyendo el kernel de Linux Liquorix 6.6.9-1 con mejoras en el soporte de hardware, controladores AMD Open Source para Vulkan® hasta la versión v-2023.Q4.2 y el entorno de escritorio KDE Plasma 5.27.10 LTS, KDE Frameworks 5.114 y KDE Gear 23.08.4. Estos componentes están construidos sobre el marco de aplicaciones Qt 5.15 LTS, que ofrece compatibilidad a largo plazo.

La instalación inicial del sistema ahora se beneficia de un instalador gráfico actualizado de Calamares. Entre las nuevas características se encuentra una casilla de verificación para deshabilitar la validación de seguridad de la contraseña predeterminada, así como una presentación de diapositivas renovada.

Por la parte de la paquetería del sistema, Nitrux 3.2.1 presenta diversas actualizaciones clave, entre las que se incluyen las versiones más recientes de Firefox 121, OpenRC 0.52.1 y AppArmor 4.0.0 alpha2. Además, se han implementado cambios significativos en el entorno de escritorio NX basado en KDE Plasma. Estas mejoras abarcan desde un efecto Cover Switch para cambiar de ventana hasta una nueva opción para reiniciar la sesión de KWin X11. También se han realizado ajustes para mejorar el inicio de sesión y ahorrar espacio en disco, se ha introducido una nueva sección de ayuda, se han actualizado temas, mejorado el escalado fraccional y se han añadido nuevas fuentes, fondos de escritorio, el lanzador de aplicaciones Plasma Drawer, así como las extensiones Plasma Gamemode y Active Blur.

Además de ello, también se destaca la integración de nuevos componentes, entre los que se incluyen el paquete rng-tools, el agente SPICE para Linux para acceso remoto a máquinas virtuales, pwgen para generación automática de contraseñas y un formulario PAM para comprobar el «fuerza” de la contraseña.

Nitrux 3.2.1 también presenta el módulo KCModule para tableta KDE Wacom, que implementa una GUI para los controladores Wacom Linux. Además, esta versión agrega nuevas fuentes del sistema (Switzer y CamingoCode) y un nuevo fondo predeterminado.

En cuanto a las mejoras de seguridad, se destaca que Nitrux 3.2.1 habilita el modo de aleatorización de direcciones MAC para redes en NetworkManager de forma predeterminada. Además, el estándar IPv6 Privacy Extensions (RFC 4941) se ha habilitado de forma predeterminada en NetworkManager y el kernel de Linux.

De los demás cambios que se destaca:

  • Se actualizaron los temas de KDE Plasma Nitrux, Nitrux Dark y Nitrux Mix para crear el diseño del escritorio correctamente utilizando Plasma Desktop Scripting (ECMA Script, también conocido como JavaScript).
  • Administrador de ventanas en mosaico (Tiling WM) llamado Polonium, que los usuarios pueden activar en la configuración.
  • Scripts de servicio para OpenRC para iniciar phodav y Avahi.
    Script de servicio para OpenRC para iniciar usbmuxd.
  • Se solucionaron los siguientes problemas:
    VirtualBox no puede iniciar ISO cuando usa EFI si fbx64.efi está presente en /EFI/BOOT
    La instalación falla en dispositivos Legacy BIOS
    Hay un problema de contraste con el esquema de color Nitrux Dark
    Algunas aplicaciones no se abren al hacer clic en el ícono del menú de aplicaciones
    Los plasmoides NX se congelan o bloquean el plasmashell cuando se agregan a un panel de plasma en la sesión de Wayland usando el hardware NVIDIA
    Algunos íconos están rotos

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

Descargar la nueva versión de Nitrux 3.2.1

Si quieren descargar esta nueva versión de Nitrux 3.2.1 deberán de dirigirse a la página web oficial del proyecto en donde podrán obtener el enlace de descarga de la imagen del sistema y la cual podrán grabar en un USB con ayuda de Etcher. Nitrux está disponible para su descarga inmediata desde el siguiente enlace. 

Para aquellos que ya se encuentran sobre una versión anterior de la distribución, pueden hacer la actualización a la nueva versión, tecleando los siguientes comandos:

sudo apt update

sudo apt install --only-upgrade nitrux-repositories-config amdgpu-firmware-extra

sudo apt install -o Dpkg::Options::="--force-overwrite" linux-firmware/trixie

sudo apt dist-upgrade

sudo apt autoremove

sudo reboot

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