Logo del proyecto SEF

Hace ya algunos días la Fundación Linux dio a conocer el primer lanzamiento de una plataforma abierta destinada al almacenamiento Flash impulsado por software, denominada SEF (Software Enabled Flash). El SDK asociado es una contribución generosa por parte de KIOXIA, una empresa de almacenamiento que se separó de Toshiba hace varios años.

Se destaca que el proyecto Software-Enabled Flash marca un hito transformador para los desarrolladores que buscan un acceso excepcional al potencial creativo de las aplicaciones de almacenamiento flash.

Sobre Software-Enabled Flash

Software-Enabled Flash está constituido por un conjunto de herramientas que comprende una serie de parches para el kernel de Linux, un controlador de bloque diseñado para dispositivos SEF (Software Enabled Flash), utilidades destinadas a la administración mediante línea de comandos, controladores SEF paravirtualizados para QEMU, una biblioteca que proporciona una API para el desarrollo de aplicaciones, parches para nvme-cli y FIO que incorporan soporte para SEF.

El hardware donado incluye el SDK del proyecto SEF, que ofrece a los desarrolladores de almacenamiento de centros de datos acceso a código de muestra y la capacidad de aprovechar todo el potencial del control de medios flash. Esto abarca reducción de WAF, control de latencia, soporte para múltiples protocolos como ZNS y FDP, o Block, y promete capacidades futuras a través de este enfoque de flash dinámico y programable definido por software.

Además, el SDK cuenta con una implementación de referencia de la capa de software FTL (Flash Translation Layer), encargada de traducir los comandos de dispositivos de bloque en accesos al chip de memoria Flash real. Esta capa se encarga también de la recolección de basura y la distribución de datos entre las celdas de memoria. La FTL implementa soporte para la ubicación flexible de datos (FDP – Flexible Data Placement), la zonificación (ZNS – Zoned Namespace) y cumple con la especificación NVMe.

Se menciona que en el caso del almacenamiento Flash convencional para sistemas externos, la unidad se percibe como una caja negra donde una porción de la memoria se destina a operaciones de limpieza, mientras que los indicadores de rendimiento tienden a ser inconsistentes, y se experimentan retrasos impredecibles debido a la actividad del controlador interno, como durante la recolección de basura.

«Estamos muy contentos de alcanzar este hito y lanzar el kit de desarrollo de software para el proyecto Software-Enabled Flash», dijo Eric Ries, vicepresidente senior de la División de Estrategia de Memoria y Almacenamiento de KIOXIA America, Inc. «Este lanzamiento ahora abre el camino hacia usos nuevos e innovadores de flash para aplicaciones de almacenamiento que aprovechan la creatividad y la inventiva de los usuarios, desarrolladores y las comunidades de código abierto».

A diferencia de las unidades flash convencionales, donde la distribución de datos, el aislamiento de bloques defectuosos y la recolección de basura son manejados por el firmware del controlador interno, las unidades con soporte SEF permiten transferir la lógica del trabajo de bajo nivel con el chip de memoria Flash al software y al sistema operativo.

SEF posibilita el control directo de la ubicación física de los datos, la modificación de algoritmos de distribución de carga, la gestión de prioridades y la calidad de servicio (QoS), la eliminación de una capa adicional de traducción de bloques, la utilización completa de la memoria disponible, el logro de un funcionamiento predecible de la unidad y la división de la unidad en dispositivos virtuales aislados en las operaciones de entrada/salida (E/S) con diferentes prioridades de procesamiento. El enfoque propuesto por SEF contribuye a la reducción de costos generales y al aumento de la eficiencia en la interacción con la unidad, adaptando la lógica de recolección de basura, la reserva de memoria y la asignación de bloques para satisfacer las necesidades actuales.

Por ejemplo, SEF permite normalizar el rendimiento al utilizar una variedad de unidades adquiridas en diferentes momentos con características distintas. En el caso de unidades que son principalmente de solo lectura, SEF puede emplear algoritmos de asignación de bloques más simples y reducir la cantidad de memoria reservada para propósitos generales.

Finalmente cabe mencionar que el SDK de SEF está escrito en C y es distribuido bajo la licencia BSD junto con la API y las especificaciones de comando. Puedes consultar el código de SEF en GitHub.

Fuente: https://www.linuxfoundation.org

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

