There is one recurring question I get, and that is “Why if you are an HPC company do you care about or post on security and system availability/uptime issues?”

Let me explain why. First of all, we are not a security processor company. Second, we believe that security and hardening measures must be included in all new hardware, firmware, operating systems and application software. Third, we see that with 5G and Fiber To The Home (FTTH) and Fiber To The Curb (FTTC) the attack surface for the Internet backend has grown and will continue to grow, and the available bandwidth for attacks to take out large portions of the Internet infrastructure has increased to a degree that the so-called “edge” will have to take a role in protecting the backend.

The magical “edge” is the collection of curbside compute that allows for 5G and FTTH and FTTC to be viable and useful. Edge computing reduces latency to the user as some of the preprocessing is executed there, and low latency is crucial for a wide variety of applications – gaming and Advanced Driver Assistance Systems (ADAS) as well as Vehicle-to-anything (V2X) included. While most compute will still occur in the backend, the edge will become more powerful, but unlike the backend, the edge is not physically protected. As a result, any attacker will have relatively easy access to the compute power at the edge. Because of the compute performance and the bandwidth of edge devices, an attacker can wreak havoc on the Internet backend, including supercomputers. Therefore, we believe that the edge must be able to protect itself and the backend from attackers as much as possible. A botnet of edge devices will bring down the Internet.

We have seen the tactics of attackers change. We went from Denial-of-Service (DoS) and distributed Denial-of-Service (DDoS) attacks to attacks against the DNS system, and while the Internet did not go down, many users experienced it as such. While we have our own DNS servers, and we were able to continue to work without interruption, many other users were not. With more bandwidth and compute power at the edge, an attacker has a much higher chance to disrupt Internet access and Internet traffic.

That is why we focus on the system availability including security measures we need to take to protect systems built with our processors. If a system is under attack, if its incoming links are unavailable, if it has been forced to reboot or is in a rolling recovery situation, it is not available for its intended tasks. This is all counted towards system downtime, and HPC time is expensive and precious. As a result, we try to make sure that systems built with our processors have the hardware and firmware robustness needed to withstand an onslaught of attacks from compromised edge devices, and ideally, we’d work with those edge devices to avert a situation in which a large number of edge devices is compromised in the first place.

Due to its enormous compute power and bandwidth we need to make sure that compromising a supercomputer cannot occur. Any computer is most vulnerable to attacks during boot time, when most hardware and software security mechanisms are not yet active. We are working on solutions to plug those holes. We are also working on a more active firewall. For example, if someone pings us, we do not respond. If from the same IP address we then see a netscan, that event is logged, but today manual intervention is needed to block that IP address. That does not make sense – the firewall should block that IP address after one ping (or traceroute) and one netscan attempt all by itself.

Aside from those reasons, I am as annoyed as anyone else if the Internet is not available or upload or download speeds are abysmal – even at home.

It was only a matter of time until somone would announce and implement HPC as a Service (in the Cloud, of course).

Fundamentally, a supercomputer today is the same as any data center operated by the hyperscalers and all of the Cloud providers. The infrastructure in both cases consists of Commercial Off-The Shelf (COTS) x86-64 servers, connected via COTS top-of-the-rack switches and a COTS global switch connecting the top-of-the-rack switches, plus an equivalent storage subsystem, and some of the general-purpose CPUs may be accelerated via General-Purpose Graphics Processing Units (GPGPUs).

The only difference is in the interconnect, which in the case of the hyperscalers usually is 10 Gbit/s Ethernet, whereas the Supercomputer faction typically uses lower-latency and higher-bandwidth InfiniBand with DDR or QDR data rates of 20 or 40 Gbit/s. As a consequence, it does not take much to change a portion of a hyperscalers' data center over to support both Ethernet and InfiniBand, and sell the CPU hours at a much higher price to HPC users compared to normal users.

Here at ZDNet is one of the stories about HPC as a Service.

Intel has been in the news a lot lately. That is largely due to Pat Gelsinger rejoining Intel. I have the upmost respect for Pat, and I know that he is up to quite a challenge.

I don't know how to say this this any friendlier than this, but at this point in time Intel is a half-trick pony. Intel has x86-64 that is slowly but surely running out of steam, and a few failed expensive acquisitions that don't play well together. MobilEye and Altera really don't complement each other, and I do not see how Nervana and Habana could augment each other's offerings. Also, Intel just discontinued Itanium, and while that was a good and overdue step, it reduces the options in processor ISAs that Intel has available to itself.

Then there is the fact that in all large organizations complacency sets in. In the beginning, every startup will attract people who want to do something exciting and new, and they work their butts off. Once a company is established and generates profits, it will attract a different kind of applicant. They are usually seat warmers, and their only purpose is to collect a paycheck. They are the status-quo people who object to any change. They justify their behavior to themselves and to others by stating that someone has to keep a straight course. They know or at least suspect that their behavior might sink the ship, but then do the math and quickly come to their conclusion that the 15 years they need to retire is not enough for the mothership to go belly up.

Pat will have to clean out the house. I assume that in due time, we will see a RIF to get rid of people who do not contribute. He is in a much better position to identify those than the prior CEOs who were deeply non-technical. He will need chip manufacturing capacity, and that is where the GloFo acquisition comes in handy. He needs a different processor architecture as it is certain that x86-64 will run out of steam. That is where SiFive fits in, and I had alluded to that earlier here: Intel interested in SiFive. GloFo will also help Intel to be a more customer-centric organization, and while GloFo itself is not the best at that, it will be a wakeup call. Intel will be able to shift production around: datacenter CPUs and accelerators on its newest nodes, and all supporting and peripheral chips in the older fabs from Intel and in the newly acquired GloFo fabs. Then slowly build out ex GloFo, bring them into the FinFET and GAA age, and then reap the benefits of using the tools that external customers use inside Intel as well. I suspect that at this point in time, Intel spends a fortune on tools developed in-house for the design and the DV (design verification) of its processor and peripherals. If Intel can switch over to commercially available tools from Synopsys, Cadence and Siemens Software (ex Mentor) as well as from AnSys, then that would save tons of money, it would allow Intel to attract design engineers from the outside and get them productive without retraining on its internal tools.

Over 20 years ago, Intel introduced a non-x86 processor, the Itanium. This was a collaboration between HP and Intel for a successor to the Intel x86 architecture. HP contributed what was HP PA (Precision Architecture), and Intel added EPIC (Explicit Parallel Instruction Computing). EPIC was a departure from traditional CPU design as it relegated a lot of the work of parallelizing instructions to the compiler instead of hardware within the CPU. Intel promised improved performance over the traditional design philosophies, and positioned Itanium above anything x86. Unfortunately, those promises never materialized. Itanium not only was unable to ever surpass x86 in performance in emulated or in native mode, and even native Itanium applications never were able to drastically outperform any other competitor. Part of the problem was the complexity of the compiler, and Intel never managed to create a compiler that was fully able to extract the theoretical benefits of EPIC.

While Intel had announced the discontinuation of Itanium years ago, its eventual demise came quietly, and would have gone mostly unnoticed had not publications such as TechSpot announced it. Most comments were not exactly kind to Itanium, as we can see here: Intel's Itanium is finally dead. To a large degree, that criticism is well-deserved, but Intel certainly deserves some credit to introduce a new processor architecture in which parallelization was done in an unconventional way.

While some put the blame on the lack of compatibility to legacy x86 (yes, the 32-bit version, not x86-64) software, I don't think that this is correct. Had Itanium shown better performance in native mode over any other processor or over the emulated x86 code, then I am fairly certain that Itanium would have succeeded despite using a different ISA. But it never did. I think that both the price point and the performance (or lack thereof) had to do with its demise. In the end, only HPE used Itanium - and for a good reason.

Rest in Peace, Itanium, and hopefully with EPIC at your side. We will bury you next to SPARC.

HPC is not an easy topic to explain. I frequently encounter people asking me what I do. Here is a brilliant article outlining what HPC has been able to do for humankind lately, and that article is only focusing on 6 applications that saved lives and make our world a better place.

In the past few weeks, there were lots of news about GlobalFoundries. One rumor stated it was going to be acquired by Intel. The Wall Street Journal reported on it here: Intel Is in Talks to Buy GlobalFoundries for About $30 Billion. Forbes tried to find a good reason for this acquisition in Intel’s Possible Rationale For Buying GlobalFoundries, Inc., and even The Next Platform was not quite sure if the idea was that great. Another Crazy Idea: Intel Might Buy Globalfoundries is not exactly an endorsement.

Its CEO Tom Caulfield responded nearly instantaneously here: CEO of ex-AMD fab GlobalFoundries shoots down Intel buyout and stated that it was planning on an initial public offering (IPO). My opinion is that very simply, GloFo is not set up for an IPO. GlobalFoundries was created by spinning off the former AMD chip manufacturing unit, and over time it added more and more fabs to the portfolio, including the former IBM Microelectronics. They all used specialty processes, and they had to be integrated with each other. In the process of doing so, it lost sight of the need to perpetually improve. GlobalFoundries was left with an embarrassing acknowledgment that it would not pursue any process nodes beyond 10 nm. While that is a FinFET process, and it has licensed Silicon-on-Insulator (SoI) from ST Micro (and later on from Samsung), it is not a leading supplier for the manufacturing of processors and accelerators. In essence, it now has planar transistor processes, one or two SoI processes, and one or two different FinFET processes. I do not see that they can support their customers with Process Development Kits (PDKs) with the current level of revenue. Simply put, trailing process nodes command commodity pricing.

Everything old is new again. The first supercomputers were machines that were very different and distinct from any regular computer. They were different from minicomputers, mainframes and from PCs. At that time, internal interconnects were vastly faster (bandwidth and latency) than anything a network could offer, so compute and storage were in the same machines. A supercomputer would contain not only the compute subsystem, but also the storage subsystem. The same applied to minicomputers and PCs.

Then, it turned out that more bang for the buck could be had by not building dedicated and special-purpose supercomputers. Instead industry standard servers were used to create a supercomputer. They were just regular PC-based servers connected via the fastest interconnects that could be had. That worked out well for a while, but disks were very slow, and tapes even slower. Since data management was needed, and that alone was computationally moderately intensive, storage management was put as software onto industry-standard servers to take over all storage management tasks, and so the storage appliance was born. This allowed supercomputers to be logically divided into two different classes of computers: the compute clusters and the storage clusters. Compute clusters focused on compute (i.e. lots of CPUs and accelerators and memory), and the storage appliances in the storage clusters took over all storage tasks, including snapshots, deduplication, tape operations, backup and restore and of course disk caching. Doing so cut down on cost while improving performance. It worked well for as long as the network was faster than cached disk I/O. The advent of Flash in the form of SAS- or SATA-attached SSDs started to change this. PCIe-attached storage provided level of performance that network-attached storage simply could not match any more. PCIe Gen3 in the 16-lanes variant tops out at less than 16 GB/s, and so that is the limit that can be achieved using PCIe-attached Flash or network-attached storage. As a result, all high-performance storage was pulled back into the compute nodes, and only the nearline and offline data storage on SATA disks and tape as a backup is now left on storage appliances. In essence, what used to be a performance-enhancing technology now has become simply a bulk storage and backup/restore technology, possibly with features for deduplication. This has now caused a simple convergence of compute and performance-oriented storage, creating the hyperconverged server.

Multiple media organizations including Heise in Germany have reported that China (more specifically the Institute of Computing Technology at the Chinese Academy of Sciences or ICT CAS) has built a high-performance RISC-V core. Even The Register reported on this, under the headline “Chinese chip designers hope to topple Arm's Cortex-A76 with XiangShan RISC-V design”.

The processor is named XiangShan, and ICT CAS faculty have posted its entire CHISEL/Scala source code on GitHub. There is also a fair amount of documentation, some of it in English, and a few schematics and block diagrams that go with the basic architecture. I have not had time to synthesize the processor and verify the performance (that will take me a while anyway), but from the text and the schematics the claims of the performance make sense. It is an out-of-order design. The pipeline depth of 11 stages seems to be confirmed by the documentation and the schematics, and so is its six-issue width. It seems to rely on 4 DDR DRAM Controllers, and I am still trying to find out if the DRAM Controllers are part of the design. In the original SiFive and UC Berkeley designs, the DRAM Controller is not included.

