AOSP inicia con los trabajos del soporte inicial para RISC-V en Android 

RISC-V android

El soporte RISC-V en Android abre un nuevo panorama de posibilidades

Hace poco, mediante una publicación de blog RISC-V anuncio que en el repositorio AOSP (Android Open Source Project) que desarrolla el código fuente de la plataforma Android, ha comenzado a incluir cambios para soportar dispositivos con procesadores basados ​​en la arquitectura RISC-V.

El conjunto de parches de soporte de RISC-V fue preparado por Alibaba Cloud e incluye 76 parches que cubren varios subsistemas.

Dentro de los trabajos realizados se incluye la pila de gráficos, el sistema de sonido, los componentes de reproducción de video, la biblioteca biónica, la máquina virtual dalvik, los marcos, las pilas Wi-Fi y Bluetooth, las herramientas para desarrolladores y varios módulos de terceros, incluidos modelos para TensorFlow Lite y módulos de aprendizaje automático para reconocimiento de texto, clasificación de sonido e imagen.

Del conjunto total de parches, 30 parches relacionados con el entorno del sistema y las bibliotecas ya se han integrado en AOSP. Durante los próximos meses, Alibaba Cloud tiene la intención de lanzar parches adicionales para AOSP para habilitar la compatibilidad con RISC-V en el kernel, Android Runtime (ART) y el emulador.

“¡Nos complace ver más apoyo de Google para crear AOSP dirigido a RISC-V! Alibaba Cloud se ha comprometido a apoyar a la comunidad RISC-V a través de una serie de innovaciones, como el avance de la migración de funciones básicas de Android a RISC-V, lo que demuestra la viabilidad de usar dispositivos basados ​​en RISC-V en escenarios que van desde multimedia hasta señal procesamiento, interconexión de dispositivos e inteligencia artificial. Esperamos colaborar con el equipo de Android para contribuir a la próspera comunidad RISC-V en el futuro”, dijo el Dr. David Chen, Director de Ecosistema de Alibaba Cloud y Vicepresidente del Comité Horizontal de Aplicaciones y Herramientas de RISC-V International. .

“RISC-V ha crecido en popularidad a través de la gran demanda de flexibilidad y opciones en todo el espectro de la informática, desde los dispositivos integrados más pequeños hasta las implementaciones de nube de escalamiento horizontal más grandes”, dijo Calista Redmond, CEO de RISC-V International. “Esta demanda ha hecho que RISC-V sea inevitable como el estándar abierto ISA más prolífico de nuestro tiempo, acelerando la innovación y la adopción con el ecosistema más fuerte de partes interesadas globales”.

Para admitir la compatibilidad con RISC-V en Android, RISC-V International ha creado un SIG de Android dedicado al que pueden unirse otras empresas interesadas en ejecutar la pila de software de Android en procesadores RISC-V. El traslado de la compatibilidad con RISC-V a la corriente principal de Android se está realizando en colaboración con Google y la comunidad.

Los cambios propuestos para Android forman parte de una iniciativa para ampliar el alcance de los dispositivos basados ​​en la arquitectura RISC-V.

En 2020, ingenieros y desarrolladores de software del laboratorio PLCT de la Academia de Ciencias de China comenzaron a migrar Android 10 a la arquitectura RISC-V en un esfuerzo por abrir este importante ecosistema a la comunidad RISC-V. Desde los primeros días del esfuerzo, la división Alibaba Cloud ha sido una estrecha colaboradora y líder en este trabajo pionero y ha mantenido el desarrollo actualizado con versiones más nuevas de Android.

El año pasado, Alibaba abrió los desarrollos relacionados con los procesadores XuanTie RISC-V y comenzó a promover activamente RISC-V no solo para dispositivos IoT y sistemas de servidores, sino también para dispositivos de consumo y varios chips especializados, cubriendo diversas aplicaciones desde sistemas multimedia hasta señales de procesamiento y aceleradores para el aprendizaje automático.

Para quienes desconocen de RISC-V, deben saber que este proporciona un sistema abierto y flexible de instrucciones de máquina que le permite crear microprocesadores para aplicaciones arbitrarias, sin requerir regalías y sin imponer condiciones de uso. RISC-V permite la creación de SoC y procesadores completamente abiertos.

