Re: pgprot_encrypted macro is broken

[Federico Di Pierro]

Hi!

Thank you very much for your hints and for your time!
I solved the issue and I agree that we should not have used that macro
in the first place.

Again, thank you very much for your help,
Regards
Federico

Il giorno lun 20 giu 2022 alle ore 13:32 Jann Horn <jannh@xxxxxxxxxx>
ha scritto:
>
> On Mon, Jun 20, 2022 at 9:39 AM Federico Di Pierro <nierro92@xxxxxxxxx> 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.)