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.
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?
