-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/21/2016 10:16 AM, ron minnich wrote:
On Mon, Nov 21, 2016 at 7:53 AM Timothy Pearson <tpearson@raptorengineering.com mailto:tpearson@raptorengineering.com> wrote:
A quick check through the source seems to indicate that the generic pci_set_resource function will enable bus mastering on any PCI bridges. From that point on, if I'm not mistaken, any malicious device that exposed a bridge interface could enable mastering for any logical devices behind the bridge and attack the host. Am I missing something?probably not. Back in the early days this kind of thing was not an issue.
I hear you on this. Now, with many peripherals running a complex on-card operating system and on-card bridges being the norm, this has become a significant security hole that we should work toward mitigating.
We've always had to adjust for limits in the kernels we support. We have a PCI subsystem mainly because, in 2000, linux could not handle an unconfigured PCI bus -- it interpreted a "0 bar" as meaning "device disabled by BIOS" -- really!
Not surprised by this. Unfortunately, from what we've seen, Linux hasn't gotten much better at configuring bridges.
I suspect the BME enable on bridges was done because Linux or other guests didn't know how to configure bridges correctly. But Linux and other kernels are a lot better now than they were; I wonder if we should stop enabling BME on bridges.
It's worth a try. I suspect Linux won't re-enable BM on bridges that were otherwise configured, but I haven't looked over that part of the code in a while either.
In any event, however, if we make this change it should be done in small steps, and I think a good first small step is to start with things that *look* obvious, like the aforementioned NIC. I am going to submit a CL today to remove BME from that and see how much upset it causes :-)
Sounds good.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
-
Timothy Pearson