Daily Archives: April 27, 2022

Richard Stallman habla sobre el estado del movimiento del software libre y ataca a Apple y Canonical

Posted on by

 

Hace algunos dias Richard Stallman habló sobre «el estado del movimiento del software libre» y en lo cual no ha sido amable con Apple y Canonical en estos comentarios.

Y es que Richard Stallman menciona que Apple continúa convirtiendo a las Mac en una especie de «prisión» al impedir que los usuarios hagan lo que quieran con sus máquinas e instalen sus propios programas o archivos binarios obtenidos de otras personas, a lo cual «señaló que esto debería ser ilegal», ademas de que Stallman también desaconseja el uso de Ubuntu, que dice que no es una distribución gratuita de GNU/Linux.

Para quienes desconocen de Richard Matthew Stallman (RMS), deben saber que tuvo una gran influencia en el mundo del software (en particular, el software libre), pero también es conocido por sus comentarios y posiciones a veces controvertidos.

Ferviente defensor del software libre, no pierde la oportunidad de criticar a las empresas en el origen de las soluciones propietarias y lidera una lucha especial contra Apple. RMS ha criticado repetidamente a la empresa y a su cofundador Steve Jobs, acusándolos de haber creado «un ecosistema informático cerrado en el que los usuarios están en prisión». Para él, nadie tiene derecho a prohibir que la gente haga lo que quiera con las máquinas que ha comprado.

“Steve Jobs, el pionero de la computación carcelaria genial diseñada para robarle a la gente su libertad, está muerto. No me alegro de que esté muerto, pero me alegro de que se haya ido. Nadie merece morir, ni siquiera Jobs, o Bill Gates, o incluso personas culpables de fechorías mayores. Pero todos merecemos el fin de la influencia maligna de Jobs en la informática de las personas. La gente debería dejar de elogiar a Jobs por el elegante estilo carcelario que creó con su firma. Es un error meter a los usuarios en la cárcel”, dijo el evangelista del software libre poco después de la muerte del difunto Steve Jobs.

En su presentación de una hora y media sobre «El estado del movimiento del software libre» Stallman no ha cambiado su retórica frente a Apple. Según la Free Software Foundation (FSF), «Debido a dificultades técnicas imprevistas, RMS realizó su presentación en forma de podcast». La FSF ha puesto a disposición el audio para que lo escuche, pero mientras tanto, aquí está la transcripción de algunos pasajes de su discurso.

RMS comenzó agradeciendo a todos los que contribuyeron con el software libre y alentó a aquellos que quieran ayudar a visitar el sitio web del Proyecto GNU.

“El movimiento del software libre es universal y moralmente no debería excluir a nadie. Aunque hay delitos que deben ser castigados, impedir que alguien contribuya al software libre castiga al mundo. Esa persona no”, dijo. También señaló algunas cosas que han mejorado en el movimiento del software libre, incluidas grandes mejoras en proyectos como GNU Emacs cuando se visualizan paquetes externos.

RMS estaba particularmente enojado porque «todas las empresas tecnológicas ahora quieren encerrar a las personas y subyugarlas». Según él, “esto desvía la informática de su propósito original, que es hacer la vida más fácil a las personas”.

“Bueno, las máquinas gratuitas que tenemos están envejeciendo y escaseando. Es difícil encontrar una manera de respaldar algo nuevo, porque tanto Intel como AMD diseñan su hardware para subyugar a las personas. Si fueran fundamentalmente críticos públicos, sería difícil que lo hicieran peor de lo que lo están haciendo”, dijo.

Luego habló sobre Ubuntu, la distribución desarrollada y comercializada por Canonical:

“Ubuntu es, por supuesto, una distribución no libre y no recomendaría a nadie que la use. Algunos paquetes importantes ahora solo se distribuyen mediante su sistema de paquetes que no respeta la libertad, no como paquetes Debian. Por lo tanto, es aún más difícil que antes obtener alguna libertad de una instalación de Ubuntu”, dijo RMS. 

Posterior a ello Stallman hablo sobre la libertad material y el Macintosh:

“Los Macins se están convirtiendo en prisiones, como los iMonsters. Cada vez es más difícil para los usuarios incluso instalar sus propios programas para que funcionen. Y eso, por supuesto, debería ser ilegal. Debería ser ilegal vender una computadora que no permita a los usuarios instalar su propio software desde el código fuente. Y probablemente no debería permitirse que la computadora le impida instalar archivos binarios que obtiene de otras personas, aunque es cierto que en tales casos lo hace bajo su propio riesgo», dijo RMS.

