Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAMZm_C=o-rc4a+u_8-pFJtmL_2drwczASMRTqszamrks5Zm_OA@mail.gmail.com>
 <CAG48ez2PVMs-CeLoZtvPq2EeQqOg05mm3AuvEE_pr9Sog0O5og@mail.gmail.com> <CAMZm_CmW7pHwfEfCQfXRJPiHOjeGviQunfwxY_1ejrihKab5rA@mail.gmail.com>
In-Reply-To: <CAMZm_CmW7pHwfEfCQfXRJPiHOjeGviQunfwxY_1ejrihKab5rA@mail.gmail.com>
From:   Jann Horn <jannh@google.com>
Date:   Mon, 20 Jun 2022 13:32:06 +0200
Message-ID: <CAG48ez2OcfTQ4SRbY89uHDJG6QujSfChaO4B3=zgGpj=9J8bdA@mail.gmail.com>
Subject: Re: pgprot_encrypted macro is broken
To:     Federico Di Pierro <nierro92@gmail.com>
Cc:     Linux API <linux-api@vger.kernel.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 20, 2022 at 9:39 AM Federico Di Pierro <nierro92@gmail.com> wrote:
> > Why does your driver need to use that macro? pgprot_encrypted() is
> > mostly only directly used by core kernel code, not by drivers... and
> > if memory encryption is enabled, almost all memory mappings created by
> > the kernel should be marked as encrypted automatically.
>
> This is interesting; i don't really know the history behind our piece
> of code; as far as i understand,
> we have a shared ring buffer with userspace, onto which we push tracing events,
> and we must mark it as encrypted when
> the kmod runs on an AMD SME enabled kernel to allow userspace to grab sane data.
>
> This is the commit that introduced the change (if you wish to give it a look):
> https://github.com/falcosecurity/libs/commit/0333501cf429c045c61aaf5909812156f090786e
>
> Do you see any workaround not involving `pgprot_encrypted` ?

If you do have to use remap_pfn_range() to map normal kernel memory,
then you might want to use vma->vm_page_prot instead, like a few other
places in the kernel do.

(Alternatively you might want to use remap_vmalloc_range() to map
vmalloc pages into userspace, but note that that has very different
semantics - I believe that installs a normal page reference rather
than a raw PFN reference, so that would permit get_user_pages() calls
on the range.)