On Wed, Sep 05, 2018 at 07:10:46PM +0000, Nadav Amit wrote: > at 12:02 PM, Nadav Amit <namit@xxxxxxxxxx> wrote: > > > at 11:56 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > >> On Sun, Sep 02, 2018 at 10:32:18AM -0700, Nadav Amit wrote: > >>> This patch-set addresses some issues that were raised in a recent > >>> correspondence and might affect the security and the correctness of code > >>> patching. (Note that patching performance is not addressed by this > >>> patch-set). > >>> > >>> The main issue that the patches deal with is the fact that the fixmap > >>> PTEs that are used for patching are available for access from other > >>> cores and might be exploited. They are not even flushed from the TLB in > >>> remote cores, so the risk is even higher. Address this issue by > >>> introducing a temporary mm that is only used during patching. > >>> Unfortunately, due to init ordering, fixmap is still used during > >>> boot-time patching. Future patches can eliminate the need for it. > >> > >> Remind me; why are we doing it like this instead of fixing fixmap? > >> Because while this fixes the text_poke crud, it does leave fixmap > >> broken. > > > > Do you have other fixmap mappings in mind that are modified after boot? > > Oh.. I misunderstood you. You mean: why not to make the fixmap mappings that > are used for text_poke() as private ones. No, you got it the first time. There are in fact more fixmap abusers; see drivers/acpi/apei/ghes.c. Also, as long as set_fixmap() allows overwriting a _PAGE_PRESENT pte and has that dodgy __flush_tlb_one_kernel() in it, the broken remains (and can return). So we need to fix fixmap, to either disallow overwriting a _PAGE_PRESENT pte, or to issue a full TLB invalidate. Either fix will terminally break GHES, but that's OK, they've known about this issue since 2015 and haven't cared, so I can't be bothered about them.