Without knowing anything about the DDR DRAM Controllers, it is hard to estimate what the performance is going to be. After all, most modern CPUs outperform their memories, and therefore the caching strategies (Cache types and hierarchies and Cache Controllers) and the DRAM Controllers are an integral part of a processor's performance.

If the DRAM Controllers are not part of the design, then commercially available DRAM Controller from Synopsys or Rambus (ex NorthWest Logic) can be used. However, that takes away part of the open source design, as without the DRAM Controllers, the chip cannot be finished. I am also still looking for the PCIe Gen3 Controller with the 4-lane interface, and I have not yet found it in the source code. Having just finished the design of a PCIe Gen3 Endpoint Controller with the 4-lane interface I can say that this is not a trivial undertaking, but again, if this is not part of the open source and it has to be sourced from a commercial entity, then most core components of this chip are open sourced, but not the whole design.

Either way, if in fact the ICT CAS taped this chip out at TSMC on a 28 nm node, then a maximum clock frequency of 1.2 to 1.3 GHz is believable. If that was the target node and if ICT CAS used the Synopsys DDR4 DRAM Controllers, then I have a hard time believing that this processor achieves the ARM Cortex A76 level of performance. Considering the more complex ISA of the ARM processor with more compound instructions and its higher clock frequency, I’d think that the XiangShan processor is probably at the 60 – 70% of performance level of the Cortex A76. It nevertheless is an extraordinary achievement from the ICT CAS team. I do not want to take away anything from their impressive achievements, and considering the learning curve, I’d wager that it won’t be long, and they'll outperform the ARM family in per-core and per-processor performance metrics. However, like ARM, they have not solved the underlying problem of scalability.

Looking up the meaning of Xiang Shan comes back as Fragrance Hill, a hill near Beijing. I am not sure if there is a deeper meaning behind this code name other than mimicking Intel’s use of lakes as code names for their processors.

It looks like Steve Wozniak has commented on the Right to Repair. When Steve talks, I usually listen. I agree that he has a point as the repair of a device if oftentimes economically and ecologically advantageous. It does not make sense to throw away a device that is repairable when and if a non-crucial component is damaged. The question then is what is a non-crucial component, and when should a device be deemed non-repairable because the repair has an impact on whether we trust the repaired device to keep secrets the same way that the original device did.

After all, for many of us, the phone has become the holder of all of our secrets – bank accounts, passwords, social security number, cashless payment system info, birthdays, fingerprint or iris scans and so on. We inherently trust Apple and Samsung, Qualcomm and a few other companies that supply the mainstream phone manufacturers because they have an established supply chain that is thoroughly vetted and continually monitored for compliance with applicable laws and additional policies imposed by the phone manufacturer.

Let me use an analogy to highlight where the issue lies. Let’s say your Mercedes is involved in a fender-bender. Only the right front fender, which is bolted on and has no impact whatsoever on anything in a subsequent crash, is damaged. You would not throw away the car because the fender is bent. You’d repair the car, and you might chose to use an aftermarket fender that is cheaper. While it may rust through ten years down the road, possibly earlier than OEM would have, there is no impact on the safety of the car itself, its value, or its longevity. If a crucial part of the car is damaged, such as the components that make up the safety cell, it is usually deemed non-repairable because in a subsequent accident, the car might not protect you.

The same applies to the phone. If a socket, a switch or the display get damaged, repairs are and should always be possible and feasible. Same for the battery.

Now if the CPU or the security processor needs to be replaced, I would deem that non-repairable by a 3rd party. Why? As stated above, Apple and Samsung and other established phone manufacturers have a supply chain that is well controlled. If you bring your phone with the dead CPU or security processor to shadytreephonerepairs.com, which sources the security processor from insecurityprocessors.com and the firmware for it – to resemble something like a working security processor – comes from backdoorfirmware.com, then I’d question if the prior level of trust in the phone to keep things private can be re-established.

If trusted and trustworthy 3rd party repair companies exist that have a supply chain that is similar to the OEMs, then that is a different story, but history has shown that that is not always the case. The danger of knowingly or unknowingly using counterfeit parts always exists if the supply chain is not clear.

Louis Rossman, who runs the non-profit Repair Preservation Group Action Fund, has shown in many of his videos on Youtube that manufacturers’ repairs (or attempts thereof) are not necessarily always successful or even state of the art, but at least they use the same components as the OEM, coming from the same supply chain.

What is my take? I support the Right to Repair movement and think it makes sense. However, some provisions have to be made to either limit that right if crucial components are affected, or to help establish 3rd party repair companies with a supply chain and associated quality standards and a guarantee from that company to the user that OEM parts are used. Those limits must be made very clear so that there is no confusion over the components that are excluded from the Right to Repair bill. For example, everything that is on an export control list must be excluded from the Right to Repair provisions. Enforcing the compliance with these regulations will not be trivial. I guess that the laws encompassing the Right to Repair will have to be very strict and detailed, and they will have to reference or include many other and secondary laws, and as such making the repair industry compliant could be the economic nail in the coffin for many devices that were initially targeted by the proposed Right to Repair laws.

As a result of my postings with regards to the supply chain attacks against SolarWinds and Kaseya I have been asked what I think of VPNs (Virtual Private Networks) to fend off some of the threats. We will analyze that.

I think the term VPN has been misused lately, so I’d like to clear up what it is, and how the different types of VPNs compare. While we are at it, I’ll throw in TOR as well.

VPNs have been around for a while, and they protect data-in-transit. The traditional understanding of VPNs is that they span a Virtual Private Network across the planet, and they use the Internet as a transport medium. A VPN will “tunnel” through the Internet. It does that by encrypting the traffic between the endpoints after having authenticated them. Companies started using VPNs as a means to connect remote workers to a central office. These types of VPNs worked well as they made the contents of the VPN that tunneled through the Internet invisible to any attacker. Any attacker was only able to identify the two endpoints of the communication, but it was and is impossible to see the payload (the contents of the communication). The VPN endpoint usually was the employee’s computer or a VPN-capable firewall at the employee’s home office. It did not matter where on the planet the employee was, he or she could log into the company’s network and computers and server as if he or she was in the office.

A very similar type of VPN was used between two or more branch offices of a company. That made it possible to transmit secret messages between branch offices and remote workers without the risk of someone snooping or inserting unauthorized contents. In those applications, firewalls were deployed that acted as VPN termination points. Each branch office had to use VPN firewalls to participate in the secure communication. They had to be set up properly with the encryption type, a pre-shared key, and the appropriate methods for authentication (for both the phase 1 and phase 2 negotiations).

It is important to mention that both of these types of VPNs are end-to-end connections with end-to-end encryption. Typically they use a protocol called IPSec, which allows for a persistent connection. This is in contrast to SSL and TLS, which are transient connections and tunnels.

To my knowledge, VPNs were never successfully breached for as long as they were set up properly. The problem with these VPNs was largely that it was difficult to set up, and that interoperability was not great. Cisco gear did not want to communicate with Juniper gear, and others did not fare much better either. The biggest challenge though was the implicit assumption that all endpoints were secured and free of malware. In essence, the VPN treated all endpoints as if they were local resources on the internal company LAN. That assumption was oftentimes proven wrong. Particularly on computers that were bought and administered by the employees (“BYOD”, or Bring Your Own Device policies), the trust put into these devices was misplaced. Any malware and worm that was capable of spreading within a LAN was capable of traversing the VPN, and so VPN-attached endpoints had to be considered about as safe as any device on a DMZ or De-Militarized Zone. As a result, malware scanners in the firewalls were made necessary for all VPN endpoints. That additional policing and filtering took away many benefits of the VPNs, and as a result, VPNs were abandoned by many companies.

We would advocate for the continued use of VPNs if possible, particularly from a security and performance standpoint. As a result, we have implemented a smart NIC in our Server-on-a-Chip that executes all necessary functions for packet filtering, encryption and decryption as well as authentication independent of the application processor cores. To make it clear, VPNs and packet filtering alone will not stop infiltration or exfiltration of data caused by supply chain attacks as those are directed against the server infrastructure itself, but with VPNs and filtering and authentication as well as with code signing the likelihood of another supply chain attack against an IT infrastructure software provider can be minimized.

The term VPN has been taken up by a new crop of companies promising better Internet security. Let’s see if that holds up to scrutiny. Most Internet users are connected to the Internet through their Internet Service Provider, or ISP. This can be DSL if your carrier uses phone lines, cable if your ISP uses coax cable for TV and data, or glass fiber if your provider uses Fiber to the Home (FTTH) or Fiber to the Curb (FTTC) and a secondary fiber from the curbside unit to the home. In either case, all of your traffic goes through your ISP. Your ISP can therefore monitor and observe all your traffic, including but not limited to your DNS (Domain Name System) traffic. The DNS infrastructure is a very important part of the Internet, and it resolves the symbolic name you type into your browsers’ address bar into an address that networking devices understand. While you type NYT.COM, your computer does not know what that is. Neither does your Internet access device, but it will ask the nearest or pre-configured DNS server what that is in IPv4 or IPv6 language. The DNS server will resolve this and report back 199.181.173.179, which is a public IPv4 address. Your computer’s browser can now establish a connection with NYT.COM under that IP address. Since your ISP has access to all of this traffic, your ISP knows which web sites you visit. If some of them are less than clean, your ISP will know that. VPN services have understood that and offer a solution to this. If you sign up to them, they will send you credentials for a VPN endpoint setup, and if you configure your PC, wireless router or LAN router with these credentials, then the traffic between you and their ingress router will be encrypted. In other words, they obscure your traffic and the ISP cannot monitor it. However, since your VPN is terminated at the ingress side of the VPN services’ router, and since your ISP cannot provide DNS services to you, the VPN provider will resolve all DNS queries, and then forward and route your traffic accordingly. In simple terms, your VPN provider now has the technical ability and in some jurisdictions the mandate to collect your traffic and your metadata (your IP address and the IP address of all of the web sites you visit). In reality, you have not gained any privacy or security. You have shifted the data collection from your ISP to your VPN provider.

This is very similar to TOR, short for The Onion Router. TOR was and is a special version of the corporate version of Firefox. TOR searches for other TOR users that have published their involvement and participation in a secret database, and it will then use a number of other TOR users as if they were a VPN service provider, while making sure that the traffic between you and the next TOR user is encrypted. Your traffic will in essence go through your ISP fully encrypted, and it will use a TOR user as an entry and entry point into the Internet. TOR actually uses multiple hierarchies of VPN tunnels so that TOR users and TOR exit points are not easily identifiable and traceable, but it is not 100% bulletproof as an analysis of delays can render enough data on how many layers of encryption and how many TOR users are in the chain to ultimately crack it and pinpoint the true endpoint of the traffic.

TOR was originally developed by the CIA to allow whistleblowers all around the world to send secure messages to the CIA without exposing the source to anyone outside of the CIA. An analysis of the code of TOR revealed a whole lot of measures that were taken to protect the whistleblower, but also plenty of vulnerabilities of the concept, including a phone-home provision. As one would expect, the author of this used TOR after having removed the phone-home provision, and experimented with the browser and its concealment provisions. Today, TOR is mostly used to access the Dark Web. That is a theme for a different discussion and blog post.

It seems like there is no letting up on ransomware attacks. Axios reports that Kaseya hackers demand $70 million in massive ransomware attack. This appears to be yet another supply chain attack. A supply chain attack is an attack that is directed at a company that provides IT infrastructure management tools. A fraudulent piece of software is inserted into this management tool or toolset. Usually, this piece opens up a backdoor by which the attackers can access every user of the management toolset. Since the tools has administrative privilege, it can do anything it wants. In the case of ransomware attacks, the attackers encrypt the server(s) contents to a key of a keypair only they know. If the attacks are noticed in time (i.e., before the last valid and unencrypted backup is overwritten by an encrypted one), then all it takes is to disable the IT management tool and restore the prior, most recent valid backup. In that case, only the data that was generated between the most recent valid backup and the time of the breach notification is lost. Restoring a backup also takes quite some time, so the business will be interrupted for a while. This is not a desirable situation to be in, but it is better than having to pay a ransom and hope that the criminals behind this attack release a valid decryption key. In my opinion, paying a ransom should be made illegal to avoid making ransomware attackers commercially successful.

