On 4/15/22 11:20, Peter Gonda wrote:
On Fri, Apr 15, 2022 at 7:49 AM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
On 4/14/22 11:23, Jacky Li wrote:
There are 2 common cases when INIT_EX data file might not be
opened successfully and fail the sev initialization:
1. In user namespaces, normal user tasks (e.g. VMM) can change their
current->fs->root to point to arbitrary directories. While
init_ex_path is provided as a module param related to root file
system. Solution: use the root directory of init_task to avoid
accessing the wrong file.
2. Normal user tasks (e.g. VMM) don't have the privilege to access
the INIT_EX data file. Solution: open the file as root and
restore permissions immediately.
Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support")
Signed-off-by: Jacky Li <jackyli@xxxxxxxxxx>
Reviewed-by: Peter Gonda <pgonda@xxxxxxxxxx>
Looks good, just a quick question. Should there be any type of access
checks before switching credentials? Should we check access to /dev/sev or
such? Or is the capability to load the module enough?
I thought this was fine because regardless of if an admin sets
psp_init_on_probe=true or false, their intention is that people who
have rw access to /dev/sev can use the commands which require the PSP
to be init. In the case of psp_init_on_probe=false only rw users can
cause the file to be created. The case of psp_init_on_probe=true seems
a little less clear to me but if a user can modprobe ccp that seems
like sufficient privilege to create the file. What do you think, Tom?
Sorry, lost this in my Inbox... That seems reasonable to me, let me add
my ack to the first email.
Thanks,
Tom
