On 11/3/2022 4:33 AM, Borislav Petkov wrote: > The moment we decide to change something in the microcode loader, we're > going to have to > > * test the IFS driver too > > * and I suspect we won't even be able to because we'd probably need > special hardware and those special blobs which you probably don't > distribute freely. We hear your concern that IFS test images are not yet publicly available for testing. We are working on it and it should be available in the near future. > > And yes, right now that function should be doing the SDM-sanctioned > dance about verifying the table and thus should also be generic but > judging from past experience, things do get different in time and > implementations do get changed so even if it is a trivial change to > microcode_sanity_check(), we would still need to test the IFS driver > too. > > So I'm wondering if it wouldn't be simply easier on everyone involved if > you just copy the bits you need into your driver and use them there as > you wish. > > Then the testing burden won't be an issue and there won't be any > potential cross-breakages. > We further hear your concern of potential cross-breakages due to IFS and Intel Microcode update driver sharing common functionality (like find_matching_signature() and microcode_sanity_check()). Within Intel, microcode and IFS folks do work closely, limiting the chances of this being introduced from Intel side. If these doesn’t alleviate your concern, I will post v2 without exporting the aforementioned functions and implementing them separately in IFS driver as you suggested. Jithu
