On 9/7/23 07:25, Kirill A. Shutemov wrote:
> On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
>> On 9/6/23 00:39, Adrian Hunter wrote:
>>> Support for unaccepted memory was added recently, refer commit
>>> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
>>> a virtual machine may need to accept memory before it can be used.
>>>
>>> Do not map unaccepted memory because it can cause the guest to fail.
>> Doesn't /dev/mem already provide a billion ways for someone to shoot
>> themselves in the foot? TDX seems to have added the 1,000,000,001st.
>> Is this really worth patching?
> Is it better to let TD die silently? I don't think so.
First, let's take a look at all of the distro kernels that folks will
run under TDX. Do they have STRICT_DEVMEM set?
> config STRICT_DEVMEM
...
> If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
> file only allows userspace access to PCI space and the BIOS code and
> data regions. This is sufficient for dosemu and X and all common
> users of /dev/mem.
Can a line of code in this patch even run in the face of IO_STRICT_DEVMEM=y?
I think basically everybody sets that option and has for over a decade.
If there are any distros out there _not_ setting this, we should
probably have a chat with them to find out more.
I suspect any practical use of this patch is limited to folks who:
1. Compile sensible security-related options out of their kernel
2. Go and reads random pages with /dev/mem in their "secure" VM
They get to hold the pieces, and they can and will get a notification
from their VMM that the VM did something nasty.
BTW, Ubuntu at least also sets HARDENED_USERCOPY which will *also*
enable STRICT_DEVMEM. So someone would have to _really_ go to some
trouble to shoot themselves in the foot here. If they're _that_
determined, it would be a shame to thwart their efforts with this patch.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
