(Local) AI, Please Write some Code

My previous blog post in this series tested the ability of a range of large language models to analyze a piece of C code and determine what a mystery function did. That was interesting and entertaining, but possibly not a particularly “fair” test of the models’ capabilities. Most of time, I think people use “AI” to help write code, not to understand some tricky piece of algorithmic code. Thus, I turn the problem around and ask the models to write code for the algorithm I previously asked them to analyze.

More Ghostwrite Bugginess with RISCVuzz

In my previous blog about the Ghostwrite vulnerability in the Alibaba T-Head C910 RISC-V-based processor, I noted that the authors of the paper had found more than just that one bug. The additional bugs are worth their own write-up, as they offer some more examples of what looks to be poor testing.

Ghostwrite – Now This is Weird

In August, a strange security vulnerability dubbed “Ghostwrite” was making the rounds in the press. Basically, a vector store instruction on an Alibaba T-Head C910 RISC-V-based processor would just write to a physical address without doing a virtual-to-physical translation or checking any kind of access rights. That is just totally weird. Just how could that be implemented and slip through testing???

The Quarterly Product and Feature Update

I think of myself to be a technical person. I like computers, simulators, code, things like that. And obviously interacting with people and helping them solve their technical problems using technology I know. However, it seems that one of the most impactful contributions made during my time at Intel was to start a meeting series. Maybe you can call it a process innovation.

Notes from our DVCon Europe 2022 Tutorial

I presented a tutorial about the “verification of virtual platforms models” at DVCon Europe last week. The tutorial was prepared by me and Ola Dahl at Ericsson, but Ola unfortunately could not attend and present his part – so I had to learn his slides and style and do my best to be an Ola stand-in (tall order, we really missed you there Ola!). The title maybe did not entirely describe the contents – it was more a discussion around how to think about correctness and in particular specifications vs implementations. The best part was the animated discussion that we got going in the room, including some new insights from the audience that really added to the presented content.

Updated: Included an important point on software correctness that I forgot in the first publication.

The ESA Schiaparelli Crash & Simulation

Back in 2016, the European Space Agency (ESA) lost the Schiaparelli Mars lander during its descent to the surface on Mars. From a software engineering and testing perspective, the story of why the landing failed (see for example the ESA final analysis, Space News, or the BBC) is instructive. It comes down to how software is written and tested to deal with unexpected inputs in unexpected circumstances. I published a blog post about this right after the event and before the final analysis was available. Thankfully, that has since been retired from its original location-it was a bit too full of speculation that turned out to be incorrect… So here is a mostly rewritten version of the post, quoting the final analysis and with new insights.

Blog – Damn the Torpedoes, Full Code Ahead!

I have recently got back to developing training labs for the Simics simulator (and related technologies). During the process of developing a new accelerator model using as many of the latest frameworks and APIs as possible, it was basically guaranteed that I would hit some bugs and unexpected behaviors. That is a natural part of and benefit from creating training materials in the first place. It also provides a good illustration of two fundamentally different ways to look at software development. One is to play it safe and get things done in known ways, and the other is charge ahead, try the unknown, and see what happens. Damn the torpedoes, bugs are a benefit. No bug reports, no glory. In this post, I will share some recent examples of just coding ahead and breaking thing.

Intel Blog: How Teaching Users Drives Product Improvements in Simics

I have a post out on the Intel Software blog about my experience developing and delivering training for Simics over the past few years. A key observation is that building training is a great way to test the product, and drives changes and improvements in the product. The blog is found at https://software.intel.com/content/www/us/en/develop/articles/teaching-users-drives-product-improvements-in-simics-sw.html

Intel Blog Post: “Quit Thinking and Look” – Mea Culpa Chasing a Performance Bug

