On my current iteration (Lenovo P1 with Intel AX211), the failure also requires some other device to try to talk to the laptop while it's being put to sleep. Anecdotally sleep tends to fail harder/more often on public networks, perhaps because there's more adversarial traffic scanning computers and waking the device up.

In the end, I really don't even understand why anyone would want their wifi driver responding to network packets when the device is asleep - given that these chips have DMA access via PCI to host memory (unless the IOMMU is configured, which is not a given) - this feature is equivalent to a persistent, always-on remote back door into your RAM, even when your machine is "off". Of course this requires an exploitable CVE in your wifi stack, but there is a constant stream of CVEs and obscure "remote management features", at least in the Intel drivers.

My solution in the end has been to just remove the wifi module from the motherboard (or in cases when it's soldered down, disable the driver by deleting it entirely) and then use an external USB wifi dongle. It's been almost a year now and no sleep issues, no more randomly heating up my backpack, and in public environments like e.g. hotels I don't worry as much because I unplug the wifi card from the laptop when I'm done with it. I had to go with the nuclear option because some updater somewhere is pretty eager about discovering the presence of the wifi device and "helpfully" re-enabling it, I suspect it's the Lenovo Vantage tool.

The external USB device is slightly inconvenient but at least I don't get woken up in the middle of the night by my laptop fan spinning up mysteriously anymore (OK not entirely true, the malware scan will trigger at night and spin up the fans but at least I know what's causing that...).

You are correct that the chip does, of course, interact with light because of the transparency. In typical applications, the housing would be opaque, and the chip kept in the dark. If you open an iPhone, for example, many of the chips have the exact same construction as this, and they are similarly photosensitive, but they are inside the iPhone case so it's not a problem.

However, for example, if you shine a laser pointer at the back side of the chip, you'll cause it to glitch. This is true both for the Baochip, and for the chips inside the iPhone. In the case of the Baochip, generally, this will trigger an attack sensor and the chip will reboot or go into fail-safe state, but a very precise laser pulse can escape detection, and thus form the basis of a glitching attack.

The Defcon badges were deliberately constructed with transparent plastic to highlight the inspectability of the chips, but if you have an actual concern about people attacking the chip with lasers or you plan to operate this in some environment constantly filled with bright strobe lights, the recommendation is to put some dark epoxy over the chip after you're done inspecting it.

The idea is that it's easier to put the epoxy on after inspection, than it is to remove the epoxy, inspect it, and then put the epoxy back again. This trades off against the assumption that supply chain attacks are a more scalable attack vector than direct physical attacks.

This check would not rule out the possibility that maybe there is some further back door that perhaps at runtime turns off the ECC function and then starts using the bits as storage, but one would need to hide the trigger for this somewhere, and there would need to be a non-trivial amount of logic to perform multiple accesses to the RAM to stripe e.g. executable code across the ECC bits. Specifically, you'd have to do 8 reads to put together a single 32-bit word in the case of a 36-bit wide RAM, which creates a fairly sizeable timing and power side channel.

