On Thu, 1 Aug 2024 15:20:30 +0200 Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > On 8/1/24 1:25 PM, Claudio Imbrenda wrote: > > The return value uv_set_shared() and uv_remove_shared() (which are > > wrappers around the share() function) is not always checked. The system > > integrity of a protected guest depends on the Share and Unshare UVCs > > being successful. This means that any caller that fails to check the > > return value will compromise the security of the protected guest. > > > > No code path that would lead to such violation of the security > > guarantees is currently exercised, since all the areas that are shared > > never get unshared during the lifetime of the system. This might > > change and become an issue in the future. > > For people wondering what the effects might be, this is the important > paragraph to read. Fortunately we're currently not unsharing anything. > > Claudio already stated that there's no way out of this but I want to > reiterate on this. The hypervisor has to mess up quite badly to force a > rc > 0 for the guest. Likewise the guest has to mess up memory > management to achieve a rc > 0. > > The only time where the cause of the rc can be fixed is when the > hypervisor is malicious and tracks its changes. In all other cases we > won't know why we ended up with a rc and it makes sense to stop the VM > before something worse happens. > > > @Claudio: > The patch subject is a bit non-specific. > How about: > "s390/uv: Panic for set and remove shared access UVC errors" feel free to fix the subject when picking (unless you really want me to send a v2) > > With that fixed: > Reviewed-by: Janosch Frank <frankja@xxxxxxxxxxxxx> >
