Replying only to the not-so-far addressed points. > On Wed, Jan 25, 2023 at 12:28:13PM +0000, Reshetova, Elena wrote: > > Hi Greg, > > > > You mentioned couple of times (last time in this recent thread: > > https://lore.kernel.org/all/Y80WtujnO7kfduAZ@xxxxxxxxx/) that we ought to > start > > discussing the updated threat model for kernel, so this email is a start in this > direction. > > Any specific reason you didn't cc: the linux-hardening mailing list? > This seems to be in their area as well, right? Added now, I am just not sure how many mailing lists I want to cross spam this. And this is a very special aspect of 'hardening' since it is about hardening a kernel under different threat model/assumptions. > I hate the term "hardening". Please just say it for what it really is, > "fixing bugs to handle broken hardware". We've done that for years when > dealing with PCI and USB and even CPUs doing things that they shouldn't > be doing. How is this any different in the end? Well, that would not be fully correct in this case. You can really see it from two angles: 1. fixing bugs to handle broken hardware 2. fixing bugs that are result of correctly operating HW, but incorrectly or maliciously operating hypervisor (acting as a man in the middle) We focus on 2 but it happens to address 1 also to some level. > > So what you also are saying here now is "we do not trust any PCI > devices", so please just say that (why do you trust USB devices?) If > that is something that you all think that Linux should support, then > let's go from there. > > > 3) All the tools are open-source and everyone can start using them right away > even > > without any special HW (readme has description of what is needed). > > Tools and documentation is here: > > https://github.com/intel/ccc-linux-guest-hardening > > Again, as our documentation states, when you submit patches based on > these tools, you HAVE TO document that. Otherwise we think you all are > crazy and will get your patches rejected. You all know this, why ignore > it? Sorry, I didn’t know that for every bug that is found in linux kernel when we are submitting a fix that we have to list the way how it has been found. We will fix this in the future submissions, but some bugs we have are found by plain code audit, so 'human' is the tool. > > > 4) all not yet upstreamed linux patches (that we are slowly submitting) can be > found > > here: https://github.com/intel/tdx/commits/guest-next > > Random github trees of kernel patches are just that, sorry. This was just for a completeness or for anyone who is curious to see the actual code already now. Of course they will be submitted for review using normal process. > > > So, my main question before we start to argue about the threat model, > mitigations, etc, > > is what is the good way to get this reviewed to make sure everyone is aligned? > > There are a lot of angles and details, so what is the most efficient method? > > Should I split the threat model from https://intel.github.io/ccc-linux-guest- > hardening-docs/security-spec.html > > into logical pieces and start submitting it to mailing list for discussion one by > one? > > Yes, start out by laying out what you feel the actual problem is, what > you feel should be done for it, and the patches you have proposed to > implement this, for each and every logical piece. OK, so this thread is about the actual threat model and overall problem. We can re-write the current bug fixe patches (virtio and MSI) to refer to this threat model properly and explain that they fix the actual bugs under this threat model. Rest of pieces will come when other patches will be submitted for the review in logical groups. Does this work? > > Again, nothing new here, that's how Linux is developed, again, you all > know this, it's not anything I should have to say. > > > Any other methods? > > > > The original plan we had in mind is to start discussing the relevant pieces when > submitting the code, > > i.e. when submitting the device filter patches, we will include problem > statement, threat model link, > > data, alternatives considered, etc. > > As always, we can't do anything without actual working changes to the > code, otherwise it's just a pipe dream and we can't waste our time on it > (neither would you want us to). Of course, code exists, we just only starting submitting it. We started from easy bug fixes because they are small trivial fixes that are easy to review. Bigger pieces will follow (for example Satya has been addressing your comments about the device filter in his new implementation). Best Regards, Elena.
