linux-kernel - Re: [PATCH v1 1/1] s390/uv: Panic if the security of the system cannot be guaranteed.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240805124601.331660f2@p-imbrenda.boeblingen.de.ibm.com>
Date: Mon, 5 Aug 2024 12:46:01 +0200
From: Claudio Imbrenda <imbrenda@...ux.ibm.com>
To: Janosch Frank <frankja@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-s390@...r.kernel.org, hca@...ux.ibm.com, agordeev@...ux.ibm.com,
        gor@...ux.ibm.com, borntraeger@...ibm.com, svens@...ux.ibm.com,
        seiden@...ux.ibm.com, nsg@...ux.ibm.com, nrb@...ux.ibm.com
Subject: Re: [PATCH v1 1/1] s390/uv: Panic if the security of the system
 cannot be guaranteed.

On Thu, 1 Aug 2024 15:20:30 +0200
Janosch Frank <frankja@...ux.ibm.com> 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@...ux.ibm.com>
>