On Wed, Apr 29, 2026 at 05:09:43AM +0200, Willy Tarreau wrote: > On Tue, Apr 28, 2026 at 03:13:01PM -0600, Greg KH wrote: > > > > We can point at other files, as this list is going to get long over > > > > time, which is a good thing. > > > > > > Sure. I'm just unsure where this could be enumerated, as it's likely > > > that there would be just one or two lines max per subsystem for the > > > majority of them. Or we could have a totally separate file, "threat > > > model", that goes into great lengths detailing all this with sections > > > per category or subsystem when they start to grow maybe, and refer only > > > to that one from security-bugs ? > > > > I think a separate file is good, I know I need to write up what the USB > > model is, and it's different from PCI, and different from other > > subsystems. All should probably be documented eventually. > > Would you be interested in me trying to initiate a new "threat-model.rst" > file that tries to unroll the points mentioned in the list ? I'm concerned > that that withuot having many details initially, it could look a bit odd, > because the list we currently have would be more suitable for an "other" > section.
Sure, a small file to start with would be good for people to work off of and add to. > > > > > > (like what the IB subsystem does which I > > > > > > don't think you listed above, or the USB subsystem.) > > > > > > > > > > Indeed I didn't list IB (I'm never sure about it, I seem to remember > > > > > we simply trust any peer, is that right?), nor did I make specific > > > > > mentions for USB which is implicitly covered by "hardware emulation > > > > > or modification". > > > > > > > > Ah, but USB does cover "some" modification of devices, so this is going > > > > to be something that is good to document over time, if for no other > > > > reason to keep these scanning tools in check from hallucinating crazy > > > > situations that are obviously not a valid thing we care about. > > > > > > OK but does this mean you still want to get these reports in the end ? > > > > I want a patch if a user cares about that threat-model (as Android does > > but no one else) as it's up to the user groups that want to change the > > default kernel's behavior like this to actually submit patches to do so. > > Yes, OK, but we want them in any case. That's the idea I tried to convey > in the proposed doc (maybe not well enough), basically "this is a bug and > it is worth reporting, but no need to involve [email protected] for this". Yes, you conveyed that, sorry if I insinuated otherwise. thanks, greg k-h
