This is pretty scary <https://twitter.com/matthewv...
# sky130
t
s
Was just talking to Matt about it on Twitter, would be interesting to see how to develop canaries for these types of attacks.
👋 2
m
@Tim Edwards see the way the inverter on the right has an isolated nmos source due to a change in dopant polarity? Could magic extract that? I tried but it didn't look correct to me. It should end up being like a tap cell.
s
I think the top-FET basically becomes a depletion-mode NFET. So you could model it as that. The thing I was curious about was related to how clean the actual implantation process might be. You would definitely affect the transistors near the implantation site, and that's not an effect you can easily model at the circuit-level. Seems like TCAD verifies that, but to know what the real effect would be, we'll need to figure out more about the spread in the implantation process itself.
o
Reminded me about the paper Matthew Hicks wrote a couple of years ago where he inserted a capacitor in the GDS between the division by zero status bit and the privilege bit so that you could gain privilege by causing enough division by zero in a short time
👍 1
He used an or1200 for that
s
That is a very clever trick!
It's also really thoroughly evaluated!
o
It's a very good paper
💯 1
m
Thanks for the link Olof!
t
@Matt Venn: Back to the original topic. . . The device on top becomes a varactor, which is poly on n-tap. The device on the bottom becomes. . . something. I never see p-varactors as foundry devices, so I'm guessing that's because they don't work very well. Since it's not a characterized device, magic doesn't have a way to represent it; if you read it in from GDS, it will either come up as a wrong kind of device, or else it will disappear entirely and leave a blank space over the gate. It's easy enough to add a p-varactor type to represent it. But still, it can't extract because there's no device model for it. Strike that. I zoomed in on the figure and realized that the P+ area substituted on the bottom does not pass under the gate. Which is actually kind of critical, because otherwise you'd short power to ground through the output. So there's no reason you can't draw it and extract that in magic. It's going to raise lots of DRC errors. If done in sky130, it would be rejected for fabrication.
s
@Tim Edwards my understanding is that the n-well -> n-tap -> diffusion should basically be a resistor between VDD and output?
t
@Siddharth Joshi: Yes, it is. But the poly-on-ntap is officially a varactor.
s
Oh got it, you mean that from an extraction perspective. Thanks for explaining!
m
Thanks @Tim Edwards, so we wouldn't be able to test these Trojans on the shuttle?
a
In my previous life, a company that I have worked with, they check the masks before fabrication to make sure that nothing has been altered. Basically they take the layout and generate the Masks for that layout using mask fracturing tool and send the original GDS and then the fab sends back to them the mask files as well before sending to the mask shop. They compare the 2 mask file sets: home generated against foundry generated. They must be the same. Sometimes companies send mask engineers even for checking actual masks before manufacturing. This practice is pretty common now for high value chips. Such attacks needs to be done at the GDS level and usually at the fab.
Shuttle projects don’t go that far. And usually there is no incentive for fabs to do that.
Plus there is no free mask fracturing tool. Technically it could be done with a tool like magic with massive constraints due to lack of OPC support in magic for example.
If someone knows a free OPC tool would be interested to see it.
And as mentioned above, these kind of attacks are relevant for high value chips that goes into day to day chips like phones, CPUs, etc..
m
👍
t
@Matt Venn: As drawn above, the layout would produce manufacturing-level unresolvable and unwaivable DRC errors. But that doesn't mean it can't be done. I did not read the paper, so I don't know the restrictions on the layout.
a
@Tim Edwards I didn't look at the image above. But I'm aware of the ideas related to hardware kind of attacks. My comments above are a general approach on what is the best practices that people do to avoid such attack. The people who does those kind of changes are very good at what they do. And they usually go to locations in the chip that are very critical path for flow.