We also need to think about additional levels of administrative privilege. Today, there is the admin (or root) and the ordinary user. This needs to be amended. There need to be admins and super-admins that administer certain rights and enable and disable admins, install firmware updates and updates to the OS kernel. Admins should then be restricted to administering users and applications above the OS level. Users should only have the right to store and retrieve data and use applications installed by admins. Very limited privileges for code execution should be granted. Limited users should only be able to store and retrieve data, without any rights to initiate any code execution. In those scenarios, IT management tools only have admin privilege, and so bulk encryption cannot be initiated. For firmware and OS kernel updates and changes, the tools must require elevation to super-admin privilege levels, and that will require additional authentication. As an industry, we might also have to rethink hardware, firmware and OS kernel security. Ultimately, we might also have to rethink the current approach of data-in-transit and the data-at-rest paradigm.

Here is a scenario I’d like you to consider.

Imagine that you need to transport large amounts of cash from A to B. Obviously, since cash has value, you’d like to protect the transport. So you build a transport van that protects the payload. The drivers are in an unprotected cabin. Does that make sense to you?

Similarly, once you arrive at the bank, the vault is pretty safe, but the tellers are unprotected. Does that make sense to you?

Well, that is exactly what we see in Internet security. There is a focus on data-at-rest and on data-in-transit. What’s not protected is the whole set of devices storing the data (even though the data may be on disks that are encrypted) and the whole set of devices that transport the data from A to B. In other words, Internet security focuses on protecting the payload. It does not make sure that the devices that transport and store the data are equally well safeguarded.

That is what Abacus Semiconductor is doing. Besides being a high-performance solution with our Server-on-a-Chip and our intelligent memory subsystem, we protect the device that protects the data-in-transit and the data-at-rest. With those measures in place, we might be able to stem the tide of ransomware attacks.

This Fourth of July marks the 245th birthday of the United States. It gained its independence from the British in 1776. In five years, it will turn 250 years old. Not all democracies in the history of humankind have survived nearly a quarter of a millenium. Let's hope that the US democracy is going to be in a much stronger and better position then.

It looks like Intel has submitted a bid for SiFive, the commercialization entity for the RISC-V processor and ISA. According to Tom's Hardware and Bloomberg, Intel Offers $2 Billion for RISC-V Chip Startup SiFive.

This would be a validation not only of RISC-V, but also of the ecosystem around it. I doubt that Intel would make that acquisition to shut down RISC-V as SiFive is not the RISC-V steering committee but merely the commercialization branch of RISC-V. This appears like a genuine approach of Intel to diversify into non-x86-64 processors. While SiFive has a focus on embedded systems and therefore can help Intel fend off ARM in those areas, I believe that this might signal the end of x86-64, and now puts pressure on AMD. This was a brilliant move, because as I have mentioned in my blog multiple times (FTC opens probe into nVidia and ARM merger, nVidia and ARM merger hits roadbumps, Apple and ARM and nVidia buying ARM), ARM will cease to be independent when the ARM acquisition by nVidia goes through. ARM will be under control of nVidia.

That means that all ARM architecture licensees will feel the heat from nVidia. Why does it matter? ARM architecture licensees are multi-trillion $ companies:

• Apple
• Qualcomm
• Broadcom
• Samsung
• NXP etc

All of these companies will have to decide if they want to stick with nVidia/ARM or switch over to RISC-V.

RISC-V is an open Instruction Set Architecture and can be implemented by anyone. If need be, anyone can buy RISC-V processor designs from SiFive and in the future from Intel - or from us. We have been using RISC-V since about 2012 and have experience with it.

We are the only company that has developed extensions to RISC-V for performance, security and scalability, and we have added hardware support for virtualization.

That makes us the only company that can get RISC-V into the server and internet backend.

Software design is not quite as robust and structured as hardware design. Nevertheless, even in ASIC and processor design sometimes bugs slip through the cracks, and they create problems that can be exploited. We have seen that with Spectre and Meltdown, both of which which exploit an issue with out-of-order execution in conjunction with caching strategies. While Intel and AMD have issued patches, the problem is not fully solved, and users report performance degradation after applying the patches. Other hardware-related vulnerabilities such as Rowhammer and Half-Double make use of knowledge of the physical characteristics in DRAM, and I am fairly certain similar exploits can be devised for Flash. These exploits rely on side effects of mechanisms that were intended to improve processor and memory performance, and they were not foreseeable by the designers of the processors and memories. Nevertheless, they are devastating in their effect. I am certain that security will be one of the more important design considerations for the next generation of processors and memories. We have taken those vulnerabilities into account and have made sure that our processors and intelligent memory subsystems do not exhibit them.

SiFive claims that it has taped out a 5 nm TSMC-produced HPC and AI capable processor in its press release here: SiFive RISC-V Proven in 5nm Silicon. In a lot of ways, that is great news as it proves that RISC-V is fully capable of supporting HPC. However, as I have said many times before, the ISA does not matter. Being successful at running HPC workloads breaks down to how accelerators are included, and how memory is attached. My prior blog post ISA versus System Architecture points out what the fallacies are. We believe that there are many more things to HPC than just a CPU made on a 5 nm TSMC process.

Vice reports that Hacking Startup 'Azimuth Security' Unlocked the San Bernardino iPhone. That's not too surprising as the prior suspect did not seem to have the wherewithals to do so. According to the article, "Motherboard can confirm a Washington Post report that said Azimuth Security developed the tool used on the San Bernardino iPhone".

Let me quote some more from the article because I think that particularly the last paragraph is of importance: "Shortly after the FBI successfully accessed the phone, rumours circulated, originating with a single Israeli press report, that established phone-cracking company Cellebrite was behind the hack. Those reports were unsubstantiated, though. After unlocking the device, the FBI found no previously unknown message data or contacts."

Why is that important? The investigators had all of the information they ever needed without cracking the phone or without having access to the encrypted communication (and neither did they need a secret backdoor). All they needed was the metadata - and I had stated that many times. There is no reason whatsoever to try to outlaw strong encryption. See my older post on this here: DOJ on Encryption.

Gizmodo reports that U.S. Federal Investigators Are Reportedly Looking Into Codecov Security Breach, Undetected for Months.

This is another supply chain attack, similar to the one used in what is called the SolarWinds breach. In this case, the attackers appear to have been able to gain access to a system that allows users to upload software to be tested onto a test server, and while that does not sound dangerous, the attackers likely were able to either extract user credentials directly, or added a backdoor that would send them the credentials of anyone who logged in.

If that is the case, then the number of affected users is greater than the 29000 users mentioned. This is in fact dangerous as it balloons. It might not seem obvious, but like with the SolarWinds hack, the direct damage is bad, but the indirect damage is worse. Let's say that a Microsoft super admin's credentials were obtained in the SolarWinds hack, and the admin changed credentials. He or she wanted to make sure that not only new credentials were used, but that the software was updated as well - including MS Exchange and its cloud equivalent. So far the admin did everything right - change credentials and make sure that known vulnerabilities in the software are fixed. Now this admin submits the new code with the new credentials to be tested only to later find out that someone stole his or her new credentials during the upload for 3rd party verification of curing the bugs... This is about as bad as it gets.

For the SolarWinds attack itself, there is plenty of updates and news, such as NPR summarizing it and updating it with some new info, and of course the Biden administration imposing sanctions on the perpetrators of the hack in the following Bloomberg article Biden Sanctions Russia, Restricts Buying New Debt After Hacking but at the same time trying to de-escalate the situation in Biden calls for de-escalation with Russia following sanctions, proposes meeting with Putin.

It looks like there is some new life in semiconductor companies and in funding for them. It was about time as I fundamentally disagree with the notion I have heard at least one too many times that we have invented all that there is to invent. Current CPUs and all GPGPUs combined do not solve many computationally intensive problems effectively and efficiently. Certainly Cerebras made a splash here, and that is a great sign. The Next Platform reports that national labs are working on the Neocortex Supercomputer to Put Cerebras CS-1 to the Test.

I completely agree that novel solutions to novel computational problems must be found, designed and funded. AI and ML training certainly qualify, but there are plenty of other unsolved problems that do not require wafer-scale compute. While Cerebras and we have different approaches to different problems, I am encouraged to see that funding and the willingness to try out new solutions are available again.

For way too long have analysts and VCs focused on CPUs and GPUs only. It seems that CPUs have settled on x86-64, ARM and RISC-V, and within the GPGPU category nVidia is leading the pack due to CUDA, but DSPs and vision processors for industrial and automotive real-time control applications, security processors and math processors as well as large-scale integer-only database processors are needed to fill the gaps that CPUs and GPGPUs cannot fill.

ARM has released a new version of its processors and instruction sets. They hope that with this processor and ISA they can compete better and more effectively with Intel, AMD and all others in the Internet backend and in the data center. Whether that ISA or processor actually can achieve what some publications claim remains to be seen, as we can read here on CNET, stating Arm's new chip architecture boosts security, speed for billions of processors or here at Bloomberg with the headline Arm Takes Aim at Intel Chips in Biggest Tech Overhaul in Decade.

As far as I can tell from the announcements and the available technical literature, ARM does what Intel and AMD have been doing, and there is really no difference in the approach: improve the number of instructions executed per cycle, and adding instructions to the ISA. Both measures increase the complexity of the cores, add to the size and power consumption, and require ever-more sophisticated caching strategies along with a required increase in cache size. I wonder if that approach is the right one to take. Particularly in light of more processor and OS modes, the attack surface will only grow with an increase in permitted instructions of the ISA.

It looks like the IT world has to deal again with the longest-living undead that I can think of, and that is the entire UNIX copyright saga around AT&T and SCO/Novell and now Xinuos - what a creative name. An anagram of UNIX appended by the abbreviation of Operating System as a company name. Clever. Not so clever is the fact that the Fear, Uncertainty and Doubt (FUD) has re-emerged, and threats of lawsuits against UNIX users are back. ZDNet has a great overview of this story here: SCO Linux FUD returns from the dead.

The Register has an equally good overview of the background and some of its implications here: IBM, Red Hat face copyright, antitrust lawsuit from SCO Group successor Xinuos. I wonder when this is finally settled in court or through the passage of time. I am getting pretty sick of this kind of use of the legal system. Certainly patents and other IP should be protected, and the prevailing party should have the rights to the proceeds, but patent trolls and re-litigating cases that have already been decided or settled only clog up the judicial system for the legitimate cases.

Well, now here is a blast from the past, and it is even incredibly well-written: DMA. That is one of the many battles most processor and SoC designer face. There are two camps, one usually consisting of the software designers. They want to do everything in software, from polling instead of IRQs to memcopy and transferring data to and from peripherals. The hardware camp is usually of the opinion that everything should be done in hardware, so they advocate for IRQs and all data transfer for I/O executed by a DMA Controller (or its more advanced cousin, the IOMMU). After seeing that IRQs and traps and exception handlers are all now treated the same, I am firmly in the camp of hardware support. Therefore, the article came at just the right time. It takes less energy to have I/O (and even memory-to-memory) transfers executed by a DMA Controller. It is faster, it can be made more secure, and it is more reliable. It has very few, if any, downsides. The complexity of a multi-channel DMA Controller or even an IOMMU is so low that omitting it will not substantially impact the die size of a processor or SoC or even a microcontroller.

We have been designing and using DMA Controllers and IOMMUs for a long time as there is simply no substitute for simplicity, performance, security and power savings while at the same time allowing concurrent operation between the DMA Controller/IOMMU and the CPU.

As chip designers and as IT admins, as users and as ordinary citizens we have probably intuitively sensed that cybercrime is on an upwards trajectory. The US CISA has statistics on the number of cybercrimes committed, and even looking at the number of CVEs filed on MITRE.org or the overview complied at SANS.org, it is pretty clear that cybercrime is not going away, but instead growing. CNET compiled the numbers, and they are staggering: Cybercrime in the US jumped by 55% in the past two years. The annual loss reached $4.2 billion in 2020.

In other words, cybercrime has reached a magnitude that requires all of us to take it seriously, and more importantly, will require us to take action. Security - and particularly cybersecurity - is not a spectator sport. We all have to proactively do something to protect us. Using a secure browser on a secure operating system, with passwords that are long enough and are not reused across many sites are a good start. Then contemplate using a hardware firewall - maybe there is one already built into your wireless access point or your cable or DSL modem. Learn how to configure and use them. Practice some digital hygiene. Not everything has to be posted on Facebook or Instagram or whatever other social media there is..

