On Thu, Jan 11, 2024 at 07:14:54PM +0530, Vidya Sagar wrote: > On 1/8/2024 7:49 PM, Lukas Wunner wrote: > > On Thu, Jan 04, 2024 at 08:01:06PM +0530, Vidya Sagar wrote: > > > On 8/1/2023 1:29 AM, Lukas Wunner wrote: > > > > As an alternative to disabling ACS, have you explored masking ACS > > > > Violations (PCI_ERR_UNC_ACSV) upon de-enumeration of a device and > > > > unmasking them after assignment of a bus number? > > > > > > I explored this option and it seemed to work as expected. But, the issue > > > is that this works only if the AER registers are owned by the OS. If the > > > AER registers are owned by the firmware (i.e. Firmware-First approach of > > > handling the errors), OS is not supposed to access the AER registers and > > > there is no indication from the OS to the firmware as to when the > > > enumeration is completed and time is apt to unmask the ACSViolation > > > errors in the AER's Uncorrectable Error Mask register. > > > Any thoughts on accommodating the Firmware-First approach also? I'm sorry, I don't have any good ideas. I just would like to avoid disabling ACS Source Validation because it would diminish our security posture. I guess setting the secondary bus number in the hotplug port to 0 isn't a good solution either because it would allow hotplugged devices to temporarily spoof TLPs from devices on the root bus, right? One option might be to have separate code paths: If AER is owned by the OS, mask PCI_ERR_UNC_ACSV on hot-removal, unmask on hot-add. If AER is *not* owned by the OS, disable ACS Source Validation on hot-removal, enable on hot-add, and warn loudly about the security implications. Another option might be to change error handling, i.e. ignore ACS Source Validation errors if they occur before assignment of a bus number. And temporarily disable DPC. None of these options look pretty. I'm generally not a fan of having the firmware own certain features. The user experience is better if everything is owned by the OS. This is just one more case in point. :( Thanks, Lukas