Para los interesados, deben saber que actualmente, en base a la especificación RISC-V, diversas empresas y comunidades bajo diversas licencias libres (BSD, MIT, Apache 2.0) están desarrollando varias decenas de variantes de núcleos de microprocesadores, alrededor de un centenar de SoC y chips ya fabricados. La compatibilidad con RISC-V ha estado presente desde los lanzamientos de Glibc 2.27, binutils 2.30, gcc 7 y Linux kernel 4.15.

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

Sigstore, el sistema de verificación criptográfica ya es estable

Sigstore

Sigstore se puede considerar como un Let’s Encrypt para código, que proporciona certificados para firmar código digitalmente y herramientas para automatizar la verificación.

Google dio a conocer mediante una publicación de blog, el anunció de la formación de las primeras versiones estables de los componentes que forman el proyecto Sigstore, que se declara adecuado para crear implementaciones de trabajo.

Para quienes desconocen de Sigstore, deben saber que este es un proyecto que tiene la finalidad de desarrollar y proporcionar herramientas y servicios para la verificación de software utilizando firmas digitales y manteniendo un registro público que confirma la autenticidad de los cambios (registro de transparencia).

Con Sigstore, los desarrolladores pueden firmar digitalmente artefactos relacionados con aplicaciones, como archivos de lanzamiento, imágenes de contenedores, manifiestos y ejecutables. El material utilizado para la firma se refleja en un registro público a prueba de manipulaciones que se puede utilizar para la verificación y auditoría.

En lugar de claves permanentes, Sigstore utiliza claves efímeras de corta duración que se generan en base a las credenciales verificadas por los proveedores de OpenID Connect (en el momento de generar las claves necesarias para crear una firma digital, el desarrollador se identifica a través del proveedor de OpenID con enlace de correo electrónico).

La autenticidad de las claves se verifica mediante un registro público centralizado, que le permite asegurarse de que el autor de la firma es exactamente quien dice ser, y que la firma fue formada por el mismo participante que fue responsable de versiones anteriores.

La preparación de Sigstore para la implementación se debe a la formación de versiones de dos componentes clave: Rekor 1.0 y Fulcio 1.0, cuyas interfaces de programación se declaran estables y, en adelante, conservan la compatibilidad con versiones anteriores. Los componentes del servicio están escritos en Go y se distribuyen bajo la licencia Apache 2.0.

El componente Rekor contiene una implementación de registro para almacenar metadatos firmados digitalmente que reflejan información sobre proyectos. Para garantizar la integridad y la protección contra la corrupción de datos, se utiliza una estructura de árbol Merkle Tree en la que cada rama verifica todas las ramas y nodos subyacentes a través de hash conjunto (árbol). Al tener un hash final, el usuario puede verificar la exactitud de todo el historial de operaciones, así como la exactitud de los estados pasados ​​de la base de datos (el hash de verificación raíz del nuevo estado de la base de datos se calcula teniendo en cuenta el estado pasado). Se proporciona una API RESTful para verificar y agregar nuevos registros, así como una interfaz de línea de comandos.

El componente Fulcio (SigStore WebPKI) incluye un sistema para crear autoridades de certificación (CA root) que emiten certificados de corta duración basados ​​en correo electrónico autenticado a través de OpenID Connect. La vida útil del certificado es de 20 minutos, durante los cuales el desarrollador debe tener tiempo para generar una firma digital (si en el futuro el certificado cae en manos de un atacante, ya estará caducado). Además, el proyecto desarrolla el kit de herramientas Cosign (Container Signing), diseñado para generar firmas para contenedores, verificar firmas y colocar contenedores firmados en repositorios compatibles con OCI (Open Container Initiative).

La introducción de Sigstore permite aumentar la seguridad de los canales de distribución de software y proteger contra ataques dirigidos a la sustitución de bibliotecas y dependencias (cadena de suministro). Uno de los problemas de seguridad clave en el software de código abierto es la dificultad de verificar la fuente del programa y verificar el proceso de compilación.

El uso de firmas digitales para la verificación de versiones aún no se ha generalizado debido a las dificultades en la gestión de claves, la distribución de claves públicas y la revocación de claves comprometidas. Para que la verificación tenga sentido, también se requiere organizar un proceso confiable y seguro de distribución de claves públicas y sumas de verificación. Incluso con una firma digital, muchos usuarios ignoran la verificación porque lleva tiempo aprender el proceso de verificación y comprender qué clave es confiable.

