On 9/2/20 9:35 PM, Andy Lutomirski wrote:
Having read the code, I’m unconvinced. It looks like a get_xsave_addr() failure means “state not saved; task sees INIT state”. So *maybe* it’s reasonable -ENODEV this, but I’m not really convinced. I tend to think we should return the actual INIT state and that we should permit writes and handle them correctly.When a thread is not CET-enabled, its CET state does not exist. I looked at EFAULT, and it means "Bad address". Maybe this can be ENODEV, which means "No such device"?+ fpu__prepare_read(fpu);Can this branch ever be hit without a kernel bug? If yes, I think
+ cetregs = get_xsave_addr(&fpu->state.xsave, XFEATURE_CET_USER);
+ if (!cetregs)
+ return -EFAULT;
-EFAULT is probably a weird error code to choose here. If no, this
should probably use WARN_ON(). Same thing in cetregs_set().
PTRACE is asking for access to the values in the *registers*, not for
the value in the kernel XSAVE buffer. We just happen to only have the
kernel XSAVE buffer around.
If we want to really support PTRACE we have to allow the registers to be
get/set, regardless of what state they are in, INIT state or not. So,
yeah I agree with Andy.