I have written before about the debug advice to “Quit thinking and look.” It means that you should not form conclusions prematurely. Stop and look at what is going on instead of guessing and cooking up theoretical scenarios. Sound advice that I completely failed to follow in the case that I just chronicled on my Intel Blog: https://software.intel.com/en-us/blogs/2020/03/18/quit-thinking-and-look-chasing-simics-performance

“Always Measure one Level Deeper” – Advice on Performance Measurements

Recently I stumbled on a nice piece called “Always Measure One Level Deeper” by John Ousterhout, from Communications of the ACM, July 2018. https://cacm.acm.org/magazines/2018/7/229031-always-measure-one-level-deeper/fulltext. The article is about performance analysis, and how important it is to not just look at the top-level numbers and easy-to-see aspects of a system, but to also go (at least) one level deeper to measure the components and subsystems that affect the overall system performance.

Continue reading ““Always Measure one Level Deeper” – Advice on Performance Measurements”

Undo Reverse Debugger “Pivots” to Record-Replay

I just found a story about Undo software that was rather interesting from a strategic perspective. “Patient capital from CIC gives ‘time travelling’ company Undo space to pivot“, from the BusinessWeekly in the UK. The article describes a change from selling to individual developers, towards selling to enterprises. This is an important business change, but it also marks I think a technology thinking shift: from single-session debug to record-replay.

Continue reading “Undo Reverse Debugger “Pivots” to Record-Replay”

Simulators in Racks at the Embedded World 2018

I work with virtual platforms and software simulation technology, and for us most simulation is done on standard servers, PCs, or latptops. Sometimes we connect up an FPGA prototype or emulator box to run some RTL, or maybe a real-world PCIe device, but most of the time a simulator is just another general-purpose computer with no special distinguishing properties. When connecting to the real world, it is simple standard things like Ethernet, serial ports, or USB.

There are other types of simulators in the world however – still based on computers running software, but running it somehow closer to the real world, and with actual physical connections to real hardware beyond basic Ethernet and USB. I saw a couple of nice examples of this at the Embedded World back in February, where full-height racks were basically “simulators”.

Continue reading “Simulators in Racks at the Embedded World 2018”

Intel Blog: Finding BIOS Vulnerabilities with Symbolic Execution and Virtual Platforms

I have just published a piece about the Intel Excite project on my Software Evangelist blog at the Intel Developer Zone. The Excite project is using a combination of of symbolic execution, fuzzing, and concrete testing to find vulnerabilities in UEFI code, in particular in SMM. By combining symbolic and concrete techniques plus fuzzing, Excite achieves better performance and effect than using either technique alone.

Continue reading “Intel Blog: Finding BIOS Vulnerabilities with Symbolic Execution and Virtual Platforms”

How 3dfx was Built on a Simulator

This blog post was originally published at Intel. After it was retired from the Intel blog system, I reposted the full contents here in order to preserve the information for my own sake. And in case anyone has a pointer here.

How Simulation Started a Billion-Dollar Company

In the early 1990s, “PC graphics” was almost an oxymoron. If you wanted to do real graphics, you bought a “real machine”, most likely a Silicon Graphics workstation. At the PC price-point, fast hardware-accelerated 3D graphics wasn’t doable… until it suddenly was, thanks to Moore’s law. 3dfx was the first company to create fast 3D graphics for PC gamers. To get off the ground and get funded, 3dfx had to prove that their ideas were workable – and that proof came in the shape of a simulator. They used the simulator to demo their ideas, try out different design points, develop software pre-silicon, and validate the silicon once it arrived.

Continue reading “How 3dfx was Built on a Simulator”

Intel Blog: Continuous Delivery for Embedded Systems and how Simulation can Help

Doing continuous integration and continuous delivery for embedded systems is not necessarily all that easy. You need to get tools in place to support automatic testing, and free yourself from unneeded hardware dependencies. Based on an inspiring talk by Mike Long from Norway, I have a piece on how simulation helps with embedded CI and CD on my Software Evangelist blog on the Intel Developer Zone.