Remember the 80286? It was the sequel to the 8086, the chip that started it all, and it powered a great number of machines in the early years of the personal computing revolution. It might not be as relevant today, but regardless, [Daniel Balsom] has now released a comprehensive test suite for the ancient chip. (via The Register)

The complete battery of tests are available on Github, and were produced using a Harris N80C286-12 from 1986. “The real mode test suite contains 326 instruction forms, containing nearly 1.5 million instruction executions with over 32 million cycle states captured,” Daniel explains. “This is fewer tests than the previous 8088 test suite, but test coverage is better overall due to improved instruction generation methods.” For now, the tests focus on the 286 running in real mode. There are no “unreal” or protected mode tests, but [Daniel] aims to deliver the in the future.

[Daniel] uses the tests with the ArduinoX86, a platform that uses the microcontroller to control and test old-school CPUs. The tests aid with development of emulators like [Daniel’s] own MartyPC, by verifying the CPU’s behavior in a cycle-accurate way.

We’ve explored some secrets of the 286 before, too. If you’ve been doing your own digging into Intel’s old processors, or anyone else’s for that matter, don’t hesitate to notify the tipsline.

[Thanks to Stephen Walters for the tip!]

hackaday.com/2025/07/24/compre…

L’azienda di sicurezza cloud Wiz ha identificato una vulnerabilità critica in NVIDIA Container Toolkit, identificata come CVE-2025-23266 e con un punteggio CVSS di 9.0. La vulnerabilità, denominata NVIDIAScape, potrebbe rappresentare una seria minaccia per i servizi cloud che utilizzano l’intelligenza artificiale e la containerizzazione basata su GPU.

Il bug riguarda tutte le versioni di NVIDIA Container Toolkit fino alla 1.17.7 inclusa, nonché NVIDIA GPU Operator fino alla versione 25.3.0. La vulnerabilità è già stata risolta rispettivamente nelle nuove versioni 1.17.8 e 25.3.1.

Il problema è legato all’utilizzo dei cosiddetti hook OCI, progettati per inizializzare i container. Uno di questi hook, “createContainer“, viene utilizzato con una configurazione errata, che consente a un aggressore di caricare una libreria dannosa all’avvio del container.

Il problema è che gli hook vengono eseguiti con privilegi elevati e nel contesto del file system del contenitore, consentendo all’attaccante di iniettare codice con il minimo sforzo. I ricercatori di Wiz hanno sottolineato che l’attacco può essere eseguito con sole tre righe nel Dockerfile, che impostano la variabile LD_PRELOAD e caricano la libreria dannosa. Di conseguenza, l’attaccante può non solo uscire dal contenitore, ma anche prendere il controllo del sistema host.

Ciò che è particolarmente allarmante è che la vulnerabilità interessa circa il 37% degli ambienti cloud che utilizzano l’intelligenza artificiale. Ciò significa che un singolo contenitore compromesso può essere utilizzato per accedere a dati e modelli di altri client ospitati sugli stessi server fisici. L’attacco potrebbe quindi portare a furti di proprietà intellettuale, interruzioni del flusso di lavoro e diniego di servizio.

Wiz aveva già segnalato due problemi simili nel toolkit di NVIDIA, CVE-2024-0132 e CVE-2025-23359 , entrambi con possibilità di acquisizione completa del sistema. La nuova vulnerabilità ha dimostrato ancora una volta quanto sia debole il meccanismo di isolamento nei container. Secondo il team, l’utilizzo esclusivo dei container come misura di sicurezza è inaccettabile: sono necessarie barriere aggiuntive come la virtualizzazione, soprattutto nelle infrastrutture multi-tenant.

La situazione di NVIDIAScape solleva interrogativi urgenti sulla resilienza delle infrastrutture moderne agli attacchi, dove vettori di hacking noti e legacy potrebbero essere più efficaci di ipotetiche minacce basate sull’intelligenza artificiale. Le problematiche a livello di componenti di base, come i container hook, dimostrano che l’attenzione ai dettagli e gli aggiornamenti regolari rimangono elementi chiave della difesa.

L'articolo L’isolamento dei container è a rischio. Solo 3 righe di codice per violare gli ambienti AI di NVIDIA proviene da il blog della sicurezza informatica.

Most research on electroplating tries to find ways to make it plate parts more uniformly. [Ajc150] took the opposite direction, though, with his selective electroplating project, which uses an electrode mounted on a CNC motion system to electrochemically print images onto a metal sheet (GitHub repository).

Normally, selective electroplating would use a mask, but masks don’t allow gradients to be deposited. However, electroplating tends to occur most heavily at the point closest to the anode, and the effect gets stronger the closer the anode is. To take advantage of this effect, [ajc150] replaced the router of an inexpensive 3018 CNC machine with a nickel anode, mounted an electrolyte bath in the workspace, and laid a flat steel cathode in it. When the anode moves close to a certain point on the steel cathode, most of the plating takes place there.

To actually print an image with this setup, [ajc150] wrote a Python program to convert an image into set of G-code instructions for the CNC. The darker a pixel of the image was, the longer the electrode would spend over the corresponding part of the metal sheet. Since darkness wasn’t linearly proportional to plating time, the program used a gamma correction function to adjust times, though this did require [ajc150] to recalibrate the setup after each change. The system works well enough to print recognizable images, but still has room for improvement. In particular, [ajc150] would like to extend this to a faster multi-nozzle system, and have the algorithm take into account spillover between the pixel being plated and its neighbors.

This general technique is reminiscent of a metal 3D printing method we’ve seen before. We more frequently see this process run in reverse to cut metal.

hackaday.com/2025/07/24/painti…

One of the categories we chose for the One Hertz Challenge is “Could Have Used a 555.” What about when you couldn’t have, but did anyway? The 555 is famously easy to use, but not exactly the most accurate timer out there — one “ticking” at 1 Hz will pulse just about once per second (probably to within a millisecond, depending on the rest of the circuit), but when you need more precise timing, the 555 just won’t cut it. Not on its own, anyway.
Allan Deviation can be a bit confusing, but generally — lower is more accurate
This entry by [burble] shows us how the humble 555 can hold its own in more demanding systems with some help from a GPS receiver. He used the One Pulse per Second (1PPS) output from a GPS module to discipline the 1 Hz output from a 555 by modulating the control voltage with a microcontroller.

Okay, this sounds a bit like baking a cake by buying a cake, scraping all the icing off, then icing it yourself, but what better way to learn how to ice a cake? The GPS-disciplined 555 is way more accurate than a free running one — just check out that Allan Deviation plot. While the accuracy of the standard 555 begins to decrease as oscillator drift dominates, the GPS-disciplined version just keeps getting better (up to a point — it would also eventually begin to increase, if the data were recorded for long enough). Compared to other high-end oscillators though, [burble] describes the project’s accuracy in one word: “Badly.”

That’s okay though — it really is a fantastic investigation into how GPS-disciplined oscillators work, and does a fantastic job illustrating the accuracy of different types of clocks, and some possible sources of error. This project is a great addition to some of the other precision timekeeping projects we’ve seen here at Hackaday, and a very fitting entry to the competition. Think you can do better? Or much, much worse? You’ve got a few weeks left to enter!

hackaday.com/2025/07/24/2025-o…

😍😍😍

youtu.be/18QQWa5MEcs?si=tFj9-s…

#marvel #Fantastic4