RMS terminó su presentación anunciando un nuevo libro que ha escrito, un manual para el compilador GNU C.

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

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

El proyecto VeriGPU anuncio el desarrollo de una GPU abierta

Posted on by

El proyecto VeriGPU dio a conocer hace pocos dias que ha comenzado a trabajar en el desarrollo de una GPU abierta, la cual tiene como objetivo ser desarrollada bajo el lenguaje de modelado y descripción de sistemas electrónicos Verilog.

Para quienes desconocen de VeriGPU, deben saber que este se posiciona como un procesador específico de aplicaciones (ASIC) optimizado para acelerar los cálculos relacionados con los sistemas de aprendizaje automático.

De manera iniciar, el proyecto se está desarrollando utilizando el simulador Verilog, pero después de que esté listo, se puede utilizar para producir chips reales.

Los planes incluyen compatibilidad con el marco de aprendizaje profundo PyTorch y la capacidad de desarrollar aplicaciones para VeriGPU utilizando la API HIP (interfaz de computación heterogénea). En un futuro no se descarta la incorporación de soporte para otras API, como SYCL y NVIDIA CUDA.

Es importante mencionar que el desarrollo de esta GPU está dirigida directamente al entrenamiento de aprendizaje automático. Por lo tanto, idealmente debería ser compatible con los marcos de aprendizaje automático actuales, como PyTorch y Tensorflow, esto significa que es casi seguro que debe ser compatible con NVIDIA CUDA o AMD HIP.

Aunque tambien se menciona que sé podría implementar una interfaz OpenCL o SYCL, aunque actualmente la compatibilidad con los marcos principales es limitada. Hay un marco de aprendizaje profundo de OpenCL dedicado en DeepCL, pero tiene un conjunto relativamente limitado de capas de red neuronal y posibles topologías de red, en comparación con PyTorch y Tensorflow.

Actualmente, no tenemos la intención de implementar la ejecución fuera de orden, es decir, comenzar una instrucción antes de que haya comenzado la anterior, porque esto es complicado en un escenario de subprocesos múltiples de una sola instrucción (SIMT), y porque esto hace que los núcleos usen más área de troquel. , y por lo tanto menos en número (o más caro).

Por otro lado, implementaremos la ejecución de instrucciones en paralelo, donde comenzamos una instrucción mientras la instrucción anterior aún se está ejecutando. Esto es estándar y bastante liviano, no ocupa demasiada área de troquel.

Actualmente no se implementa almacenamiento en caché de ningún tipo (sin nivel 1, sin nivel 2, sin nivel 3, ni siquiera caché de instrucciones: P). Dado que tengo la intención de crear una GPU, que tiene un mecanismo de caché diferente al de la CPU, pensaré en esto una vez que comience a parecerse más a una GPU.

La GPU evoluciona en función del conjunto de instrucciones de RISC-V, pero la arquitectura del conjunto de instrucciones de GPU interno resultante es poco compatible con RISC-V ISA, ya que en situaciones en las que el diseño de la GPU no se ajusta a la representación de RISC-V, ademas de que no se establece la tarea de mantener la compatibilidad con RISC-V.

Dado que el desarrollo se centra en las capacidades requeridas para los sistemas de aprendizaje automático, por lo tanto, para reducir el tamaño y la complejidad de la matriz del chip, solo se utiliza el formato de coma flotante BF16 y solo las operaciones de coma flotante que están en demanda para el aprendizaje automático, como exp, log, tanh y sqrt, están disponibles.

De los componentes ya disponibles se mencionan por ejemplo el controlador GPU, APU (Accelerated Processing Unit) para operaciones con enteros («+»,»-«,»/»,»*»), unidad para operaciones de punto flotante («+»,»*») y una unidad de ramificación, asi como también el soporte para el compilador HIP.

Para la creación de aplicaciones se ofrece ensamblador y soporte para compilar código C++ basado en LLVM. De las características previstas, se destacan la ejecución paralela de instrucciones, el almacenamiento en caché de datos y la memoria de instrucciones, las operaciones SIMT (Single Instruction Multiple Thread).

Finalmente, si estás interesado en poder conocer más al respecto sobre el desarrollo de esta GPU de código abierto, debes saber que los desarrollos del proyecto se distribuyen bajo la licencia MIT y puedes consultar el código, asi como los avances del proyecto desde el siguiente enlace.

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

La implementación OpenCL de Mesa escrita en rust ya supero las pruebas CTS

Posted on by

La nueva implementación de OpenCL (rusticl) desarrollada para el proyecto Mesa, escrita en Rust, ha superado con éxito las pruebas CTS (Kronos Conformance Test Suite) utilizadas por el consorcio Khronos para evaluar la compatibilidad con las especificaciones de OpenCL 3.0.