Hace ahora algo más de tres años escribimos un artículo sobre los mejores bots de Telegram. Estos «robots» que viven en la única app de mensajería que le hace sombra a WhatsApp, o eso pretenden, pueden ayudarnos a mucho, como por ejemplo, enterarnos de cuándo van a empezar unos entrenamientos o carrera de F1 o descargar vídeos de YouTube. Las posibilidades son tantas que alguno puede pensar en crearse una especie de «super app» dentro de Telegram, pero hay que tomar medidas para evitar algunas molestias.

Los bots de Telegram son software, y como cualquier programa, su creación puede requerir más o menos tiempo. Si no se consigue dejarlo en la nube, hay que tener un equipo local para que el bot pueda estar funcionando. Lo que hace la comunidad Linux y de código abierto en general no es lo más normal, y muchos desarrolladores quieren conseguir dinero, mucho y pronto. Lógico. Lo malo es cuando se elige la vía del spam para conseguirlo.

Útiles siempre, molestos a veces

Yo, que en su día probé muchos, ya sólo mantengo unos pocos bots y prácticamente no les doy uso. Dos de ellos son para stickers, uno para el propio Telegram y otro para pasarlos a WhatsApp. También mantengo ese de las notificaciones de F1 porque la app oficial me parece demasiado y el bot es perfecto, pero poco más. El motivo, además del spam, es que, si hay aplicación, la app suele ser mejor.

El tema de los mensajes de spam no es tan grave como el de los años dorados del correo basura, pero existe. Los desarrolladores pueden enviar, manual o automáticamente, un mensaje promocional que poco o nada tiene que ver con el bot en sí, y eso es molesto: salta una notificación, te llama la atención, la abres y lo que ves es publicidad, y puede que en un idioma que no entiendas. No es la publicidad que hay en un borde de la pantalla en algunas apps móviles; esta te notifica y todo aprovechando que viven en una aplicación de mensajería.

Cómo evitar mensajes de spam de los bots de Telegram

Pero hay una manera de evitarlo: si un bot no nos interesa por el motivo que sea, tenemos que eliminar la conversación y elegir la opción de bloquear también al bot. En un principio uno puede pensar que es un poco drástico bloquear a «alguien», pero esa función existe por un motivo, y ese motivo es justamente evitar el spam.

También se puede parar un bot sin eliminar la conversación, para lo que tendremos que entrar en la configuración de la misma. Supongamos que hay uno que sí nos interesa, como puede ser el que nos informa del estado de los envíos de nuestros pedidos on-line, pero su desarrollador -no sé si es el caso; es sólo un ejemplo- ha decidido enviar publicidad cada dos por tres y nos resulta molesto. No queremos dejar de usar el bot, pero tampoco sufrir las notificaciones. Entramos en la configuración de esa conversación y ejecutamos la opción de «Bloquear».

En la versión de escritorio, la opción es «Detener y bloquear el bot», mientras que en la del móvil es sólo bloquear. De esta manera tendremos la conversación a la vista y podremos reiniciar el bot sólo cuando nos interese. En el caso del ejemplo, cuando tengamos un envío pendiente lo activaríamos, y al recibir el paquete lo bloquearíamos.

Silenciar a los bots, la solución salomónica

A medio camino, algo que también apoyaría a los desarrolladores, tendríamos la opción de silenciar al bot. De hecho, la gran mayoría de veces puede estar en silencio y seguir haciendo su trabajo. Por ejemplo, si queremos que nos notifique cuándo van a hacer una carrera de F1 o en las novedades de nuestro envío, quizá sí sea necesario recibir las notificaciones, pero ¿para qué queremos tenerlas activas en un bot que lo que hace es transcribir voz a texto?

Tomemos la decisión que tomemos, es bueno educarse con los bots de Telegram como nos educamos en su día con los correos basura. Dónde pongamos el límite, si es que lo ponemos, es otra decisión que tenemos que tomar.

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

Log4Shell es uno de los que aparecerán en las filtraciones de datos durante la próxima década

Este último mes del año 2023 marco el segundo aniversario del descubrimiento de la vulnerabilidad Log4j/Log4Shell, la cual es una vulnerabilidad que al día de hoy continua afectado a muchos proyectos y supone un riesgo de seguridad.

Y es que Log4j sigue siendo un blanco principal para los ciberataques, según el informe anual «Year in Review» de Cloudflare y también los resultados de un estudio sobre la relevancia de las vulnerabilidades críticas en la biblioteca Java Log4j que dieron a conocer investigadores de seguridad de Veracode.