ArsTechnica reports that hackers that were exposed by Google and Microsoft have reacted with classical counter-warfare by targeting those that exposed them. ArsTechnica states that North Korean hackers return, target infosec researchers in new operation. That is not too surprising, but in essence this is quite an escalation of severity. However, not only did they escalate, but they also set up a fake web site purporting to be a security company with a keen focus on research for digital security.

CNN reports that Russian hackers did the same to those that exposed them in connection with the SolarWinds breach. According to CNN, Hunting the hunters: How Russian hackers targeted US cyber first responders in SolarWinds breach, Russian hackers directly targeted these researchers. Again, a very classic counter-warfare operation.

That means that even more so than before, everyone - including security researchers - have to be very careful when sharing zero-day attacks, vulnerabilities, novel exploits or any kind of security holes even in procedures and processes. At this point in time it seems as if the Western democracies do not fight back hard enough. While the US has offensive cyber warfare capabilities, it seems like the US is more on the receiving end of cyber warfare. Unfortunately, there is no global legal framework in place that is agreed upon and can be used to determine who the perpetrator was, and what the penalties are. On top of that, if the cyber warfare program is a state-run effort, it is hard to believe that the states that conducted these attacks will agree to any kind of extradiction in any treaties.

I have been warning for a while that firmware and the boot process are not as secure as they could have been made. Firmware updates can be executed unauthenticated, and with physical access to a device modification of firmware is borderline trivial. All of that poses a danger, and I have mentioned it multiple times. In each of my blogposts about Pre-Boot Security, Security in the News, Newsmax rehashing debunked stories and Resilient Secure Boot have I pointed out that the firmware attacks are the most malicious ones as they cannot be detected from a running OS or by any malware scanner.

On top of that, firmware controls the basic behavior of the system itself and of all of its embedded components. As far as I know, there is no malware scanner for the embedded controller in hard disks, SSDs, RAID Controllers, SAS or SATA Controllers, or LAN network interface cards, smart NICs and wireless LAN (WLAN/WiFi) Controllers - and the keyboard, the mouse and touchpad/trackpad. Even the GPU has its own firmware, and I have yet to see a scanner for malware on GPUs. As a result, I completely agree with Microsoft's assessment that Firmware attacks are on the rise and you aren't worrying about them enough.

There are more reports on 3D XP, and more in-depth information becomes available on why Micron to decided halt development of 3D XPoint and sell its Flash Memory Fab. Apparently, there was not enough demand to even load one fab fully. That is not entirely consistent with a prior statement saying that Micron was unable to scale out production. The only way both statements can be true at the same time is that scaling out production was so expensive or technically challenging that Micron gave Intel for its Optane memory an upper limit of what can be produced, and even if Intel absorbed all of it, it was not enough to fully utilize the Utah fab for this product. That would be a truly sad ending for a once promising technology. In my earlier blog post about 3D XPoint Memory Discontinued I assumed that in fact Micron was unable to scale out production of 3D XP and as a result was unable to make this technology self-sustaining. The lack of demand surprised me.

In essence, it means that everyone needs to go back to the drawing board for a successor to Flash. While Flash has improved drastically, the fact that we need to deal with wear is somewhat problematic, but the biggest downfall is the write performance. In essence, the industry is still stuck on the growing performance discrepancy between processors, DRAM and Flash. I had hoped that 3D XP or more generally Phase Change Memory would have taken over from Flash as the leading memory type for density. Had that been the case, we could have expected DRAM manufacturers to focus more on performance instead of density, and created a lower-latency DRAM main memory. Unfortunately, that did not happen.

Booting up a computer has not changed in over 30 years. While the TPM and a few other improvements were invented along the way, essentially any computer today boots the same way a 30 or 40 year old machine did. The only difference fundamentally is that way back then, computers booted out of a ROM, an EPROM or an EEPROM, which was essentially unchangeable via software. While that made it impossible for attackers to insert malicious code into the boot (or pre-boot) environment, it also prevented easy updates to the firmware to fix bugs. Over time, the pre-boot environment became more important as the boot code itself grew in size. With more and more of the firmware migrating to EFI/UEFI, the pre-boot environment has taken over what used to be the initial startup, and it is unprotected. I had designed a novel pre-boot environment with primary focus on security and resilience, and I am glad to see that this is seen as a pressing issue today. Proof of that is that an increasing number of companies focus on pre-boot security, such as Lattice Semiconductor. While we are doing our part, we need the industry to come up with solutions that universally work, and that can be standardized and evaluated in their attained level of security and resilience.

Once that is achieved, the industry will need to develop more stringent tests for security and resilience in pre-boot and boot environments, and that will have to include both hardware and firmware to withstand and log all evidence of attacks.

Attack vectors will have to include those that assume physical access to or possession of the device under attack. After all, with intelligence pushed out to the edge like for 5G, we will see many more devices at the edge in physically not very secure enclosures, and that will make these devices much more vulnerable to snooping, denial of service attacks and theft with the intention to steal keys.

Years ago, Intel and Micron had set out to develop a new kind of memory. It had to be faster than Flash and denser than DRAM. It was also supposed to not show wear and degradation. They called it 3D CrossPoint, or short, 3D XP. It was Phase Change Memory, but if you called it that, Intel got upset. I thought that the approach was genuinely good and novel and worthwhile, but Intel lost interest a while ago, so Micron took it all over. Unfortunately, Micron could not create a large-scale production-worthy version of it, and as a result, it was canceled altogether. That's really a loss as I think that it could have been the missing link between Flash and DRAM. While I had assumed for while that it would not see commercial use, the announcement at The Next Platform came as a surprise, and it now necessitates that the industry rethinks what the new memory type between DRAM and Flash with regards to their density, latency and bandwidth should be.

I would have liked to see some new form of memory in that gap, but it seems that we may have to revert to what Abacus Semi is doing and what its HRAM will show in terms of performance, density and of course the price point.

You know that things are bad when CISA releases a new SolarWinds malicious activity detection tool. While it is great that the community now has one more tool in its toolchest to detect if a breach occurred, it means that most CIOs and CISOs don't even know if they have been breached, and if so, to which degree data was exfiltrated. That is a complete and utter disaster.

The more we learn about the SolarWinds breach, the more it becomes clear that its impact has been vastly underestimated. I think it may have a lasting effect for all software vendors, and that includes open source and closed source. As far as I can tell, it might also undermine trust in cloud services and online tools such as Office365 and similar or equivalent solutions.

Unleashing the true potential of massively parallel compute solutions is a system architecture decision, not a result of using better process nodes. We do not have to rely on Moore's Law.

We are not banking on Moore's Law alone to improve computer and processor performance. Intel, AMD and all ARM licensees can do that just fine, and that is not the major point of criticism of the status quo we have. Any processor designer can probably improve on the performance of any given processor - with or without Moore's Law. What we are saying is that ganging up many processors does not work well enough to provide linear scaling of performance across a broad range of computational problems. In other words, 10,000 cores in a Linux cluster will not solve a computational problem 10,000 times faster than one core. Why is that? Very simply processor design has been too successful over the past 20 years. The discrepancy between processors, accelerators and memory has only grown in the past 20 years. That now demands a fairly coarse granularity of tasks, and that is counterproductive. What do we mean by that? If a processor core works on a task that would take it 10,000 CPU cycles to complete, and we have 100 cores available, then distributing the task onto the 100 cores should allow all of the cores to complete the entire task in 100 cycles as we have parallelized the problem. So ideally, we have 100 times the core count, and 1/100th of the execution time. That would be ideal linear scaling. The problem is that it does not work that way.

First of all, we face the problem that we need to chop the big problem into 100 chunks. Then we need to verify that there are no dependencies among the chunks. The first part will likely take 100 cycles all by itself, on one core. The second part can be parallelized, but it adds to the total complexity of the problem. So let's say we either ignore the verification of interdependencies, and let the cores figure it out once they work on the problem. We still have to distribute the chunks. That will take a fixed but fairly large amount of time as we have to share the data and instructions across cores in a cluster within a CPU, then across CPUs, and then across computers to other CPUs and cores. This will consume 10s to 1000s of cycles, and we have not worked on the parallelized problem yet - only on chopping up the task and distributing it. Once fully distributed, the cores work on the problem for about 100 of their cycles, and then send the results back. Now the initial scheduling core will take in the results and consolidate them. It is in the realm of possibilities that all of this overhead will cause the result to be ready after about 10,000 cycles on the CPU core that tried to farm out the problem to accelerate processing. In other words, we have not saved any time. Instead, we have kept many more cores busy, used the CPU-internal resources, the network and a whole lot of other infrastructure without gaining anything. The reason for this is simply that cores process data much faster today than they did 20 years ago, but memory has not sped to the same degree, and while network bandwidth increased dramatically, the latency (the delay) has become worse. As a result, it does not make sense to farm out small tasks of 10,000 or 100,000 cycles. The granularity of tasks that can and should be farmed out has gone up drastically, and as a result, it has become very coarse. Fine-grained granularity only makes sense across adjacent cores like the ones in a ccNUMA system, or across cores in a coherency domain.

What needs to happen is that core processing performance, inter-processor communication and memory bandwidth have to be re-balanced to allow for reasonably fine-grained granularity of tasks to be parallelized. That is what we are doing, and that is where our unique selling point lies. If your computational problem can be solved in one core or one processor, we will not be the solution for you. If your computational problem is big enough to keep millions of cores busy, we are the right partner.

It was only a matter of time. Spectre and Meltdown are vulnerabilities that so far had only shown the risk of thoretical exploits, but none in the wild. That has now changed. The Record claims that the First Fully Weaponized Spectre Exploit Was Discovered Online. In essence, that means that a non-fixable hardware feature has been exploited by real-life malware. With that attack now being a blueprint for others, more malicious attacks will be carried out against processors for which no hardware fix is possible, and the firmware fix is not only reducing performance, it does not guarantee that the system is not vulnerable any more.

That is about the worst case scenario imaginable. Protecting against an entire class of attacks is going to be necessary, but how that is going to be done is unclear to me. I am not sure if firewall rules can even be written to detect such attacks.

I have criticized SIMD ("Single Instruction, Multiple Data") architectures for quite a while, and for one reason or another I got a lot of questions and feedback on my take on it in the past few weeks. I'll try an analogy to point out what SIMD is, why it is not always useful, and why MIMD ("Multiple Instruction, Multiple Data") is not a whole lot better. EPIC (Explicitly Parallel Instruction Compute) is dead, and approaches with VLIW (Very Long Instruction Word) and extremely wide instruction words and decoders/predecoders don't seem to hold much promise either.

Imagine you have a very long wall that needs to be painted. You have 100 painters available to speed up finishing the job. A foreman will go and create 100 sections of identical size, and then direct each of the 100 painters into a certain position. Upon job start, each of the 100 painters will do exactly the same - down to the movement of the paint roller. If the wall was flawless and the surface required exactly the same amount of paint for proper coverage all along the wall, the result will be a perfectly painted wall that was finished 100 times faster as if a single painter had done it.

If the wall surface is not perfect, it is usually not a big problem for the foreman or a few painters to fix the remaining issues, and if the wall had a few doors and windows and trim, then these doors and the trim can be repainted with the proper paint after the wall paint has cured. The windows have to be treated such that the paint is scraped off as all painters will have painted over the windows as well.

The more windows there are, and the more the wall surface is imperfect, the more repair work will have to be carried out, and the advantage of using only one foreman and 100 painters doing exactly the same goes away.

A seemingly simple solution would be to associate one painter to one foreman so that the foreman can tell the painter at any given time what to do. In actuality, that's not a solution as we now might still have the time advantage of 100 painters and 100 foremen be done with the job 100 times faster than a single painter, but we have now deployed 200 people, and there needs to be a clearinghouse or arbitrator among the large number of foremen, so that will add to the total number of people on the job. Just the job of distributing tasks and jobs is now an administrative challenge by itself, so we have created a hierarchy of non-productive entities (the foremen that don't paint) that is associated with increaded cost and complexity, but we have not fundamentally solved the problem. In essence, that's MIMD. Instead of the task complexity itself we now have a challenge in the task distribution complexity.

