Messages in this thread | | | From | Peter Gonda <> | Date | Fri, 15 Apr 2022 10:20:40 -0600 | Subject | Re: [PATCH v2] crypto: ccp - Fix the INIT_EX data file open failure |
| |
On Fri, Apr 15, 2022 at 7:49 AM Tom Lendacky <thomas.lendacky@amd.com> 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@google.com> > > Reviewed-by: Peter Gonda <pgonda@google.com> > > 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?
| |