Los investigadores de Veracode mencionan que después de estudiar 38.278 aplicaciones utilizadas por 3.866 organizaciones, descubrieron que dos de cada cinco aplicaciones aún utilizan versiones vulnerables de la biblioteca Apache Log4j, dos años después de que se hiciera pública una vulnerabilidad crítica.

El informe destaca que cerca de un tercio de las aplicaciones ejecutan Log4j2 1.2.x (que alcanzó el final de su vida útil en agosto de 2015 y ya no recibe actualizaciones de parches) lo que representa un 38%. La razón principal para continuar usando código heredado es la integración de bibliotecas antiguas en proyectos o la laboriosidad de migrar de ramas no compatibles a nuevas ramas que son compatibles con versiones anteriores. Además, un 2.8% de las aplicaciones aún utilizan versiones vulnerables a la conocida vulnerabilidad Log4Shell.

Además de ello, se menciona que existen tres categorías principales de aplicaciones que aún utilizan versiones vulnerables de Log4j, según el informe de Veracode:

1. Vulnerabilidad Log4Shell (CVE-2021-44228):
   El 2.8% de las aplicaciones persisten a seguir utilizando versiones de Log4j desde la 2.0-beta9 hasta la 2.15.0, las cuales contienen la vulnerabilidad conocida.
2. Vulnerabilidad de Ejecución Remota de Código (RCE) (CVE-2021-44832):
   Un 3.8% de las aplicaciones emplean la versión Log4j2 2.17.0, que aborda la vulnerabilidad Log4Shell, pero no resuelve la vulnerabilidad de ejecución remota de código (RCE) identificada como CVE-2021-44832.
3. Rama Log4j2 1.2.x (Soporte Finalizado en 2015):
   Un 32% de las aplicaciones aún utilizan la rama Log4j2 1.2.x, cuyo soporte finalizó en 2015. Esta rama se ha visto afectada por vulnerabilidades críticas, como CVE-2022-23307, CVE-2022-23305 y CVE-2022-23302, identificadas en 2022, siete años después de finalizado el mantenimiento.

Estos datos resaltan la diversidad de situaciones en las que las aplicaciones continúan utilizando versiones desactualizadas y vulnerables de Log4j, lo que genera una gran preocupación por parte de los investigadores.

Y es que un dato preocupante es que el 3.8% de las aplicaciones utilizan Log4j2 2.17.0, que fue parcheado contra Log4Shell, pero contiene CVE-2021-44832, otra vulnerabilidad de ejecución remota de código de alta gravedad.

El informe subraya que, a pesar de los esfuerzos realizados en los últimos años para mejorar las prácticas de seguridad en el desarrollo de software y el uso de código abierto, queda trabajo por hacer.

Chris Eng, director de investigación de Veracode, destaca que:

Los desarrolladores tienen una responsabilidad crucial y que hay margen de mejora en cuanto a la seguridad del software de código abierto.

Aunque muchos desarrolladores inicialmente respondieron adecuadamente a la crisis de Log4j instalando la versión 2.17.0, el informe sugiere que algunos volvieron a patrones anteriores al no aplicar parches más allá del lanzamiento de 2.17.1.

La Apache Software Foundation (ASF) ha estado activamente notificando a los proyectos downstream sobre la urgencia de actualizar, pero los hallazgos del informe indican que aún hay aplicaciones que no han implementado las correcciones necesarias.

El informe de Veracode se basó en datos de escaneos de software de más de 38,000 aplicaciones durante un período de 90 días, entre el 15 de agosto y el 15 de noviembre. Las aplicaciones ejecutaban versiones de Log4j desde la 1.1 hasta la 3.0.0 alfa 1 en 3,866 organizaciones diferentes.

Nuestra investigación también encontró que una vez que los desarrolladores son alertados sobre una biblioteca vulnerable a través de un análisis, las solucionan relativamente rápido: el 50 por ciento de las vulnerabilidades se solucionan en 89 días en general, en 65 días para las vulnerabilidades de gravedad alta y en 107 días para las vulnerabilidades de gravedad media.

Estos resultados concuerdan con las advertencias previas, como el informe de la Junta Federal de Revisión de Seguridad Cibernética de 2022, que indicó que la crisis de Log4j tomaría años en resolverse por completo.

Finalmente si estás interesado en poder conocer más al respecto, te invito a que visites el artículo original del blog de veracode. El enlace es este.

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