[tlul] tlul_sram_byte data integrity check

[tjaychen]

When a byte write is issued to memory, tlul_sram_byte is responsible for doing a read first to generate the new word-wise integrity.

However, the read data integrity is not checked as part of this generation. This potentially creates a security risk.

estimate 4

[tjaychen]

@weicaiyang

[weicaiyang]

Let's review this in D2S meeting

[msfschaffner]

@tjaychen, should we just check ECC on all SRAM reads in this case (like we do on incoming TL-UL transactions)?
I.e., if we are adding this logic anyway, we might as let all read transactions benefir from it...

[tjaychen]

o sorry, this is due to lack of a tagging scheme.
This is meant to be "future" improvement. I'm not too concerned about weaknesses in the byte case because we already KNOW it is weaker than a full word write / read.

[msfschaffner]

Ah got it, thanks for the clarification!

FYI @moidx @cfrantz

[moidx]

Tagging with software label as this needs to be added to the software implementation guidelines.

[andreaskurth]

Triaged for tlul. Are we sure we don't want to check the integrity of data read in tlul_sram_byte by adding a tlul_data_integ_dec and feeding its data_err_o into error_o? (This to me does not seem to be a complex change, though we might have to insert some flops to break overly long paths coming out of SRAMs.) Tagging @vogelpi for a security opinion

[vogelpi]

Thanks for tagging me @andreaskurth . After having studied the RTL I agree that the change would probably be rather simple and it would be a nice to have for M2.5. However, it's not critical. Thus, I label this as P3. If we don't have time to do it or things turn out more difficult, we can instead include information on this in the software guidelines.