On Thu, 2021-02-04 at 08:48 -0800, Dave Hansen wrote: > On 2/4/21 8:28 AM, Sean Christopherson wrote: > > > Do we see any security risk here? > > Not with current CPUs, which drop writes and read all ones. If future CPUs take > > creatives liberties with the SDM, then we could have a problem, but that's why > > Dave is trying to get stronger guarantees into the SDM. > > I really don't like the idea of the abort page being used by code that > doesn't know what it's dealing with. It just seems like trouble (aka. > security risk) waiting to happen. Hi Dave, Just to confirm, you want this (disallow ioremap() for EPC) fixed in upstream kernel before KVM SGX can be merged, correct? If so, and since it seems you also agreed that better solution is to modify ioremap() to refuse to map EPC, what do you think of the sample code Sean put in his previous reply? https://www.spinics.net/lists/kvm/msg234754.html IMHO adding 'bool sgx_epc' to ioremap_desc seems not ideal, since it's not generic. Instead, we may define some new flag here, and ioremap_desc->flag can just cope with it. Btw as Sean already pointed out, SGX code uses memremap() to initialize EPC section, and we could choose to still allow this to avoid code change to SGX driver. But it seems it is a little hack here. What's your opinion? Hi Sean, If we all agree the fix is needed here, do you want to work on the patch (since you already provided your thought), or do you want me to do it, with Suggested-by you?
