Regarding Proposed US Restrictions on RISC-V

November 6th, 2023

A bipartisan group of 18 lawmakers in the US Congress have recently amplified a request to the White House and the Secretary of Commerce to place restrictions on Americans working with RISC-V (see also the initial request from the Senate) in order to prevent China from gaining dominance in CPU technology.

The request is facially misguided; any restrictions would only serve to reduce American participation in an important emerging technology, while bolstering ARM’s position as an incumbent near-monopoly provider of embedded CPUs.

When the first report came out, I hoped it was just a blip that would go away, but with the broader bi-partisan group asking for restrictions, I felt I could no longer just stand by and watch: I am an active participant in the RISC-V ecosystem. I’m also subject to US law.

I did the one thing any American can do, which is write a letter summarizing my thoughts on the issue, and sending it to the White House, Department of Commerce, and the relevant members of Congress. Unfortunately, I don’t have a PAC, lobbyists or any sort of high-level connections to US politicians, so I don’t have much hope the letter will be received in time.

However, I do have a blog. I’m posting a copy of the letter I sent to the White House here, in far-flung hopes that maybe someone with more political connections than I might pick it up and send it on.

Finally, if you disagree with my stance or have a different perspective, I also encourage you to send a letter expressing your thoughts to various government officials. It doesn’t have to be “my way”, but a show of broad public interest in the topic may at least encourage policymakers to think a bit more carefully about the issue, and to hear out more perspectives.

The Letter

To President Biden and the White House staff:

Recently, a letter was sent to the White House and the Secretary of Commerce by 18 lawmakers asking how the US plans to prevent China “from achieving dominance in … RISC-V technology and leveraging that dominance at the expense of US national and economic security”.

I am a Michigan-born American with a PhD from MIT in electrical engineering. I’m also a small business owner who designs and manufactures electronics. I am writing to urge you to not place any restrictions on the sharing of RISC-V technology.

My products’ CPUs are based on the open source RISC-V standard. RISC-V’s openness specifically benefits small businesses such as mine. I get tools and designs from the open source community, and I contribute my improvements back to the pool. Barrier-free participation in this vibrant open source ecosystem keeps overhead low, allowing me to be competitive in the cutthroat hardware business.

Like the Internet, RISC-V is already a global phenomenon. There are already prolific contributions from the EU, India, China, and more [1]; the US is not the sole proprietor of RISC-V implementations. I use an implementation of RISC-V called the VexRiscv, which is developed in the EU. Any barrier for US persons’ participation will only slow American progress in developing and adopting this technology. It will have an effect opposite of that intended by lawmakers.

A further subtlety is that RISC-V is simply a standard. It defines a set of words used to tell a chip to do something, similar to how we rely on a dictionary to define the meaning of English words. Just as one can write secret documents using openly defined words, designs using the RISC-V standard can be proprietary, even if the standard is open. The benefits of open standards are so well established that the US has an entire agency – NIST – to promote American innovation and industrial competitiveness by publishing open standards.

Furthermore, it is not practical to police the use of an established standard: once a book is published, it is impractical to ensure that none of America’s enemies obtain a copy of it. This has long been a trade-off of American innovation philosophy: we can freely exercise our First Amendment rights to share ideas, creating a vibrant intellectual exchange, even at the risk of others benefiting from reading our textbooks, journals and patents.

I believe this trade-off has been in our favor. With every exchange – even with potential competitors – we learn more. Chilling our freedom of expression to achieve administrative outcomes is a page out of other more oppressive regimes’ playbooks: it is fundamentally un-American to restrict the flow of ideas.

In summary, any restrictions placed on US persons sharing RISC-V technology would only serve to diminish America’s role as a technological leader. Over-broad restrictions could deprive educators of a popular tool used to teach students about computers on American campuses, for fear of also accidentally teaching to an embargoed entity. And even narrow restrictions on RISC-V could deprive US tech companies with any potential exposure to the Chinese market of access to a cost-effective, high-performance CPU technology, forcing them to pay royalties to the incumbent near-monopoly provider, ARM Holdings plc – a company that isn’t American. This weakens American competitiveness and ultimately harms the US’s best interests.

If the administration agrees that RISC-V is a technology so critical to US economic and military interests that it deserves special attention, instead of trying to restrict its expression with a federally-mandated licensing regime, it should invest in programs to develop more home-grown American RISC-V chip maker success stories. It is already within the four corners of existing US legal framework, and the RISC-V contractual framework, for companies to choose to develop proprietary implementations of RISC-V CPUs. The US has strong precedents for companies navigating the boundaries of open standards and finding success without the need for federal guidance: Intel and AMD are American industrial juggernauts built around proprietary implementations of an otherwise openly documented “x86” computer standard. What the US needs is an American answer to ARM Holdings plc’s monopoly, and that answer comes from investing in US companies that embrace RISC-V.

President Biden, I urge you: have faith in American innovation. Have faith in American values. Do not place any restrictions on the sharing of RISC-V technology. We can work together to build more US chip maker success stories, while embracing the American value of freedom of expression!

Very truly yours,

Andrew ‘bunnie’ Huang
An American Hacker, Maker, and Author

