linux-kernel - Re: pgprot_encrypted macro is broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG48ez2OcfTQ4SRbY89uHDJG6QujSfChaO4B3=zgGpj=9J8bdA@mail.gmail.com>
Date:   Mon, 20 Jun 2022 13:32:06 +0200
From:   Jann Horn <jannh@...gle.com>
To:     Federico Di Pierro <nierro92@...il.com>
Cc:     Linux API <linux-api@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: pgprot_encrypted macro is broken

On Mon, Jun 20, 2022 at 9:39 AM Federico Di Pierro <nierro92@...il.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.)