What we do is different. We are not using SIMD or MIMD. It is not EPIC either, nor does it rely on an extremely wide instruction decoder either. We cannot disclose what it is exactly, but it does not suffer from the SIMD or MIMD problems, nor does it stall when dependencies are discovered which is what bogs down VLIW architectures.

Computer and network security finally seem to get the attention they deserve. The past few years have been absolutely terrible when it comes to protecting everyone's personal and private data. Equifax was not the first, and certainly the SolarWinds hack won't be the last of breaches. The issue I see is that the approach to solving the problem does not seem to fit the underlying cause. The solution that is pushed by the industry is more software. If software were able to solve the problem, we would have solved it. However, what we observe is the opposite. More software equals a vastly larger attack surface. Therefore, more and better hardware is needed so that the attack surface is reduced, and then build better firmware and better software on top of it.

Let's first get to the mentions of the solution providers The 20 Coolest Endpoint And Managed Security Companies Of 2021: The Security 100. Again, I am glad security is finally being brought up, and that is a good thing. If you look at the list, it is all higher-level software, without any regards to the underlying Operating System, the firmware or the hardware. Good thing is that there is backup and recovery software in case the breach did succeed...

The next article is about support software that helps prevent permanent damage in case a company got breached. Prevention of breaches by using encryption, virtualization, logging, filtering and advanced analytics as well as heuristics will reduce the attack surface and to some degree the severity of a breach. These applications are all useful and needed, and they certainly have their place, but by themselves they won't solve the breach problem in the first place. The 20 Coolest Network Security Companies Of 2021: The Security 100 is a good read and the list is well-researched; however, I still think it lacks pointers to the real solution - better underlying hardware that makes the firmware more robust and needs less software to protect itself, therefore reducing the attack surface of the whole solution. This must start with a secure BMC for servers, secure processor cores and non-core components, hardware filtering, truly secure boot and firmware update hardware measures, and of course accelerators integrated into the CPU to facilitate these requirements. Only when that is accomplished can we try to harden the software (and that includes the Operating Systems as well as all APIs and the application software stack) against attacks.

Newsmax is rehashing two stories that long ago have been debunked, claiming that China Used Secret Microchip to Spy on US Computers. The first one is an old Bloomberg story that claims that China (all 1.3 billion of them?) installed secret microchips on SuperMicro server mainboards so that they can control them. The second story is about an alleged Pentagon attack in which China had infiltrated a non-classified Pentagon network part.

I had commented on that Bloomberg story on Youtube while I was CTO of Axiado. First of all, server mainboards are designed with modern CAD software that creates a BOM (Bill of Materials) list, and second, the pick-and-place machines used in mainboard assembly use that BOM and the coordinates from the CAD software to build the boards, and then the quality control (QC) will take pictures of each mainboard and compare the actual built boards with the "golden model" of what it should look like from the CAD design files. Any extraneous chips would immediately be noticed. It is highly unlikely that a company as sophisticated as SuperMicro would not notice an extraneous chip on their mainboards. It is even more unlikely that first SuperMicro misses them, and then users such as Apple, Amazon and others, including us, would not notice any chips they don't recognize on server boards. Another claim in this story is that the extraneous chip will be able to control and monitor all of the traffic inside the server. Well, if that is the case then this little magic thing must have more computational horsepower than all of the Intel or AMD or ARM cores that legitimately are present in the server - and all of that without its own memory! If someone is that advanced to build such a chip, then they would not waste their talent on an attack as indicated above.

What is possible is that an attacker installed malicious firmware on the server mainboard as the Baseboard Management Controller (BMC) - in essence a Linux/ARM-based PC inside a PC-based server - is not a very secure chip. However, that is firmware, not a chip. Huge difference... The outcome may be similar as certainly putting a backdoor in, or monitoring some of the management traffic is possible, but it for certain is not an extraneous chip.

The other story that an unclassified Pentagon network was breached and unusual behavior of SuperMicro servers was observed has not been reported as true anywhere. This is a fairly wild claim that cannot be susbstantiated. Penetrating even an unclassified Pentagon network is not trivial. Assuming that compromised servers were installed and then created unusual traffic is much more likely, albeit I doubt that the Pentagon allows servers that were not subject to configuration management (and that includes firmware version) to be installed in any live network. I doubt the validity of that story as well. All Pentagon networks will have firewalls on each entry and exit point that check for infiltration and exfiltration, so if the attackers hoped that classified data would be exfiltrated from a breached non-classified network, then this was a test to check the Pentagon's response to an exfiltration threat.

I am not trivializing the threat, but there are simply too many holes in these stories. A sophisticated attacker would use stealth methods, not an extraneous chip, not waking up the 800 pound gorilla for an unnecessary test and incident response. On top of that I have to say that the attacks out of China have been a whole lot less advanced than those we saw from Russia.

It looks as if about four months into the nVidia/ARM merger announcement some of the larger ARM technology licensees are finally waking up, and that the FTC is taking a cue from Britain's Competition and Markets Authority that this merger or acquisition is probably not going to be without an impact on licensees or end customers.

The FTC is now taking a more detailed look into the nVidia/ARM merger, which in essence is not a merger but a flat-out acquisition of ARM. My concern was and is that a FRAND type licensing agreement is not a very likely outcome of that acquisition, and that it would harm all current ARM licensees. The question here is not if the current licensees could do what Apple did with its ARM-architecture application processors. That is the easier part as virtualizing them and then gradually replacing them is not too much of an issue as Apple has shown multiple times now.

The much bigger problem are all the small and oftentimes ignored embedded ARM cores in peripherals and in most of the I/O, including WLAN and USB and other components. They are designed and built to run on as little memory as possible and therefore cannot be virtualized. As a result, nVidia knows it has more than a bargaining chip. It can exert undue financial pressure on licensees that simply cannot replace the embedded ARM processor cores in time to avert an increase in licensing fees. I would not be surprised if any modern phone contains 30 to 40 embedded ARM cores - removing and replacing them is a nightmare, not only for the hardware development teams but in particular for the firmware teams as these cores likely run on a very broad variety of operating systems or even on bare metal application code.

I assume that Google/Alphabet, Microsoft and Qualcomm and others have come to the same conclusion accoding to Bloomberg and CNBC.Looking at the licensing terms and conditions to CUDA - nVidia's signature piece of software that makes GPGPUs hum - could have provided regulators and licensees a clue towards what nVidia is up to. I am amazed that it took them so long to find and voice their objections.

Let's see how this pans out. I am sure that the last word has not been spoken in this saga.

I had voiced my concerns on the nVidia/ARM tie-up on 2020-10-12 (nVidia buying ARM) and on 2020-10-14 about Apple and ARM on my blog.

It looks like Qualcomm is finally deciding that maybe I was right, and is now objecting to the acquisition. That's a bit late, and I assume that it might not have an impact on the regulators, but the big wildcard in the game is China anyway. If China objects or obstructs the deal, then it does not make a difference whether Qualcomm objected.

My argument was and still is that ARM is a licensing company for a widely used processor architecture and as such has to be independent of any of its licensees. An independent entity can make sure that there are no favorites, no undue influence, and that licensing can follow a FRAND (fair, reasonable and non-discriminatory) model. This would not be possible under an nVidia ownership - and neither would it be under the ownership of Apple, Samsung, Qualcomm or Broadcom or any other the other big names. That is not to say that these are bad or unethical companies - the opposite is true. These are all good companies, but they are driven by (relatively) short-term profit requirements as they are all public companies, and as such have to have a leg up over their competitors. That in turn means that the primary driver is an increase in licensing revenue, and while it long-term might destroy the ARM ecosystem, it will bring monetary benefits in the short-term.

I believe that ARM would do better if it remained independent. If that is not an option, then I suggest that all ARM licensees form a consortium with strong governing principles that continue the current liensing model, and make sure that this consortium is owned by all licensees that spend in excess of $10M annually on ARM licenses. That way license fees to some extent return to the owners while at the same time making sure that the ecosystem persists, and that new customers of the ARM architecture can be onboarded.

I say this not because I am a fan of the ARM architecture. The opposite is true. I vastly prefer the open RISC-V ISA over ARM and x86-64 and other processor architectures, but for the sake of diversity I'd like to see ARM stick around.

I have been asked many times now why I do not think that the so-called secure boot is in fact secure. It is not exactly easy to understand why even with some newly-added security technology current secure boot schemes are not a guarantee of full firmware boot image integrity. Once the bootloader has loaded all necessary components and has started loading the operating system from disk we’d like to be certain that no malicious code has been installed or is even running below the level that the operating system (and therefore the malware scanners) can detect.

Here is how “secure boot” technology works. The CPU will start executing code from a very specific memory location once RESET is de-asserted. This location is typically located within the so-called real mode address range that is only accessible prior to entering virtual mode, and it is associated with a physical address that is located at the top of a 20-bit or 32-bit addressable address space. An SPI Flash chip is normally mapped via memory-mapped I/O to this address. Since the processor does not know how to read from a device that is not main linear memory, it needs microcode ROM inside the processor to be able to access and read and execute code within the SPI Flash. This microcode cannot be altered and is created during the manufacturing and final test of the processor. This microcode instructs the processor to read and execute the code within the SPI Flash, and as a first step, the processor “verifies” the integrity of the entire SPI Flash chip. It reads the entire contents, called the firmware “image”, computes a hash value, and compares that hash value to a value found at a specific location in the image itself, or to a value that is stored in the Trusted Platform Module (TPM). While this sounds like a secure solution, there is nothing that stops anyone from altering the verification code in the SPI Flash to simply skip the verification, and declare the contents valid and complete and authentic. In other words, the verification is a bit like Münchhausen pulling himself out of the mud by his own hair. If you trust the verification that is run in software from an unverifiable source, then yes, this is secure. If, however, you assume that the verification code can be circumvented and entirely skipped by a programmer who “updates” your firmware image in the SPI Flash, then this scheme does not seem like it is capable of guaranteeing that the image being booted has never been compromised. For the sake of the netizens' digital security on the Web I certainly hope that resilient secure boot becomes the industry standard. We call it Assured Firmware Integrity/AFI™ and Resilient Secure Boot/RSB™ because we believe that the term secure boot is overused and at this point in time useless. Most secure boot schemes are in fact not secure. We can assure integrity of the boot code, and we can guarantee that the firmware has not been modified by an unauthorized entity or with unauthorized firmware images. At the same time, we can guarantee resilience as we can boot from a golden image in case an update failed or was corrupted.

Pat Gelsinger was the first CTO at Intel and the architect behind the i486 and should have become CEO when Paul Otellini stepped down. Instead, a string of non-technical CEOs were installed, and essentially, all of them failed. While Intel's BoD finally came to its senses, the question now is if it is too late, and whether Pat can catch up with more than a decade between when he last was responsible for chip and process node development and now.

Let's hope he still can identify tech talent so that he can refresh the current second and third level of management. It is direly needed. Intel needs to catch up both in processor architecture and in process technology. That's a huge undertaking.

Most of Intel's expensive acquisitions (more than $33B) under the non-technical CEOs have not returned any investment, and it is going to be up to Pat to reverse those mistakes, fire those that came on board without the required technical understanding, and restore competetiveness with AMD and ARM (and to some degree RISC-V) on the processor architecture side while at the same time battling TSMC for process node development. This is going to be an uphill battle, and it is made even more delicate as Intel needs TSMC to produce some of its processors. Drawing the lines between being a customer and competing with a supplier is going to be tough.

I wish Pat all the best simply because if he is not successful, Intel will suffer, and semiconductor manufacturing in the US will vanish.

We pledge that we will not do business with anyone who has been actively involved in the attempted coup and insurrection in Washington, DC on 2021-01-06, including the organizers and enablers of President Trump, as well as those Senators and Representatives who objected to the certification of the votes of the Electoral College, nor with any company that has appointed any such person to a Board of Directors or into an advisory position. We will prepare a list of persons that can be obtained by emailing us. These people and organizations will be permanently banned from doing any business with us.

For any job applicants we will require that they certify that they have not been part of the insurrection in Washington, DC on 2021-01-06.

Maybe the Senators and Representatives that serve the public have forgotten what the Constitution looks like, what it is all about, and what legal repercussions it has if it is disobeyed. In case they don’t recall that there is a government printing office through which the US Constitution is freely available, here is a link to the US Constitution in a version from 1993. Another link to a different annotated and commented version with analysis of its legal impact and ramifications is here.