If the ECC is confirmed (via glitch or sidechannel) during the trusted-boot measurement phase, and all the code and data space is accounted for, then the alternate mode trigger would then have to be in hardware. In either case there would be a non-trivial logic disturbance in the surrounding gates compared to the reference design (this is assuming you're trying to differentiate between a "good" design and a "modified" design).

To be clear, the article states that optical inspection alone can not yield a perfect security bound. However, it reduces the attack surface from an essentially unbounded problem, to a set of more difficult attacks such as the ones outlined above, which once enumerated can be detectable via other means.

This is a much stronger bounds than chips that are impossible to visibly inspect, and thus can trivially hold several kilobytes of fast code storage that can be easily swapped out and run at full speed, leaving little to no side channel to detect, and an intractably large space to search via software-only brute force for discovery.

Re: repair rows - these are a valid place to hide data, but in this design there are no repair rows, and you can confirm they don't exist from the imaging data.

The average household consumption of electricity per day in the US is about 28kWh, which would take around 7-9 liters/day of diesel. Assuming an average US household of 2.6 persons, that's about 3 liters/person/day for electricity alone - does not include gas/electricity spent driving. So, at least for this camp, the average person is using less electricity at the burn, than if we weren't at burning man.

The fossil fuels spent getting to and from the event are more substantial than those burned at the event, but this is a separate discussion I think as to whether or not people should be flying to conferences, events, or taking vacations. COVID was great for reducing travel-related fossil fuel consumption, so we have the data and the experience on how to reduce that, but probably not the will.

The power logs are pretty interesting to look at. On average the generator is lightly loaded, so a lot of energy is going towards idling the generator, but batteries are expensive and these generators are not made to be stopped and started repeatedly.

The problem with moving out of the dead tree medium is that suddenly a whole host of alternative, untested legal theories can be thrown at you. Even if they are preposterous or 'obviously wrong' to the lay person, these alternative theories increase the cost of litigation, and limits the quick remedies you can seek, because the judge has to consider now if your situation is different from precedent.

If your adversary is well funded they can just keep on throwing up 'but what about...' theories to the court for years and years, effectively achieving censorship without setting any meaningful legal precedent.

Then they can reuse this strategy again and again, and anytime a litigant gets close to winning they settle out of court, avoiding clear legal precedent and thus preserving this 'legal purgatory' path (settlements do not create legal precedent).

Basically, they learned from experience with books how to avoid other media getting the same level of effective legal protection.

It's a clever exploit on the legal system, but not great for actual justice.

I think it will be interesting to see what people end up doing with it and what are the pain points. As you say, it's a v1 - with any luck there will be a v2, so we could consider the time starting now as a deliberation period for what goes into v2.

The good news is that it also all compiles into an FPGA, so proposed patches can be tested & vetted in hardware, albeit at a much slower clock rate.

That being said - size isn't everything. At these small geometries you have gates to burn, and having access to multiple shifts in a single cycle really do help in a range of serialization tasks.

When considering the space of possibilities, I focused on applications that I could see there being actual product sold that rely upon the feature. The problem with DVI is that while it's a super-clever demo, I don't see volume products going to market relying upon that feature. The moment you connect to an external monitor, you're going to want an external DRAM chip to run the sorts of applications that effectively utilize all those pixels. I could be wrong and mis-judged the utility of the demo but if you do the analysis on the bandwidth and RAM available in the Baochip, I feel that you could do a retro-gaming emulator with the chip, but you wouldn't, for example, be replacing a video kiosk with the chip. Running DOOM on a TV would be cool, but also, you're not going to sell a video game kit that just runs DOOM and nothing else.

The good news is there's plenty of room to improve the performance of the BIO. If adoption is robust for the core, I can make the argument to the company that's paying for the tape-outs to give me actual back-end resources and I can upgrade the cores to something more capable, while improving the DMA bandwidth, allowing us to chase higher system frequencies. But realistically, I don't see us ever reaching a point where, for example, we're bit-banging USB high speed at 480Mbps - if not simply because the I/Os aren't full-swing 3.3V at that point in time.

The deadlock possibilities with the FIFO are real. It is possible to check the "fullness" of a FIFO using the built-in event subsystem, which allows some amount of non-blocking backpressure to be had, but it does incur more instruction overhead.

The C compiler support is a relatively recent addition, mostly to showcase the possibilities of doing high-level protocol offloading into the BIO, and the tooling benefits of sticking with a "standard" instruction set.

The 25MHz number I cite as the performance expectation is "relaxed": I don't want to set unrealistic expectations on the core's performance, because I want everyone to have fun and be happy coding for it - even relatively new programmers.

However, with a combination of overclocking and optimization, higher speeds are definitely on the horizon. Someone on the Baochip Discord thought up a clever trick I hadn't considered that could potentially get toggle rates into the hundreds of MHz's. So, there's likely a lot to be discovered about the core that I don't even know about, once it gets into the hands of more people.

The BIO should also be able to overclock. It won't overclock as well as the PIO, for sure - the PIO stores its code in flip-flops, which performance scales very well with elevated voltages. The BIO uses a RAM macro, which is essentially an analog part at its heart, and responds differently to higher voltages.

That being said, I'm pretty confident that the BIO can run at 800MHz for most cases. However, as the manufacturer I have to be careful about frequency claims. Users can claim a warranty return on a BIO that fails to run at 700MHz, but you can't do the same for one that fails to run at 800MHz - thus whenever I cite the performance of the BIO, I always stick it at the number that's explicitly tested and guaranteed by the manufacturing process, that is, 700MHz.

Third-party overclockers can do whatever they want to the chip - of course, at that point, the warranty is voided!

That being said - one nice thing about the BIO being open source is you can run the verilog design in Verilator. The simulation shows exactly how many cycles are being used, and for what. So for very tight situations, the open source RTL nature of the design opens up a new set of tools that were previously unavailable to coders. You can see an example of what it looks like here: https://baochip.github.io/baochip-1x/ch00-00-rtl-overview.ht...

Of course, there's a learning curve to all new tools, and Verilator has a pretty steep curve in particular. But, I hope people give the Verilator simulations a try. It's kind of neat just to be able to poke around inside a CPU and see what it's thinking!

Because it does what it does so well, I use the PIO as the design study comparison point. This requires taking a critical view of its architecture. Such a review doesn't mean its design is bad - but we try to take it apart and see what we can learn from it. In the end, there are many things the PIO can do that the BIO can't do, and vice-versa. For example, the BIO can't do the PIO's trick of bit-banging DVI video signals; but, the PIO isn't going to be able to protocol processing either.

In terms of area, the larger area numbers hold for both an ASIC flow as well as the FPGA flow. I ran the design through both sets of tools with the same settings, and the results are comparable. However, it's easier to share the FPGA results because the FPGA tools are NDA-free and everyone can replicate it.

That being said, I also acknowledge in the article that it's likely there are clever optimizations in the design of the actual PIO that I did not implement. Still, barrel shifters are a fairly expensive piece of hardware whether in FPGA or in ASIC, and the PIO requires several of them, whereas the BIO only has one. The upshot is that the PIO can do multiple bit-shifts in a single clock cycle, whereas the BIO requires several cycles to do the same amount of bit-shifting. Again, neither good or bad - just different trade-offs.