On Wed, Sep 9, 2020 at 8:32 AM Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > Sreekanth, > > > Broadcom adapters participate in a Secure Boot process, where every > > piece of FW is digitally signed by Broadcom and is checked for a valid > > signature. If any piece of our adapter FW fails this signature check, > > it is possible the FW has been tampered with and the adapter should > > not be used. Our driver should not make any additional access to the > > “invalid/tampered” adapter because the FW is not valid (could be > > malicious FW). This type of detection is added into latest Aero and > > Sea family adapters h/w. > > While I appreciate the intent, I would still like there to be an option > to permit using the adapter. I am concerned about users being unable to > boot their system due to this if, for whatever reason, these validation > checks fail. Maybe there is limited risk of that happening since this is > restricted to Aero and Sea adapters. But I am still concerned about > enforcing policy decisions like this in the kernel. These non-secure PCI Ids are very unlikely to happen as they are not actual IDs instead they get exposed when something wrong happens in the controller and it is good to prevent boot instead of giving an ability for an user to run malicious code. Also, This is an extremely unlikely event, and is evidence of physical tampering at the ASIC level. - If the executing firmware is authentic, signed Broadcom firmware, it will halt due to the evidence of physical tampering and you won't have a working controller anyway. - If the executing firmware continues to run, then that means that the physical attack has somehow succeeded and allowed the firmware to bypass some part of the signature check, since authentic firmware would have halted. In this case, the driver should reject the controller/firmware combination Thanks, Sreekanth > > -- > Martin K. Petersen Oracle Linux Engineering