In light of the attempted coup by the sitting President of the United States of America to overthrow the freely and fairly elected Biden/Harris government, we have decided to update our terms of engagement and our code of conduct with prospective employees, customers and partners.

We will update this section asap.

Donald J. Trump has proven to be the clear and present danger to the US, its Constitution and its people as many of us had feared. It is my civic duty to request that our elected officals act and remove him from office and impeach him so that he cannot start a second coup attempt, start a war, or bring upon us even more civic unrest than he incited already. The insurrection he incited and asked for brought us to the brink of disaster, and we cannot afford it to have him serve out his term as it simply is too dangerous to do so. He has no checks and balances in place and still holds the nuclear codes and the "Commander in Chief" designation.

Recent news indicate that Oracle and HPE have left Silicon Valley. That's not entirely true as all these companies did was move their HQ to Texas. As far as I can tell, there were no layoffs or office closures within HPE or Oracle. I see that purely as a tax avoidance strategy. I do not foresee any impact on the workforce once the pandemic is over and employees return to the office for work. It is troubling in a way that clearly those companies did not see continued value in being headquartered in Silicon Valley, but I do not think that one should infer that Silicon Valley has lost its mojo. It is expensive here, and it always has been, but the pool of talent is deep and broad. While other cities (and regions) may have caught up in some areas, I still think that entrepreneurial spirit and availability of funding sources combined with the depth and breadth of talent in the San Francisco Bay Area is unparalleled.

The departure of Palantir is different though. While I am not a huge fan of Peter Thiel or Alex Karp I have to admit that there is some truth in why Thiel, Karp and Palantir all left Silicon Valley. To some degree Silicon Valley has become its own echo chamber, and there is a downside to that. If we agree that a democracy has to have the right to defend itself (i.e. the nation and its people) against adversaries, then we must be able and allowed to put that defense infrastructure in place, without a social or other stigma attached to those who work there. If lawmakers and justices agree that there is a threat from foreign and domestic groups that threaten to overthrow our way of governing ourselves, then of course we must have the means in place to conduct surveillance operations against those involved. That does not invalidate my opinion on strong encryption, as I have mentioned many times that surveillance of the endpoints and the existence of communication can be sufficient to establish a reasonable cause for a search warrant. Wholesale surveillance and archival of communication is not and should not be synonymous with this goal, and that is why I am split on Palantir. The NSA might have developed the technology anyway, but Palantir certainly accelerated the possibility of complete and total surveillance. Coming back to my echo chamber comments, I think that while it is great to have a noble goal (“Do no evil” comes to mind), sometimes that has unintended consequences. I’ll expand on this in a subsequent blog entry.

It has become very expensive to live and conduct business in Silicon Valley, and there cannot be any doubt about the fact that it has started to drive away talent and a lot of the supporting populace to make the Valley hum. It is questionable if we get our money’s worth here if I look at the highways, the public transportation infrastructure, even Internet access at a decent Quality of Service and cost. For unmanaged 1 Gigabit per second links without any decent QoS and availability (and robustness during disasters) the going rate is over $100 per month, and that is in international comparison too high. Managed full-duplex GbE is still in excess of $1000 per month, and that is vastly overpriced. It is ridiculous to see that in the middle of the region that brought us all of the ASICs and the devices that make communication available, this very access is not competitive with the rest of the world.

I want to comment on the so-called SolarWinds hack as there is a lot of misinformation out there, and it is not due to the fact that reporters intentionally mislead, but due to the complexity of the case. I would like to simplify it as much as possible without making it false to explain what happened here.

For one reason or another, penetrating a single server, a single data center or a single cloud provider was not enough for the attackers. They wanted full control over the IT infrastructure in their target countries.

This was either impossible to do with traditional methods, or too time-consuming.

To understand this attack and its scope, it is important to know that data centers have grown so huge that they require their own set of tools to just deploy servers, prepare them for customer (or in cloud speak, "tenant") use, administer them, check on their health status, and maintain them as well as to take them down if they need replacement. These OAM&P (Operation, Administration, Maintenance and Provisioning) tools - in this case Orion - are complex all by themselves, and they are usually built the same way that all other Internet backbone tools including Linux are built: with a collection of a very large number of pieces of source code, some of them proprietary and in-house, and others open source.

That is where this attack originated. The attackers hijacked some of these pieces of software and added code to them that constituted a so-called "backdoor" once their code was included in a new "build" of the OAM&P software. In other words, once the new tool was built (compiled and linked), their code allowed them to use the backdoor to access the servers through the OAM&P mechanism. That is very hard to detect as the tool does what it was intended to do, but for people who were not supposed to access it. The only way to detect an attack like this is by using behavioral monitoring. In other words, if I use the tools to conduct OAM&P and that is my profile of use, and then someone with illegitimate credentials uses the same mechanism (IP addresses, port numbers, APIs and more) to conduct surveillance and to access net user data, then the profile is different and should (and can) be detected as illegitimate and be flagged as a breach.

However, it took SolarWinds and FireEye as well as Microsoft more than six months to detect this breach, and effectively end new infections (but likely not eradicate all existing backdoors). I rarely praise Microsoft, but in this case they did exceptional work once this breach was suspected. Microsoft then followed through with stopping the attack and helping affected users to preserve evidence as much as possible to submit this to law enforcement. FireEye - while itself being a victim - assisted Microsoft and others in evidence collection and analysis of the logs of victim machines.

The challenge that all victim organizations are facing now is that it is unclear if the attackers managed to install backdoors in the servers themselves, not only in the OAM&P servers in the network management centers (NMCs). The number of servers in the NMCs is limited, and worst case they can be physically replaced. However, it is not clear if the breach went so far as to compromise the servers that deal with customer or tenant data. In other words, at this point in time we cannot trust in the integrity of the servers in the affected organizations - and those include the US Treasury and the administrators of the US stockpile of nuclear weapons.

Only after a thorough review of all software on the servers that might have been affected can we be certain that no additional backdoors were installed. That is a monumental task as likely hundreds of thousands of servers must now be assumed to be compromised.

The question to ask is what the attackers got out of the successful execution of this breach. First all of, they gained insight into lots of US agencies, and they have been able to steal data possibly indicating the identity of spies and counteroperations. Second, they have suceeded in eroding trust in US and more general Western democratic institutions. Third, they have damaged the economy as some of the Internet infrastructure has to be replaced or at least evaluated for persisting breaches and backdoors. The damage is likely in the tens, if not hundreds of Billions of Dollars.

Considering that the targets are very clearly the Western democracies, I have to say that the attacks likely originated in Russia or in North Korea. While China certainly has its own cybersecurity and cyberattack units, this breach is very unlikely to come from China as its economic well-being is too intertwined with the economic status of the Western democracies.

More and more benchmarks keep appearing for Apple's M1. The more I read about it, the more I am impressed how far Apple pushed the ARM architecture both in terms of absolute performance, but also with regards to its energy-efficiency. This is not only due to a manufacturing process at TSMC that is ahead of everyone else, it is also about how the entire processor is effectively a System-on-Chip with all needed accelerators fully integrated. What I am still missing is the information about how many of the accelerators in fact are fully programmable and by themselves are ARM cores in disguise. I assume it's quite a few of them, and that may be a good portion of its advantage. Surely the CPU cores are impressive, with the little and big ones implemented such that the required performance is achieved by the cores that are most suited to the tasks. While they might still lack multi-threaded performance that large Intel cores provide, the real advantage lies in offload of mundane tasks, and I'd really like to see how much of the offload is done in dedicated cores so that the application cores don't have to take over those chores. I am pretty sure that in another two generations or so Apple will have caught up with Intel even in multi-threaded performance, while retaining its lead over Intel with the intelligent I/O. That would truly end Intel's dominance in compute. The only question is now what AMD does to hold up the x86-64 flag... I am not betting on them to keep it going. I think it is time for AMD to switch over to RISC-V and leave x86-64 behind.

With regards to Apple's announcement of the new M1 we are back to discussing performance. Performance is measured by using standardized benchmarks. Even that is a very complex and multi-faceted issue for processors and even more so for computers. Why? Because the number of input parameters is extremely high. If we go back to basics, and discuss basic physical units we want to measure that's pretty simple: If we want to measure a physical unit, we can refer to the methods that NIST and BIPM and others prescribe. For a length, we take the speed of light and measure the time it takes to go from the starting point of the unit under test to the endpoint of it. Since we know the speed of light (it's one of the fundamental constants), the travel times gives us the exact length at a very high level of precision. The same is similarly applicable to areas and volumes, and even for currents and voltages. The definition of the weight is currently being changed from a sample of the Ur-Kilogramm to a volumetric unit with a certain mass per volumetric unit derived from the atomic mass of its material composition.

Measuring the performance of a processor or a computer is a vastly more complex undertaking.

The perceived performance of a processor or computer is highly dependent on my application profile, and that is different from yours and anyone else's.

I do not game. I do compile, but I do more floating-point math stuff. I don't use Word, or any MS office tool. I use LibreOffice, and I use a different browser with vastly higher capabilities for filtering and a different email client than most. So my use and therefore requirements profile differs. Maybe you compile, lookup, use a standard browser and FTP and other tools. Your use of the instructions that your computer (more precisely, the processor's ISA) provides you is different from mine. Your need to access memory likely is different from mine. Your applications may have a different locality of the data going to and coming from memory. Locality has a huge impact on performance as caching algorithms make use of locality to hide the inherent latency of DRAM over SRAM. The locality of data and instructions (or the lack thereof) may have a bigger impact on performance than the processor core.

Let's say I run 1 MB data sets, and yours are 100 MB. Yours will exceed the cache size of any CPU and will work only if there is locality in your data. If not, your caching will not work effectively since incoming data will overwrite existing data only to be reloaded again. Your performance will be at the performance level of the DRAM. Even if your and my setup and software are identical, I will see much better performance out of the same HW.

For me, it does not matter if integer performance for CPU X is better than for Y, and I also use more tools that parallelize compute. So a processor with more lower-performance cores with better floating point performance is better for me, particularly if it scales with number of cores. The same is true for Inter Processor Communication (IPC). If my applications and my compiler allow for better use of multiple cores and even multiple processors, because my OS distributes the load better than yours, and yours keeps things on very few cores and only uses inter-process communication for communication between threads and tasks, you will see vastly different performance based on the differences in how the processors and cores deal with IPC.

Your applications may be different on how much and how often you need to execute I/O functions.

If my computer needs to execute all I/O in software on the main CPU cores, and yours can offload those functions, yours will outperform mine by a wide margin on all applications that have or create a high I/O load.

How can a single benchmark capture this? It cannot.

That is why there are different benchmarks for different things, and that is why it is so hard to come up with a single fair benchmark.

This is today compounded by the problem that we do not only measure absolute performance, but also the performance per Watt, or the computational efficiency. To sum it up, there is no single fair and correct benchmark in existence today.

Apple's approach to showing comparisons for typical applications used by MacBook owners is not more or less valid than others; it is one of many that all may render different outcomes. It is not any more or less fair than others either.

Yes, you read right. Bitrot. Bits don't rot, you say, and you are right. They don't. The physical media they are on deteriorate. But that is not what I mean here.

Bits represent data, and that data is used to represent something, usually some sort of contents in some format for some software. If the data is still there but it cannot reasonably be interpreted any more, it might as well have rotted away - and that is what I mean. Case in point: I needed to look up some data from my Diploma thesis, written in 1989 and luckily available in four formats: Microsoft Word from way back then, in LaTex, and as a printout and scan of that printout in GIF. The printout on acid-free paper was still perfectly fine since I had hidden it and it was never exposed to sunlight. No oily fingers leaving prints were allowed to touch it, and so the printout was fine. The scan from way back then as a GIF was importable and readable too, but the prevalent resolution then was fairly low, so the clarity left much to be desired. It was so bad in fact that I considered it rotten. Today's Microsoft Word did not even touch the old Word file - it simply could not open or import it, even with all of the file format conversion tools that MS has available. It did not open it, it did not display it, and it did not print it. I considered that rotten too, although all the bits were still perfectly preserved. By chance, I opened it in OpenOffice, and OpenOffice opened it, displayed it, and was able to print it, albeit at the loss of pretty much all format, and the embedded graphs were lost. All of them. So I still considered the Word format a total loss - complete bitrot. LaTex fared a lot better. All text, format and formulas were still there. Most of the embedded graphs could still be displayed, with the exception of a few plots created by an IEEE488-attached plotter (yes, back then that was modern...). I considered that a winner for a while, only to find out that if I scan the printout and then run some decent OCR on it, I was able to recover close to 100% of all contents, text, graphs, formulas and nearly everything else. So what's the moral of the story? Do not believe in the promise of a major piece of software creating something that can still be interpreted 30 years down the road. It will create something that is susceptible to major bitrot. If it is important, paper and printouts still rule. Even if you can preserve the bits and the file itself, it is going to be borderline useless if the application that was used to create the file is not available any more (or does not run on modern hardware). In other words, if you create documents that must survive for more than a century, and if they are important, print them. Maybe PDF/A might be an alternative, but I am not sure about that...

