A History Of NASA Supercomputers, Among Others

The History Guy on YouTube has posted an interesting video on the history of the supercomputer, with a specific focus on their use by NASA for the implementation of computational fluid dynamics (CFD) models of aeronautical assemblies.

The aero designers of the day were quickly finding out the limitations of the wind tunnel testing approach, especially for so-called transonic flow conditions. This occurs when an object moving through a fluid (like air can be modeled) produces regions of supersonic flow mixed in with subsonic flow and makes for additional drag scenarios. This severely impacts aircraft performance. Not accounting for these effects is not an option, hence the great industry interest in CFD modeling. But the equations for which (usually based around the Navier-Stokes system) are non-linear, and extremely computationally intensive.

Obviously, a certain Mr. Cray is a prominent player in this story, who, as the story goes, exhausted the financial tolerance of his employer, CDC, and subsequently formed Cray Research Inc, and the rest is (an interesting) history. Many Cray machines were instrumental in the development of the space program, and now adorn computing museums the world over. You simply haven’t lived until you’ve sipped your weak lemon drink whilst sitting on the ‘bench’ around an early Cray machine.

You see, supercomputers are a different beast from those machines mere mortals have access to, or at least the earlier ones were. The focus is on pure performance, ideally for floating-point computation, with cost far less of a concern, than getting to the next computational milestone. The Cray-1 for example, is a 64-bit machine capable of 80 MIPS scalar performance (whilst eating over 100 kW of juice), and some very limited parallel processing ability.

While this was immensely faster than anything else available at the time, the modern approach to supercomputing is less about fancy processor design and more about the massive use of parallelism of existing chips with lots of local fast storage mixed in. Every hacker out there should experience these old machines if they can, because the tricks they used and the lengths the designers went to get squeeze out every ounce of processing grunt, can be a real eye-opener.

Want to see what happens when you really push out the boat and use the whole wafer for parallel computation? Checkout the Cerberus. If your needs are somewhat less, but dabbling in parallel computing gets you all pumped, you could build a small array out of Pine64s. Finally, the story wouldn’t be complete without talking about the life and sad early demise of Seymour Cray.
Continue reading “A History Of NASA Supercomputers, Among Others”

This Week In Security: Oracle Opera, Passkeys, And AirTag RFC

There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC”

Linux Cell Phone? Build OURPhone

[Evan] couldn’t find a phone he liked, so he decided to build his own. There are advantages and disadvantages, as you might expect. On the plus side, you have the ultimate control. On the negative side, it doesn’t quite have the curb appeal — at least to the average user — of a sleek new cell phone from a major manufacturer.

The phone uses a Raspberry Pi, along with a 4G modem and a 480×800 touchscreen. There’s a laser cut box that measures 90x160x30 mm. For reference, a Google Pixel 7 is about 73x156x9 mm, so a little easier on the pocket.

But not one the pocketbook. The OURPhone only costs about $200 USD to build. There are trade-offs. For example, the touchscreen is resistive, so you’ll want a stylus (there’s a slot for it in the case). On the other hand, if you don’t like something, it is all there for you to change.

Obviously, a better screen would help. Thinner batteries might be a good enhancement too. But that’s the beauty of an open project. You can do all these things and more.

We wondered if you could get one of the “mobile” Linux editions to run or even Android. It seems like the hardest part is coming up with a sophisticated enclosure.

CNC Feeds And Speeds, Explained As A First-Timer

If you’ve ever looked into CNC cutting tools, you’ve probably heard the term “feeds and speeds”. It refers to choosing the speed at which to spin the cutting tool, and how fast to plow it into the material being cut. They’re important to get right, and some of the reasons aren’t obvious. This led [Callan Bryant] to share his learned insights as a first-timer. It turns out there are excellent (and somewhat non-intuitive) reasons not to simply guess at the correct values!

A table of variables and how they relate to one another (click to enlarge).

The image above shows a tool damaged by overheating. [Callan] points out that as a novice, one might be inclined to approach a first cutting jobs conservatively, with a low feed rate. But doing this can have an unexpected consequence: a tool that overheats due to spinning too quickly while removing too little material.

CNC cutting creates a lot of heat from friction, and one way to remove that heat is by having the tool produce shavings, which help carry heat away. If a tool is making dust instead of shavings — for example if the feed rate is too conservative — the removed pieces will be too small to carry significant energy, and the tool can overheat.

[Callan] makes a table of variables at work in a CNC system in order to better understand their relationship before getting into making a formula for calculating reasonable feed and speed rates. Of course, such calculations are a reasonable starting point only, and it’s up to the operator to ensure things are happening as they should for any given situation. As our own Elliot Williams observed, CNC milling is a much more manual process than one might think.