Para quienes desconocen de»Rusticl» deben saber que este se ha publicado como una nueva implementación de Mesa OpenCL escrita en el lenguaje de programación Rust.

Rusticl fue iniciado por el conocido colaborador de Mesa Karol Herbst de Red Hat quien comenzó como ingeniero del controlador de código abierto»Nouveau» de NVIDIA mientras estaba en Red Hat, y trabajó en el soporte informático Clover de Mesa y otros esfuerzos. Rusticl es un intento de Herbst de aprender el lenguaje de programación Rust y también de proporcionar una nueva (y con suerte superior) implementación de OpenCL.

Rusticl es mucho más moderno enfocado en OpenCL en comparación con el antiguo código Clover y es notable, sin embargo, es que Rusticl en este momento todavía no tiene soporte de imagen OpenCL que ha sido otro problema con Clover.

Rusticl confía en clc para compilar el código fuente de OpenCL en SPIR-V. Rusticl también depende de los controladores Mesa Gallium3D compatibles con NIR, pero todos los controladores principales ya lo hacen. Cabe señalar que Carol se puso en contacto con Khronos para obtener la certificación oficial de compatibilidad con OpenCL 3.0 en rusticl.

Y ahora, rusticl ha pasado con éxito las pruebas Kronos Conformance Test Suite para evaluar la compatibilidad con las especificaciones de OpenCL 3.0, asi lo anuncio en Twitter neil trevett:

Khronos se enorgullece de haber renunciado a todas las tarifas de adopción de MESA a lo largo de los años, y muchas implementaciones de MESA son oficialmente conformes. ¡Genial que OpenCL 3.0 de MESA esté pasando CTS! Infórmenos cuando MESA esté listo para ejecutar el Acuerdo de adopción de OCL 3.0 y podamos iniciar el proceso…

Las pruebas se realizaron en un sistema con GPU Intel de 12.ª generación (Alder Lake), con el cual el trabajo se realizó con el controlador Iris Mesa, pero se menciona que el proyecto debería funcionar con otros controladores Mesa que usen la representación intermedia (IR) sin tipo de los sombreadores NIR.

Rusticl actúa como una contraparte de la interfaz OpenCL Clover de Mesa y también se desarrolla utilizando la interfaz Gallium de Mesa. Clover lleva mucho tiempo en estado de abandono y rusticl se posiciona como su futuro reemplazo. Además de lograr la compatibilidad con OpenCL 3.0, el proyecto Rusticl se diferencia de Clover en que admite extensiones OpenCL para el procesamiento de imágenes , pero aún no admite el formato FP16.

Rusticl usa rust-bindgen para generar enlaces para Mesa y OpenCL que permiten llamar a las funciones de Rust desde el código C y viceversa.

La posibilidad de usar el lenguaje Rust en el proyecto Mesa se discute desde 2020. Entre las ventajas del soporte de Rust mencionan mejorar la seguridad y calidad de los drivers al eliminar problemas típicos cuando se trabaja con memoria, así como la posibilidad de incluir desarrollos de terceros en Mesa, como Kazan (una implementación de Vulkan en Óxido).

Entre las deficiencias, hay una complicación del sistema de compilación, la falta de voluntad para vincularse al sistema de paquetes de carga, un aumento en los requisitos para el entorno de compilación y la necesidad de incluir el compilador Rust en las dependencias de compilación que se requieren para construir componentes de escritorio clave en Linux.

Finalmente, se menciona que la solicitud para fusionar Rusticl con Mesa aún está pendiente y aún no se ha tomado una decisión sobre la inclusión del código de idioma Rust en Mesa, pero se espera que llegue en la versión de Mesa 22.2

Es por ello que antes de que Rusticl sea aceptado en la composición principal de Mesa, se puede usar una rama separada para construir, al compilar, debe especificar los parámetros de compilación «-Dgallium-rusticl=true -Dopencl-spirv=true -Dshader-cache=true -Dllvm =true».

Si estás interesado en poder conocer más al respecto sobre esta nueva especificación, puedes consultar los detalles en el siguiente enlace.

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

Fighting Fake EDRs With ‘Credit Ratings’ for Police

Posted on by

When KrebsOnSecurity recently explored how cybercriminals were using hacked email accounts at police departments worldwide to obtain warrantless Emergency Data Requests (EDRs) from social media firms and technology providers, many security experts called it a fundamentally unfixable problem. But don’t tell that to Matt Donahue, a former FBI agent who recently quit the agency to launch a startup that aims to help tech companies do a better job screening out phony law enforcement data requests — in part by assigning trustworthiness or “credit ratings” to law enforcement authorities worldwide.