El proyecto se está desarrollando bajo el auspicio de la organización sin fines de lucro Linux Foundation de Google, Red Hat, Cisco, vmWare, GitHub y HP Enterprise con la participación de OpenSSF (Open Source Security Foundation) y la Universidad de Purdue.

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/28TZGM0
via IFTTT

Proponen modernizar el proceso de arranque de Linux

Trusted Boot

El nuevo arranque Linux funcionará en el futuro con un enfoque en la robustez y la simplicidad.

Lennart Poettering (el creador de Systemd) dio a conocer hace poco una propuesta para modernizar el proceso de arranque de las distribuciones de Linux, con el objetivo de resolver los problemas existentes y simplificar la organización de un arranque verificado completo, confirmando la autenticidad del kernel y el entorno del sistema subyacente.

Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image) que combina la imagen del kernel de Linux, el controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en memoria, utilizado para inicialización inicial en la etapa antes de montar el FS.

En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en el UKI, lo que permite la creación de entornos de sistema totalmente verificados que se cargan en la RAM. La imagen UKI se empaqueta como un archivo ejecutable en formato PE, que no solo se puede cargar con los cargadores de arranque tradicionales, sino que también se puede llamar directamente desde el firmware UEFI.

La capacidad de llamar desde UEFI permite usar una verificación de validez e integridad de firma digital que cubre no solo el kernel, sino también el contenido del initrd. Al mismo tiempo, la compatibilidad con las llamadas desde los cargadores de arranque tradicionales permite guardar funciones como la entrega de varias versiones del kernel y la reversión automática a un kernel en funcionamiento en caso de que se detecten problemas con el nuevo kernel después de instalar la actualización.

Actualmente, la mayoría de las distribuciones de Linux utilizan la cadena «firmware → capa shim de Microsoft firmada digitalmente → cargador de arranque GRUB de distribución firmado digitalmente → kernel de Linux de distribución firmado digitalmente → entorno initrd sin firmar → FS root» en el proceso de inicialización. La falta de verificación initrd en las distribuciones tradicionales crea problemas de seguridad, ya que, entre otras cosas, este entorno extrae claves para descifrar el FS root.

No se admite la verificación de la imagen initrd, ya que este archivo se genera en el sistema local del usuario y no puede ser certificado por la firma digital de la distribución, lo que complica mucho la organización de la verificación cuando se utiliza el modo SecureBoot (para verificar el initrd, el usuario necesita para generar sus claves y cargarlas en el firmware UEFI).

Además, la organización de arranque existente no permite usar información de los registros TPM PCR (Registro de configuración de plataforma) para controlar la integridad de los componentes del espacio de usuario que no sean shim, grub y kernel. Entre los problemas existentes, también se menciona la complicación de actualizar el gestor de arranque y la imposibilidad de restringir el acceso a claves en TPM para versiones anteriores del sistema operativo que se han vuelto irrelevantes después de instalar la actualización.

Los principales objetivos de implementar la nueva arquitectura de arranque:

  • Proporcionar un proceso de descarga completamente verificado, que cubra todas las etapas, desde el firmware hasta el espacio del usuario, y que confirme la validez e integridad de los componentes descargados.
  • Vinculación de recursos controlados a registros TPM PCR con separación por propietarios.
  • Capacidad para precalcular los valores de PCR en función del arranque del kernel, initrd, configuración e ID del sistema local.
  • Protección contra ataques de reversión asociados con la reversión a la versión vulnerable anterior del sistema.
  • Simplifique y mejore la confiabilidad de las actualizaciones.
  • Compatibilidad con actualizaciones del sistema operativo que no requieren volver a aplicar o aprovisionar recursos protegidos por TPM localmente.
  • Preparación del sistema para la certificación remota para confirmar la corrección del sistema operativo y la configuración de arranque.
  • La capacidad de adjuntar datos confidenciales a ciertas etapas de arranque, por ejemplo, extrayendo claves de cifrado para el FS root del TPM.
  • Proporcione un proceso seguro, automático y silencioso para desbloquear claves para descifrar una unidad con una partición root.
  • El uso de chips que admiten la especificación TPM 2.0, con la capacidad de recurrir a sistemas sin TPM.

Los cambios necesarios para implementar la nueva arquitectura ya están incluidos en el código base de systemd y afectan a componentes como systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase y systemd-creds.

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

Chrome 107 llega con ECH, cambio en la interfaz de descargas y diciendo adios a Android 6

chrome

El navegador Chrome se diferencia de Chromium en el uso de los logotipos de Google

