3 ms·

Doing a "regular" ECO to push a RTL change to the gate-level netlist (bypassing regular synthesis) is already a very difficult process. The hardest part is figu

Doing a "regular" ECO to push a RTL change to the gate-level netlist (bypassing regular synthesis) is already a very difficult process. The hardest part is figuring out how your RTL maps to the optimized gates - and this is with full access to the RTL and netlist. I can't imagine someone being able to manage to pull this off from an unknown netlist and successfully understand, let alone modify, the design.

a1369209993 5y ago
> The software analogy I like to use is trying to reflect a change in your source code by modifying the binary directly without recompiling. Not sure about kayson, but I've done essentially that on a couple occasions (usually to some C++ abomination that refuses to compile away from the authors' build server). It's not that difficult.[0] > Unlike those pirate crackers who sometimes can pull this off, imagine you have no idea what the binary does, and even if you "run" it in simulation (super slowly) everything is gibberish. Realisticly, you usually do have a pretty good idea what the chip does[1], and may have 'extra'/'lost' stock from the previous revision to compare its behaviour against, especially if you're attacking something popular enough to be worth compromising (= probably more than one batch ordered). 0: Most off-the-top-of-head example from my notes file: fix caja(glib) wrong(decimal) unit prefixes: at libglib-2.0.so.0.4105.0:7CFB1 [... more at ...] change 4 bytes in g_format_size_full from: 41 F6 C4 02 test r12b 0x02 # if(flags&G_FORMAT_SIZE_IEC_UNITS) into: 48 83 FB 00 cmp rbx byte(+0x00) # if(size!=0) 1: Presuming 'you' are a intelligence agency, ie the kind of thing that would credibly try such a attack, not a isolated disgruntled fab employee.