A sample Kodex dashboard. Image: Kodex.us.

Donahue is co-founder of Kodex, a company formed in February 2021 that builds security portals designed to help tech companies “manage information requests from government agencies who contact them, and to securely transfer data & collaborate against abuses on their platform.”

The 30-year-old Donahue said he left the FBI in April 2020 to start Kodex because it was clear that social media and technology companies needed help validating the increasingly large number of law enforcement requests domestically and internationally.

“So much of this is such an antiquated, manual process,” Donahue said of his perspective gained at the FBI. “In a lot of cases we’re still sending faxes when more secure and expedient technologies exist.”

Donahue said when he brought the subject up with his superiors at the FBI, they would kind of shrug it off, as if to say, “This is how it’s done and there’s no changing it.”

“My bosses told me I was committing career suicide doing this, but I genuinely believe fixing this process will do more for national security than a 20-year career at the FBI,” he said. “This is such a bigger problem than people give it credit for, and that’s why I left the bureau to start this company.”

One of the stated goals of Kodex is to build a scoring or reputation system for law enforcement personnel who make these data requests. After all, there are tens of thousands of police jurisdictions around the world — including roughly 18,000 in the United States alone — and all it takes for hackers to abuse the EDR process is illicit access to a single police email account.

Kodex is trying to tackle the problem of fake EDRs by working directly with the data providers to pool information about police or government officials submitting these requests, and hopefully making it easier for all customers to spot an unauthorized EDR.

Kodex’s first big client was cryptocurrency giant Coinbase, which confirmed their partnership but otherwise declined to comment for this story. Twilio confirmed it uses Kodex’s technology for law enforcement requests destined for any of its business units, but likewise declined to comment further.

Within their own separate Kodex portals, Twilio can’t see requests submitted to Coinbase, or vice versa. But each can see if a law enforcement entity or individual tied to one of their own requests has ever submitted a request to a different Kodex client, and then drill down further into other data about the submitter, such as Internet address(es) used, and the age of the requestor’s email address.

Donahue said in Kodex’s system, each law enforcement entity is assigned a credit rating, wherein officials who have a long history of sending valid legal requests will have a higher rating than someone sending an EDR for the first time.

“In those cases, we warn the customer with a flash on the request when it pops up that we’re allowing this to come through because the email was verified [as being sent from a valid police or government domain name], but we’re trying to verify the emergency situation for you, and we will change that rating once we get new information about the emergency,” Donahue said.

“This way, even if one customer gets a fake request, we’re able to prevent it from happening to someone else,” he continued. “In a lot of cases with fake EDRs, you can see the same email [address] being used to message different companies for data. And that’s the problem: So many companies are operating in their own silos and are not able to share information about what they’re seeing, which is why we’re seeing scammers exploit this good faith process of EDRs.”

NEEDLES IN THE HAYSTACK

As social media and technology platforms have grown over the years, so have the volumes of requests from law enforcement agencies worldwide for user data. For example, in its latest transparency report mobile giant Verizon reported receiving 114,000 data requests of all types from U.S. law enforcement entities in the second half of 2021.

Verizon said approximately 35,000 of those requests (~30 percent) were EDRs, and that it provided data in roughly 91 percent of those cases. The company doesn’t disclose how many EDRs came from foreign law enforcement entities during that same time period. Verizon currently asks law enforcement officials to send these requests via fax.

Validating legal requests by domain name may be fine for data demands that include documents like subpoenas and search warrants, which can be validated with the courts. But not so for EDRs, which largely bypass any official review and do not require the requestor to submit any court-approved documents.

Police and government authorities can legitimately request EDRs to learn the whereabouts or identities of people who have posted online about plans to harm themselves or others, or in other exigent circumstances such as a child abduction or abuse, or a potential terrorist attack.

But as KrebsOnSecurity reported in March, it is now clear that crooks have figured out there is no quick and easy way for a company that receives one of these EDRs to know whether it is legitimate. Using illicit access to hacked police email accounts, the attackers will send a fake EDR along with an attestation that innocent people will likely suffer greatly or die unless the requested data is provided immediately.

In this scenario, the receiving company finds itself caught between two unsavory outcomes: Failing to immediately comply with an EDR — and potentially having someone’s blood on their hands — or possibly leaking a customer record to the wrong person. That might explain why the compliance rate for EDRs is usually quite high — often upwards of 90 percent.

