On Mon, Apr 04, 2022 at 03:36:59PM -0700, Dave Hansen wrote:
> On 4/4/22 15:02, Riccardo Schirone wrote:
> > Functions cc_mkenc()/cc_mkdec() were introduced in commit b577f542f93c
> > ("x86/coco: Add API to handle encryption mask") to handle encryption
> > masks in page tables. As part of the above commit only cc_mkdec() was
> > exported, however this creates an asymmetry where a module can use
> > pgprot_decrypted() but not pgprot_encrypted(). Export cc_mkenc() as well
> > to avoid the problem.
> ...
> > As an example of a module using pgprot_encrypted() I tried to compile
> > https://github.com/draios/sysdig but I could not because of missing
> > cc_mkenc().
>
> Thanks for the patch. But, I don't think we can just apply it as-is.
> That "sysdig" thing goes and downloads some random "scap" driver that it
> then compiles. It's pretty opaque what it's actually doing.
You are right, the driver part is split in a separate repository, which should
be this https://github.com/draios/agent-libs .
>
> We don't tend to export functions just because there is *a* user out
> there for it. I went looking for an in-tree user that was doing the
> same thing, but it's impossible to tell.
>
> I also don't see any use of cc_mkenc() in any kernel headers. That's
> the most common way folks might end up using a new symbol accidentally.
>
> Does this affect and in-kernel code?
pgprot_encrypted()/pgprot_decrypted() are fallback-defined in
include/linux/pgtable.h, but in arch/x86/include/asm/pgtable.h they are
defined as:
#define pgprot_encrypted(prot) __pgprot(cc_mkenc(pgprot_val(prot)))
#define pgprot_decrypted(prot) __pgprot(cc_mkdec(pgprot_val(prot)))
AFAIK any code that was using pgprot_decrypted()/pgprot_encrypted() is now
essentially using cc_mkdec()/cc_mkenc(). commit b577f542f93c ("x86/coco: Add
API to handle encryption mask") made cc_mkdec() exported, so one can use
pgprot_decrypted(), which is in include/linux/pgtable.h, but not
pgprot_encrypted().
The reason why I thought this change made sense is just because I think the
two operations should be mostly the same and if one can do one operation, he
should be able to access also the other as they are defined in the same header
file.
Please let me know if I should find other ways to fix the problem and thanks
for your review.
--
Riccardo Schirone