Google dio a conocer el lanzamiento de la nueva versión de su navegador web «Google Chrome 107» junto con el cual tambien está disponible una versión estable del proyecto gratuito Chromium, que es la base de Chrome.

Además de las innovaciones y la corrección de errores, se han corregido 14 vulnerabilidades en la nueva versión de las cuales no se han identificado problemas críticos que permitan eludir todos los niveles de protección del navegador y ejecutar código en el sistema fuera del entorno sandbox. Como parte del programa de recompensas por vulnerabilidades de la versión actual, Google pagó 10 premios por valor de 57 000 USD.

Principales novedades de Chrome 107

En esta nueva versión de Chrome 107 podremos encontrar el soporte para el mecanismo ECH que continúa el desarrollo de ESNI (Indicación de nombre de servidor cifrado) y se utiliza para cifrar información sobre los parámetros de la sesión TLS, como el nombre de dominio solicitado. La diferencia clave entre ECH y ESNI es que en ECH, en lugar del cifrado a nivel de campos individuales, se cifra todo el mensaje TLS ClientHello, lo que le permite bloquear fugas a través de campos que no están cubiertos por ESNI, por ejemplo, el PSK. Para controlar si ECH está habilitado, se sugiere la configuración «chrome://flags#encrypted-client-hello».

Otra de las novedades que se destaca de la nueva versión de Chrome 107 es el cambio en el diseño de la interfaz para rastrear el estado de las descargas. En lugar de la línea inferior con datos sobre el progreso de la descarga, se ha agregado un nuevo indicador al panel con la barra de direcciones, al hacer clic, se muestra el progreso de la descarga de archivos y un historial con una lista de archivos ya descargados.

Para usuarios de escritorio, se proporciona la capacidad de importar contraseñas guardadas en un archivo en formato CSV. Anteriormente, las contraseñas de un archivo al navegador solo podían transferirse a través del servicio passwords.google.com, y ahora esto se puede hacer a través del administrador de contraseñas integrado en el navegador (Google Password Manager).

Tambien se destaca que se habilitó la retirada automática del permiso para mostrar notificaciones de sitios detectados enviando notificaciones y mensajes que interfieren con el usuario. Además, para dichos sitios, se suspenden las solicitudes para obtener permisos para enviar notificaciones.

Por otra parte, tambien se destaca la quinta etapa de recorte de información en el encabezado HTTP del agente de usuario y los parámetros de JavaScript navigator.userAgent, navigator.appVersion y navigator.platform se ha habilitado para reducir la información que se puede usar para identificar pasivamente a un usuario. En Chrome 107, la cadena de agente de usuario se ha reducido en la información de la plataforma y el procesador para los usuarios de escritorio, y el contenido del parámetro de JavaScript navigator.platform se ha congelado. El cambio solo se nota en las versiones para la plataforma Windows, donde la versión específica de la plataforma se cambia a «Windows NT 10.0». En Linux, el contenido de la plataforma en User-Agent no ha cambiado.

Anteriormente, los números MINOR.BUILD.PATCH que componían la versión del navegador se reemplazaron con 0.0.0. En el futuro, el encabezado contendrá solo información sobre el nombre del navegador, la versión principal del navegador, la plataforma y el tipo de dispositivo (teléfono móvil, PC, tableta).

De los demás cambios que se destacan de esta nueva version:

  • En Android se ofrece una nueva interfaz para seleccionar archivos multimedia para cargar fotos y videos (en lugar de su propia implementación, se utiliza la interfaz estándar de Android Media Picker).
  • El soporte para Android 6.0 ya no es compatible y ahora requiere al menos Android 7.0.
  • CSS Grid agrega soporte para interpolar las propiedades grid-template-columns y grid-template-rows para proporcionar una transición suave entre los diferentes estados de la cuadrícula.
  • Se han realizado mejoras en las herramientas para desarrolladores web.
  • Se agregó la capacidad de personalizar las teclas de acceso rápido. Inspección de memoria mejorada de objetos de aplicación C/C++ convertidos al formato WebAssembly.
    Compatibilidad habilitada para la decodificación de video acelerada por hardware en formato H.265 (HEVC).

¿Como instalar Google Chrome 107 en Linux?

Si estás interesado en poder instalar esta nueva versión de este navegador web y aún no lo tienes instalado, puedes visitar la siguiente publicación en donde te enseñamos a como poder instalarlo en algunas distribuciones de Linux.

El enlace es este. 

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