Why do I bring it up now? Very simply because I see that there is a major change in Operating Systems, applications, and of course the type of devices that we use to read, write, browse and process data. Applications and flat-hierarchy proprietary formatted ASCII-type data formats from the old single-user, single-tasking Operating System days on clunky PCs with a 640 * 480 screen resolution have long given way to rich data formats with or resembling HTML on multi-user, multi-tasking Operating Systems with quad VGA screen resolution at least even on smart phones.

Apple announced its new Macbook Air, the Mac mini and the Macbook Pro yesterday. All three are powered by a big.little combo of ARM processor cores, a set of accelerators, and very high bandwidth memory interfaces. This is Apple's first internal design of a laptop processor, and it is way beyond the smart phone processors of the A line. The new processor dubbed M1 is seriously impressive, both in absolute performance and in performance per Watt. I had not expected such a performance leap over the incumbent Intel processors. While Apple did not quite disclose which benchmarks they used, the notion of a 3.5 times performance gain is impressive. Even more so if in fact the power consumption is reduced by 50% compared to the prior Intel processor.

Over the past 40 years we have seen processor families and ISAs (Instruction Set Architectures) come and go. Not always did the "better" solution win.

That was fairly apparent with Intel's original 8086 versus the Motorola 68000 family, then again with the 80286 against the 68020 and 68030, and it happened with the SPARC and MIPS versus the DEC Alpha. We saw the RISC versus CISC wars, and luckily all of those wars have died off.

It is possible to design an excellent CISC Processor the same way it is possible to create a subpar RISC design - and vice versa. The instruction sets do not really matter. All that counts is how many instructions per second the final product executes, how much energy it uses to do so, and what the silicon area is that it is consuming. Another important metric is how much the processor design burdens the software and compiler developers, as Intel had found out with its Itanium and EPIC (Explicit Parallel Instruction Computing). Most processor architectures have by now faded away, and we are left with x86-64, ARM in its various guises, and of course RISC-V. SPARC and POWER have seen a very dramatic decline in use, and while open source variants exist, they don't seem to gain much traction. MIPS has been undead for a long time now, but its new Chinese parents may want to (or have to) revive it.

As a result, I believe that the ISA and CPU architecture wars are over and behind us, because very simply, neither the ISA nor the CPU (core) architecture matter. What matters is how easy it is to integrate accelerators and coprocessors, as these units will do the majority of the work. The CPU will become just an orchestrator. That is why I have high hopes for RISC-V (although even that ISA has issues that drive me up the walls).

A good portion of the tasks in a computer can and should be dealt with by offload engines or accelerators. Intel claims that its processors are fast enough to take over all computational tasks in a computer, and that no accelerators or offload engines are needed. In all fairness, Intel tried twice to decentralize compute. The first time they tried it was was the 8086/8087/8089 combination, where the 8088 or 8086 was the main CPU, the 8087 was the math coprocessor, and up to two 8089 could included for offloading I/O tasks. The problem was that there was no operating system making use of this, and the idea died. The second attempt started better with I²O, and this time the I/O offload engine of choice for each I/O intensive peripheral was the i960 and later on the (ex DEC) StrongARM. Intel made an effort to add software and drivers, but that effort ultimately also failed. For ARM, the story was the opposite. The ARM core simply could not cope with any I/O, and it required offload, so even smaller and cheaper ARM cores were integrated into everything and anything that needed a performance boost due to demanding I/O, a complex protocol, or offload for a variety of other reasons. These became the "embedded" processor cores, and they used a variety of different Real Time Operating Systems (RTOSes). That led to the fact that ARM-based laptops today can compete performance-wise with x86-64 based laptops.

Over the past decades Apple has taken over most of its suppliers and most verticals providing services to it. It is hard to imagine that Apple will not do that for the most important piece of IP powering their products, the CPU core.

Apple’s legal battle with Qualcomm that for reasons incomprehensible for industry insiders Qualcomm won, is a showcase for Apple’s need to be in control of all of its supply chain. Qualcomm sold not only its wireless WAN chips to Apple, it also required Apple to pay royalties for that exact same IP included in those ASICs. For non-technology readers, an equivalent would be if someone buys a house, and then has to pay usage fees to the prior owner of the house. That’s incomprehensible and hard to understand.

Apple first stood up to Qualcomm by suing Qualcomm for essentially double-dipping. Apple won in the first instance, and many in the industry believed that Apple won rightfully. However, Qualcomm appealed, and in the appeal it won. Most technologists and IP lawyers would probably agree that the US appeals court made a grave mistake here. In either case, Apple decided to double down and bought the former Infineon wireless WAN group from Intel and redoubled its efforts to build a 5G modem and bring this technology in-house. For the time being though Apple had to revert back to Qualcomm and use its technology and the ASICs for its iPhones. At a market capitalization of $2T I doubt that Apple will continue to use Qualcomm chips in the future.

This illustrates to which length Apple will go to take control over its suppliers. That is why I am so surprised and confused why Apple did not buy ARM. With nVidia owning ARM, this story may repeat itself. Apple could have easily bought ARM. Certainly Google and Samsung would then have moved to an alternative, as would most other smart phone suppliers, but the transition to another CPU architecture would have been upon them, and not upon Apple. I do not understand this. I had bet that Apple – prior to the sale of ARM – would transition over to RISC-V, but I lost that bet. Apple did not consolidate ARM and x86-64 to RISC-V, it stuck with ARM. Now what does Apple do?

Here is my perspective (and of course I may be wrong. I have been wrong in the past on this). nVidia acquiring ARM has direct and short-term as well as long-term implications on the entire semiconductor industry as well as on all related industries. I am going to highlight them and point out why I think that way.

After full integration of ARM into nVidia there are going to be issues with the licensing model.

First, in my opinion ARM is overvalued today if one applies usual economic guidelines. ARM's licensing revenue does not support a $34B or $40B valuation. I'd peg ARM's valuation at best at around $15B (seven times annual revenue), considering annual revenues of under $2B.

nVidia therefore did not buy ARM for future revenue attained by licensing out ARM architecture cores. Paying $40B for an asset that is worth at best $15B if future revenue is taken into account is stupid. Jensen Huang is not stupid. He is brilliant. As a result, we can assume that Huang bought ARM not because of future licensing revenue.

He bought it because he will have an asset that can be used to put pressure on Qualcomm, Samsung and - most importantly - Apple. Huang saw that Apple caved in the licensing and WWAN radio (both 4G and 5G) spat with Qualcomm. He'll do the same to Apple.

Apple's entire iPhone and iPad product line is predicated on ARM. The announcement was just made that Apple's laptops will follow, and one could reasonably expect that Apple will discontinue all desktop and server products. In other words, Apple is an ARM house, and one with a very large ASIC and processor development department in-house. Apple likes to have all of its suppliers under very tight control, or absorb them. Current Apple products contain many to probably dozens of ARM cores, in a wide variety of functions inside all of their chips. Consolidating all hardware on ARM and all software onto one RTOS and one OS - presumably iOS at this point in time - will help Apple save money.

I had predicted Apple would go the RISC-V route. I was wrong. Apple went ARM. Now, Apple really does not have a choice any more: either transition again, this time to RISC-V, or be under the control of Huang's nVidia.

Many of you will disagree, and I have heard the arguments: nVidia will continue to play nice and license out ARM cores. That might be the case, for a while, to lure everyone in. However, does anyone think that Apple will now buy pre-packaged ARM cores designed by nVidia? What will Samsung do? Or Qualcomm? They won't because there will be no distinguishing features. An Apple or a Samsung phone on par with an HTC phone, or an arbitrary phone from a Chinese supplier, or any other phone? That is not going to happen.

Second, most users do not care about absolute performance, or even if they do, they see it as a trade-off over power consumption. While today's modern in-order CPUs all achieve roughly the same number of instructions per second, the picture changes if the instructions per second are normalized against power (or out-of-order processing or simultaneous multi-threading are included). On top of that, accelerators have proven to be useful and more efficient than CPUs, and currently nVidia's proprietary CUDA GPGPUs are the weapon of choice for AI and HPC acceleration.

If nVidia fully enters the automotive L4 and up fray, with the ARM cores working in conjunction with nVidia GPGUs for display and AI accelerators, it will dominate that industry very quickly. nVidia can now tackle automotive, the phone industry, and the entire HPC market with ARM and GPGPUs as well as x86-64 working with the GPGPUs all by itself. It does not need partners or other suppliers. In other words, ARM can be everywhere where there is the need for compute. ARM covers the entire spectrum from feature phones to smart phones, from tablets to laptops, and in servers as well as in HPC and of course in automotive and in all embedded systems. The only exception would be desktops, but those are going away and provide a woefully low margin. Hard to believe, but x86-64 might soon be the cheap solution, and not the default (performance) choice.

All of nVidias customers will be their competitors. And in this case, there is no friendly "coopetition".

I am not sure why Tim Cook did not see this, and why he did not buy ARM. His exit paths out of the conundrum now are worse. Switching to RISC-V immediately risks a lot of business and creates a trust issue for Apple. Staying with ARM exposes Apple to risk from nVidia.

nVidia as well as Google and Western Digital were the largest RISC-V proponents. Nothing at nVidia happens without Jensen Huang's approval. So Huang knew well that RISC-V is a threat to ARM. Thus, I can only surmise that nVidia bought ARM for exactly one reason.

However, this has other implications as well. This brings me to the third argument, and that is the number of processor core choices available. What most casual users fail to understand is that the supporting ecosystem of a processor core is directly related to the number of users. The more users there are, the larger and the more robust the ecosystem is, and the larger and the more robust the ecosystem is, the easier it is to design and deploy it.

If ARM cannot be used by Chinese or other players because ARM now falls under CFIUS jurisdiction, alternatives must be used. There are not many:

Out of all of those, only RISC-V has a growing ecosystem, has no export restrictions, has the performance needed to compete with ARM and x86-64 in every aspect, and is open source (well, the Instruction Set Architecture is, not any given implementation).

In summary, I believe that the real winner out of all of this will be nVidia as they can make money short-term from existing ARM licensees, but long-term, RISC-V will win as x86-64 is relegated to desktops without a margin, and to legacy server backends.

Yet again the US Department of Justice (DoJ) tries to pitch End-To-End Encryption against Public Safety. The reality is that the opposite is true. There is no Public Safety without End-To-End Encryption. Predictably, the DoJ brings up exploitation of children to justify restricting the use of encryption. Encryption relies on secret keys or key pairs. The algorithms are standardized. For backdoors to work, a repository of keys and key pairs has to be created. This database will be the most-targeted piece of property ever, as it would reveal all keys from everyone to everyone else using encrypted communication. Whether this database is a collection of databases by each provider or a centrally and federally managed database does not make a difference. It will be breached. I do not want to go into any more detail here, and anyone who wants to dive deeper is invited to ping me. I promise to return email requests. I'd like to make it very clear: Backdoors to encryption are not needed and are dangerous. This renewed attempt of pushing legislation through that restricts encryption must be stopped.

It looks as if AMD is making a bid for Xilinx. This might be copying what Intel has done with Altera, and that outcome was not particularly good. It might also be based on better insight at AMD, or a different vision of AMDs' corporate leaders for its future. I am still scratching my head as I cannot figure out why AMD would want to buy Xilinx. Xilinx is a great company, but I fail to see the synergies. AMD is a great company in its own right as well, but other than investing what the stock market have given AMD over the past 12 to 18 months, I do not see where Xilinx would augment AMD.