[1] https://github.com/riscvarchive/riscv-cores-list

Name that Ware, October 2023

October 31st, 2023

The Ware for October 2023 is shown below.

Thanks to JeffreyO for contributing this ware!

Winner, Name that Ware September 2023

October 31st, 2023

The Ware from September 2023 is a Honeywell HPMA115S0-XXX PM2.5 sensor. Although Ben guessed the general category of the ware first, David was the first to give the exact model. Usually I award the prize to the first person to give an exact, correct model number and fall back to category-of-ware only if no correct model number was named. So, congrats to David for nailing the exact make and model of the ware. email me for your prize!

Bypassing Windows 11 Account Setup

September 30th, 2023

I had the misfortune of setting up a Windows 11 machine and being confronted with creating a mandatory Microsoft account. I can’t concisely explain why being forced to create an account bothers me so much, but generally when a vendor tries this hard to get you to do something, it’s not for a user-friendly reason.

Anyways, after a bit of searching I found that Rufus is able to create a Windows 11 boot image that can bypass the account setup requirement; but for various reasons I just wanted to modify the OEM configuration.

After poking through the Rufus source code for a bit, I found the pointy end of the stick, applied the patch, and it worked.

Here’s my notes on how I did it — mostly so I have it someplace where I won’t lose it, but also maybe because someone else might find it useful. NB: Microsoft seems to have been paying attention and hardening their setup process against work-arounds to account setup, so the shelf life of this post might not be so long.

Assuming you have a brand new machine with a Windows 11 OEM pre-install, and you have not yet turned it on:

  1. On first boot, go to BIOS settings and turn off the TPM (and backdoors like Intel AMT, Absolute Persistence module, etc.), and allow third party OS boot. On my machine (a Lenovo laptop) this caused the screen to go black for quite a while on reboot as it undid the Bitlocker encryption on the pre-installed Windows volume. Decrypting the Windows volume is necessary for the next steps.
  2. Grab an Ubuntu install image, put it on a USB drive, and boot the Ubuntu image using the “Try Ubuntu” selection.
  3. Mount the C: volume (probably the biggest partition on the NVME drive). You may have to run ntfsfix on the volume first to make it writeable.
  4. Edit the file at …/Windows/panther/unattend.xml and insert some XML (exact incantation shown below).
  5. Unmount the volume and reboot.
  6. When the first dialog box appears during setup, hit Shift + F10 and type OOBE\BYPASSNRO into the command prompt shell that appears. This will disable the internet connection requirement, and force a reboot of the machine to restart the setup process.
  7. When you get to “Let’s connect you to a network” there should be an option now that says “I don’t have Internet”; click that, and the system should proceed to setup a local-only account.

During setup, I connected to the Internet using a wired Ethernet line, so I could easily cut the internet by pulling the cable out if things went wrong and I had to try again (if you do set up by wifi, it’s a bit more complicated to cut internet). In my trials I did end up connecting a couple times and allowing the system to update, and that didn’t impact my ability to pull off the procedure in the end.

The specific commands I used within Ubuntu to access the unattended installer manifest were:

sudo su
ntfsfix /dev/nvme0n1p3
mount /dev/nvme0n1p3 /mnt
nano /mnt/Windows/panther/unattend.xml

But the exact path to the Windows partition will probably be different depending on your OEM and hardware configuration. The right partition is probably the biggest partition, so you can use fdisk to inspect your disk and guess the exact path for your machine.

The XML I injected was this snippet:

<RunSynchronousCommand wcm:action="add">
<Order>1</Order>
<Path>reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\OOBE /v BypassNRO /t REG_DWORD /d 1 /f</Path>
</RunSynchronousCommand>

Stick it in the first “settings” block, just after the “component” block. So overall, the top of the unattended.xml file on my machine ends up looking like this:

<?xml version='1.0' encoding='utf-8'?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="specialize">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="xxxxxxxxxxxxxxxx" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <OEMName>Lenovo</OEMName>
      <OEMInformation>
        <Logo>c:\windows\system32\oemlogo.bmp</Logo>
        <Manufacturer>Lenovo</Manufacturer>
        <HelpCustomized>true</HelpCustomized>
        <RecycleURL>https://www.lenovo.com/recycling</RecycleURL>
        <TradeInURL>https://www.lenovo.com/trade-in-program</TradeInURL>
      </OEMInformation>
    </component>
    <RunSynchronousCommand wcm:action="add">
      <Order>1</Order>
      <Path>reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\OOBE /v BypassNRO /t REG_DWORD /d 1 /f</Path>
    </RunSynchronousCommand>
  </settings>
  .... more settings blocks below ....

It’s not exactly a fast or convenient procedure, but unfortunately the “just unplug network during setup” hack that populates the front couple pages of Google searches on the topic was patched. Anyways, I always disable a bunch of the security theater/DRM and back doors installed by OEMs (in addition to running an overnight RAM test, hence the need to allow third-party/unsigned OS boot), so this was only incrementally more effort on top of what I was already going to do.

Name that Ware, September 2023

September 30th, 2023

The Ware for September 2023 is shown below.

Thanks to FETguy for contributing this ware!