UV doesn't have sufficient penetration depth to cause a lot of trouble for the chip. Of course at some intensity, any kind of light becomes problematic but for any exposure level that doesn't also cause eye damage it's not a concern.
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.
Just another +1 for fastmail, long time user, really pleased with the service. They do one thing and they do it well, and they charge a fair price for the value delivered.
Actually this chip does have ECC on many of the SRAMs - hence the bit widths of 36 bits instead of 32 in many cases. If it's a concern that the ECC is being used as storage, I'd suggest a laser glitch on the SRAMs to confirm the disturbance is caught by the ECC logic. This would at least confirm that the ECC bits are being used as some form of ECC. We've done testing to confirm the ECC function, but you don't have to take my word for it, it's a thing you can verify, too.
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.
This is very interesting, but would you tend to agree that at some point the effort to adversarially inspect to verify becomes larger than the effort to make something like SRAM oneself?
The effort of fabricating yourself dense CMOS integrated circuits, instead of giving your design to a foundry, to have it fabricated there (where a malicious foundry could modify the design), is huge, even when you do not want a state of the art technology (which would require billions of $).
Here, the description of how an end user could verify what a die contains is intended to guard not only against the possible modifications done by a malicious foundry, but also against a dishonest designer, who could claim that the chip contains something, which is shown in documentation and in the part of the design files that are open source, but the real design could include something else.
I've run power for a 100-person theme camp in the past. According to the logs, we burned an average of 36.8 gallons per day, or 1.4 liters/person/day (we ran the generator for 9 days total) in 2025. The camp has air conditioners (iirc ~20 units), lighting, freezers, etc. although not everyone has all of the above.
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.
Thanks for the math. My mind was more on the transportation pollution (moving all the people and stuff into the desert and then back out again, every year). The amount of CO2 spent on flying people around for business and vacations blows my mind. Using jet engines should be something like 10x more expensive than they are to reflect the actual burden on future generations of humans and other species.
Anecdotally, from when I did first amendment activism, my lawyers would always recommend that I stick to doing it with dead tree editions as much as possible. Literal book banning and/or burning has direct judicial precedent that is hard to contest, enforced by lots of precedent.
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.
The core ID definitely didn't need to be in a register, but the elapsed clocks since reset is actually really handy. Having this in the hot path allows me to build a captouch sensor using the BIO, because the clock increment is 1.42ns and even though the rise time of the pad is microseconds you get plenty of resolution at that counting rate.
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.
Ah, thank you for the example, I understand how a linearly-increasing counter can be useful, if you use it that way. It would obviously be more versatile with write access & configurable clock dividers, pre-setters, counting direction, etc. The current design probably allows re-using the counter across cores & minimize space, so makes sense to me. I should dig into the RTL when I have a bit of time… Maybe I'll make it my bedside reading?
You could also say it's up to the user to implement a fully-fledged timer/counter in a BIO coprocessor if they need one, though ideally there would be a shared register (or a way to configure the FIFOs depth + make them non-blocking) to communicate the result.
Small cores like these are really fun to play with: the constraints easily fit in your head, and finding some clever way to use the existing HW is very rewarding. Who needs Zachtronics games when you have a BIO or PIO?
Yah, it is - the text is first posted to the campaign, and then copied to my blog for long-term archival in a domain that I control, sans the sales pitch.
It's hard to know for sure, because we don't have access to the PIO's implementation, but I suspect that the PIO is "not small".
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.
I suspect there are tricks to get higher rates, for sure. And hopefully once we see a library of applications forming, we can make informed decisions about what extensions and features would be necessary to enable the next level of I/O performance.
FIFO is 8-deep. I did fail to mention that explicitly in the article, I think. The depth is so automatic to me that I forget other people don't know it.
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.
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.