Extending security coding practices to vendor IP

lowRISC / opentitan

OpenTitan: Open source silicon root of trust

https://www.opentitan.org

Apache License 2.0

2.46k stars 736 forks source link

Extending security coding practices to vendor IP #421

Open martin-lueker opened 4 years ago

martin-lueker commented 4 years ago

Follow-on to #367, as brought up by #390. Once we establish a set of RTL coding guidelines for OpenTitan, the question remains as how enforce this in external components.

tjaychen commented 2 years ago

@arnonsha @zi-v @sha-ron

it would be great to hear your opinions here.

This is the same question @msfschaffner , @eunchan and I have been discussing. Ideally we would like to maintain a similar coding style and standard across all code, both open source and proprietary.

zi-v commented 2 years ago

IMO, guidelines like ‘Secure Hardware Design Guidelines’ (https://docs.opentitan.org/doc/security/implementation_guidelines/hardware/) should not be enforced for propriety IPs. Reasons:

Large IP vendors may not be open to customizations of their IPs. So this may narrow down the licensing options (sometimes to none)
Enforcing such guidelines on IP vendors may increase cost, risk and lead time. Note that IP vendors usually don't start from scratch and the cost/risk/lead may be proportional to the diff.
Guidelines as above are generally good, but they leave much room for interpretation, tradeoffs and RoI considerations. It's not clear to me what exactly should to be enforced and how.
The access to proprietary IP is limited (usually it is not in public domain), this limits the review capabilities and also the added value for the open community.

tjaychen commented 2 years ago

I understand your point Ziv. But for the IPs that are Nuvoton developed and at least visible to Google, I feel like we need to at least come to a compromise on what we should expect.

I think coding style we maybe can waive, but some of the security principles I feel would be similar. Specifically regarding any single bit signals that are potentially vulnerable.

zi-v commented 2 years ago

I agree that security needs to be maintained, but there is room for judgement of which 'single bit signals', for example, should be further protected and how. Maybe we should further discuss the details outside the public domain.

tjaychen commented 2 years ago

I'm adding this to the M3 milestone as it is something we have to conclude by Gold and is work in progress.

msfschaffner commented 8 months ago

Tagging this as a general multi-top issue and removing from PROD M4.

It does not seem to be relevant for Earlgrey-PROD anymore since we did perform security reviews on the flash and OTP wrappers with Nuvoton, and there are no big changes planned.