Fake EDRs have become such a reliable method in the cybercrime underground for obtaining information about account holders that several cybercriminals have started offering services that will submit these fraudulent EDRs on behalf of paying clients to a number of top social media and technology firms.

A fake EDR service advertised on a hacker forum in 2021.

An individual who’s part of the community of crooks that are abusing fake EDR told KrebsOnSecurity the schemes often involve hacking into police department emails by first compromising the agency’s website. From there, they can drop a backdoor “shell” on the server to secure permanent access, and then create new email accounts within the hacked organization.

In other cases, hackers will try to guess the passwords of police department email systems. In these attacks, the hackers will identify email addresses associated with law enforcement personnel, and then attempt to authenticate using passwords those individuals have used at other websites that have been breached previously.

EDR OVERLOAD?

Donahue said depending on the industry, EDRs make up between 5 percent and 30 percent of the total volume of requests. In contrast, he said, EDRs amount to less than three percent of the requests sent through Kodex portals used by customers.

KrebsOnSecurity sought to verify those numbers by compiling EDR statistics based on annual or semi-annual transparency reports from some of the largest technology and social media firms. While there are no available figures on the number of fake EDRs each provider is receiving each year, those phony requests can easily hide amid an increasingly heavy torrent of legitimate demands.

Meta/Facebook says roughly 11 percent of all law enforcement data requests — 21,700 of them — were EDRs in the first half of 2021. Almost 80 percent of the time the company produced at least some data in response. Facebook has long used its own online portal where law enforcement officials must first register before submitting requests.

Government data requests, including EDRs, received by Facebook over the years. Image: Meta Transparency Report.

Apple said it received 1,162 emergency requests for data in the last reporting period it made public — July – December 2020. Apple’s compliance with EDRs was 93 percent worldwide in 2020. Apple’s website says it accepts EDRs via email, after applicants have filled out a supplied PDF form. [As a lifelong Apple user and customer, I was floored to learn that the richest company in the world — which for several years has banked heavily on privacy and security promises to customers — still relies on email for such sensitive requests].

Twitter says it received 1,860 EDRs in the first half of 2021, or roughly 15 percent of the global information requests sent to Twitter. Twitter accepts EDRs via an interactive form on the company’s website. Twitter reports that EDRs decreased by 25% during this reporting period, while the aggregate number of accounts specified in these requests decreased by 15%. The United States submitted the highest volume of global emergency requests (36%), followed by Japan (19%), and India (12%).

Discord reported receiving 378 requests for emergency data disclosure in the first half of 2021. Discord accepts EDRs via a specified email address.

For the six months ending in December 2021, Snapchat said it received 2,085 EDRs from authorities in the United States (with a 59 percent compliance rate), and another 1,448 from international police (64 percent granted). Snapchat has a form for submitting EDRs on its website.

TikTok‘s resources on government data requests currently lead to a “Page not found” error, but a company spokesperson said TikTok received 715 EDRs in the first half of 2021. That’s up from 409 EDRs in the previous six months. Tiktok handles EDRs via a form on its website.

The current transparency reports for both Google and Microsoft do not break out EDRs by category. Microsoft says that in the second half of 2021 it received more than 25,000 government requests, and that it complied at least partly with those requests more than 90 percent of the time.

Microsoft runs its own portal that law enforcement officials must register at to submit legal requests, but that portal doesn’t accept requests for other Microsoft properties, such as LinkedIn or Github.

Google said it received more than 113,000 government requests for user data in the last half of 2020, and that about 76 percent of the requests resulted in the disclosure of some user information. Google doesn’t publish EDR numbers, and it did not respond to requests for those figures. Google also runs its own portal for accepting law enforcement data requests.

Verizon reports (PDF) receiving more than 35,000 EDRs from just U.S. law enforcement in the second half of 2021, out of a total of 114,000 law enforcement requests (Verizon doesn’t disclose how many EDRs came from foreign law enforcement entities). Verizon said it complied with approximately 91 percent of requests. The company accepts law enforcement requests via snail mail or fax.

Image: Verizon.com.

AT&T says (PDF) it received nearly 19,000 EDRs in the second half of 2021; it provided some data roughly 95 percent of the time. AT&T requires EDRs to be faxed.

The most recent transparency report published by T-Mobile says the company received more than 164,000 “emergency/911” requests in 2020 — but it does not specifically call out EDRs. Like its old school telco brethren, T-Mobile requires EDRs to be faxed. T-Mobile did not respond to requests for more information.

Data from T-Mobile’s most recent transparency report in 2020. Image: T-Mobile.

from Krebs on Security https://ift.tt/qeKv1W8
via IFTTT