Let's check the individual strengths of each company. AMD has over the past few years caught up to Intel with regards to the x86-64 processor architecture, and arguably passed it. This is not only because Intel is behind in semiconductor manufacturing technologies versus TSMC, which makes AMD's processors. The more important aspect is that AMD's architecture appears to be superior to Intel's. That's quite a feat. Its other product line, GPUs, are lagging behind nVidia's. They can't seem to catch nVidia in total performance, nor in performance per Watt. nVidia has also monopolized acceleration by GPGPU compute by using a captive and proprietary standard, CUDA. AMD (ex ATI) does not have a CUDA competitor, not is any meaningful open source alternative (such as openCL) supported by AMD. nVidia uses its advantage to the maximum possible extent, and it is now venturing into the automotive market and into AI and ML (Machine Learning) with its CUDA-supported products. AMD/ATI has nothing to counter that. If we add Xilinx to the mix, it does not change the equation one iota. Xilinx has excellent FPGAs, and its software to program the FPGAs (ISE and Vivado) is ahead of Intel/Altera's offerings, but it does not compare to CUDA. Xilinx FPGAs also don't offer a direct interface to any AMD server processor family at the socket-level, to increase interprocessor bandwidth and reduce latency between the CPU and the FPGA accelerator. Both would be needed to guarantee a performance advantage over PCIe-attached GPGPUs.

nVidia on the other hand is buying ARM. Whether that means that nVidia is going to drop RISC-V or not remains to be seen, but if one assumes that accelerated compute is the future, then nVidia is much better positioned as GPGPU compute is synonymous with nVidia and CUDA. In other words, if solutions three years from now are made up of 80% GPGPU and 10% CPU and another 10% for miscellaneous other stuff on the die, then nVidia will take the lead and kill off x86-64, independent of whether AMD buys Xilinx or not, and how well the integrations goes. The logic behind the AMD/Xilinx tie-up escapes me. If you have an idea why send me an email to info at abacus-semi.com.

Oracle had bought Sun Microsystems a long time ago. Considering Oracle and its past behavior, I am amazed that it did not kill off Solaris and SPARC (a RISC processor architecture) right after the acquisition. SPARC was an acronym, and it stands for Scalable Processor ARChitecture. The problem with that is that it is not scalable and never was. Anyone trying to scale out a large number of SPARC cores will have run into that problem. Niagara could not fix that. As a result, I am not surprised that SPARC finally hit the end of the road, and if my contacts into Fujitsu are correct, they gave up as well.

So I think it is fair to say goodbye to SPARC. Rest in peace, and please don't come back.

Solaris, on the other hand, was a distinguishing feature. It was not better than other UNIX, but it was proprietary. I had assumed that Larry Ellison preferred proprietary and captive products as they prevented a customer from migrating to better solutions. Well, I was wrong, and Oracle of late has embraced Linux. I am not sure if that was due to the lackluster performance they got out of scaled-out SPARC-based data centers running Solaris, or if Oracle simply got sick of supporting Solaris when in reality most Linux installations performed at least as well. Since Solaris did not have any OS extensions that would have made it a natural choice for any of the other Oracle offerings, it simply became a burden instead of an asset. Solaris, may you rest in peace, and please don't come back either.

During the design of every embedded processor, and even for quite a few accelerators, a stone-old debate is revived. It is about real-time operating systems (RTOSes) versus multi-user, multi-tasking systems, and it is about polling versus interrupts. Those concepts may sound strange and abstract, but they are actually very simple to understand. Let me use a house and doors and windows as an analogy, and let us assume the case in which doorbells exist versus the case in which doorbells have not yet been invented.

Let's start with a system that uses polling. The analogy would be me walking around the house and "polling" (i.e. checking the status of) every door and every window of the house, at preset times. If I poll the doors, I need to walk around in a circle that covers my desk and all doors. That is a piece of linear software that loops back to where I started. I could therefore write that as a linear piece or as a loop in a "for all doors do the following:" scheme - the compiled code will be the same or nearly identical. It does not matter how I do it, it is fairly low effort to write that software. The problem with that is that I cannot prioritize doors, and while I am in the loop executing the check, I might miss someone who is at the door that I had just visited prior, possibly (and even fairly likely) missing that visitor. Another danger is that someone chats me up with seemingly important stuff, and I miss my schedule (or the entire cycle).

In an interrupt-driven system I can prioritize doors (for example, the doorbell for emergency personnel has a different pitch and cadence than the one for the mailman bringing invoices and checks, and that again differs from the one for the least favorite salesman from the least favorite company we buy products and services from). That way I can deal with visitors at multiple doors easily. Let's say I am sitting at my desk and the invoice-delivering mailman rings the bell. I need to write down what I am doing so I can resume that task once I am back. I then proceed to the mailman to greet him to fetch my invoices for the day. On the way to the door, the emergency doorbell rings, and so I take note that I was on the way to the invoice-delivery mail door, proceed to the emergency door, and let the emergency personnel in while disabling all lower-priority interrupts, or have them queue up in the interrupt request queues. If my presence is required, I stay with the emergency personnel for as long as I am needed, and if I am not needed, the emergency door alarm is marked as being dealt with, the lower-priority interrupt requests are re-enabled and I can resume my prior task, once all other pending doorbells are dealt with. Since the invoice-delivery doorbell handling task is still pending completion, I can proceed to the mailman, fetch my invoices, mark that as finished, and resume my desk task. An additional benefit arises when I can mask the interrupts I do not want to deal with at a point in time. If I am busy with finishing some important work, I can either disable certain doorbells, or I can make their requests pending but do not allow them to interrupt me. In other words, the annoying salesman from company C will ring the doorbell and hear that it rang, but since I have some important stuff to do for the next 30 minutes, that request will stay pending. He can chose to stay for the 30 minutes, or post a note and leave.

By using an interrupt-driven system, I am in control of when I can and want to be interrupted, which interrupt requests I take, and I can guarantee that high-priority requests are always dealt with first, even if multiple interrupt requests arrive at the same time or in a time-staggered fashion. Even if so many interrupt requests arrive at the same time that would exceed the time I have available to process them, it will not bring the system or me into a situation that puts me in overload as I simply disable all interrupt requests from lower-priority sources and either mark them as pending, or disable them entirely. Hence, it is impossible to try to allocate more of my time to check the doors than I have available.

Let's evaluate what the overhead is: I need what is called an advanced programmable interrupt controller (APIC), and upon each incoming interrupt request I need to write down what I did when I was interrupted, and once that is dealt with, resume that task and shred the note that I took to remind myself what I had done. That is all. The APIC is a fairly trivial piece of hardware these days, and the overhead of taking note what I was in process of doing is no different than a branch to and return from any other subroutine other than that it is privileged. In computer speak, any CPU core can do it. In fact, all of it can be done by an I/O coprocessor within a heterogeneous MP system.

I would like to come back to an observation that stated that for a processor to achieve 1 FLOPS of floating-point processing performance, it would need to provide 1 byte/s of memory bandwidth. While Gene Amdahl disclaimed this particular observation, I think it is important to point out that there is a logic relationship between performance of a processor and its I/O bandwidth - this would be Kloth's Second Observation if unclaimed or disclaimed by Amdahl or collaborators. One FLOPS is defined as 1 floating-point operation per second. Today, we assume that all floating-point operations are 32-bit floats (minimum requirement) or 64-bit floats (more mainstream today). Most floating-point operations require two operands and produce one result, and the instruction is issued by one instruction word of 16 bit, 32 bit or 64 bit length. Most superscalar processors will need 64-bit instruction words to issue all instructions that are supposed to be executed in the following cycle. In our example, we will see two 64-bit operands being transferred in, one instruction word (64 bit) being transferred in, and one 64-bit result being transferred out. If any instruction is supposed to take one cycle (in superscalar architectures, greater than one instruction per cycle is normal) then any FPU will create one result per instruction and thus per cycle. In this example, we will need 3 64-bit words in and one 64-bit word out per cycle. That is four quad words per cycle, or 32 bytes of I/O per cycle. That's 32 bytes of I/O per FLOP, or if we divide all units by the time unit 1 s, then it is 32 bytes/s of I/O per FLOPS. This situation is aggravated in any processor that contains multiple superscalar cores and provides a very low number of DRAM interfaces. Only in situations in which compound and very complex floating-point instructions are executed this would not apply. I can think of sincos and tan as well as the hyperbolic functions as well as log and exp functions. What implications does that have? You won't see 3 TFLOPS of floating-point performance in a Xeon with a mere 200 GB/s of memory bandwidth. Our numbers are not theoretical peak performance numbers - they are numbers that indicate sustainable performance.

First, I am glad the RISC-versus-CISC wars are over. Second, I am equally glad that the best of both worlds has come to dominate processor design. We now have processors that support large instruction sets (and not surprisingly, the largest instruction set can be found in a RISC processor), and some of those instructions point to hardware engines that execute certain functions as native and possibly atomic instructions. Those functions are complex mathematical operations that were unthinkable to be implemented even just a decade ago. FFTs, matrix multiplications and most video codecs are commonplace functions in processors and DSPs today. They used to be macros or function calls comprised of hundreds of simple native processor instructions just a few years ago. So my lemma and theory is simply that every software library function that has proven to be useful will end up as a piece of hardware. In essence, it also means that the ISA will become less important. Our processor cores are based on the open Instruction Set Architecture (ISA) RISC-V. Our RISC-V cores are modified in a lot of ways from the original UC Berkeley and SiFive RISC-V designs. While they are fully compliant with the RISC-V ISA, we focused on simplicity, scalability and performance instead of ease of design. We have also modified the "uncore" parts of the processors while retaining full compatibility so we don't have to rewrite or modify drivers. Unlike other approaches, we decided to not extend the ISA either. However, we could have designed our processors with a different core and a different ISA, and I believe it would have no meaningful performance impact.

As a result, users and programmers can rely on industry-standard compilers, SDKs and APIs and do not have to worry about instruction sets.

One of my favorite pieces of advice from Albert Einstein is to "make everything as simple as possible, but not any simpler than that". Software is not simple. Software is great to test out new algorithms or new ideas that might not be able to be expressed algorithmically. However, once performance, robustness and security metrics and power envelopes come into the game, software is at a disadvantage against hardware. The world's programmers write more and more software. There cannot be any doubt about it. However, that software runs on more and more differentiated and dedicated hardware than ever. We not only have CPUs and GPUs (rebranded to GPGPUs), FPGAs, TPUs and Security processors, there are also more and more offload engines for network traffic. In other words, functions that we used to execute in software are now available as hardware building blocks, invoked by simple driver commands. Therefore my lemma is: "Any problem that can be described algorithmically, through table lookups or a combination thereof will be implemented as a piece of software unless it can be executed more efficiently in dedicated hardware". That statement also leads directly to Kloth's First Observation. If more and more software is being written, then (atomic) instructions will have to cover more and more of the tasks executed to save power and energy, reduce latency, and improve performance. MMX and SSE as well as H.264 video codecs are only one set of examples. Kloth's First Observation can be summarized as follows: "Any sequence of instructions that is proven to be deployed to a degree greater than a preset threshold in a typical application mix is replaced by dedicated hardware, controlled by a Finite State Machine dedicated to this sequence of instructions, and invoked by a new instruction word. The threshold is determined by goals for performance and latency as well as by the need to reduce power and energy consumption". If George Haber's original Observation ("If it can be done in software it will") were true, then we'd be back to the original Turing Machine, where no hardware assist existed for anything. That would mean that our processors execute in, out, inc and bne (Branch on Not Equal). That's all that's required, but of course it's not practical. While we could build a processor like this today in very few gates and with today's SiGe or GaAs process technology probably in the range of 60 - 100 GHz, it would not be practical, it would not perform well, and its power consumption per (compound) instruction executed would be well above the threshold that anyone would accept today. Instead, we keep adding instructions and dedicated hardware to an instruction set of a processor, and sometimes we even need an entire new class of coprocessors for specific tasks because the memory bandwidth of a CPU might not be compatible with the needs of that coprocessor, and because there may be real-time requirements that for example a DSP can fulfill, and a CPU cannot. So while the breadth of software is increasing, so does the world of hardware accelerators.

I am happy to announce that Abacus Semiconductor Corporation has been formally established. We have identified team members we'd like to bring on board, and we will finish that process in the next few weeks. We are going to build out the team to the degree necessary and then announce it by the end of June of 2021.