Messages in this thread | | | Date | Sat, 13 Aug 2022 23:58:13 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory |
| |
On Sat, Aug 13, 2022 at 09:04:58AM -0700, Andy Lutomirski wrote: > > > On Wed, Aug 3, 2022, at 7:02 AM, Dave Hansen wrote: > > On 8/2/22 16:46, Dave Hansen wrote: > >> To sum it all up, I'm not happy with the complexity of the page > >> acceptance code either but I'm not sure that it's bad tradeoff compared > >> to greater #VE complexity or fragility. > >> > >> Does anyone think we should go back and really reconsider this? > > > > One other thing I remembered as I re-read my write up on this. > > > > In the "new" mode, guests never get #VE's for unaccepted memory. They > > just exit to the host and can never be reentered. They must be killed. > > > > In the "old" mode, I _believe_ that the guest always gets a #VE for > > non-EPT-present memory. The #VE is basically the same no matter if the > > page is unaccepted or if the host goes out and makes a > > previously-accepted page non-present. > > > > One really nasty implication of this "old" mode is that the host can > > remove *accepted* pages that are used in the syscall gap. That means > > that the #VE handler would need to be of the paranoid variety which > > opens up all kinds of other fun. > > > > * "Old" - #VE's can happen in the syscall gap > > * "New" - #VE's happen at better-defined times. Unexpected ones are > > fatal. > > > > There's a third option which I proposed but doesn't yet exist. The TDX > > module _could_ separate the behavior of unaccepted memory #VE's and > > host-induced #VEs. This way, we could use load_unaligned_zeropad() with > > impunity and handle it in the #VE handler. At the same time, the host > > would not be allowed to remove accepted memory and cause problems in the > > syscall gap. Kinda the best of both worlds. > > > > But, I'm not sure how valuable that would be now that we have the > > (admittedly squirrelly) code to avoid load_unaligned_zeropad() #VE's. > > How would that be implemented? It would need to track which GPAs *were* > accepted across a host-induced unmap/remap cycle. This would involve > preventing the host from ever completely removing a secure EPT table > without the guest’s help, right? > > Admittedly this would IMO be better behavior. Is it practical to implement?
I don't think it is better if you look from host POV. It owns resources of the machine and it has to have a way to pull memory from uncooperative TD at any point.
It also would require more complicated private->shared conversion as guest has to notify TDX module about the change, not only host as we do now.
-- Kiryl Shutsemau / Kirill A. Shutemov
| |