From: Janosch Frank <frankja@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
hca@linux.ibm.com, agordeev@linux.ibm.com, gor@linux.ibm.com,
borntraeger@de.ibm.com, svens@linux.ibm.com,
seiden@linux.ibm.com, nsg@linux.ibm.com, nrb@linux.ibm.com
Subject: Re: [PATCH v1 1/1] s390/uv: Panic if the security of the system cannot be guaranteed.
Date: Thu, 1 Aug 2024 15:20:30 +0200 [thread overview]
Message-ID: <7f98cb85-de83-41ea-aaab-d76a22647ccb@linux.ibm.com> (raw)
In-Reply-To: <20240801112548.85303-1-imbrenda@linux.ibm.com>
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"
With that fixed:
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
next prev parent reply other threads:[~2024-08-01 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 11:25 [PATCH v1 1/1] s390/uv: Panic if the security of the system cannot be guaranteed Claudio Imbrenda
2024-08-01 13:20 ` Janosch Frank [this message]
2024-08-05 10:46 ` Claudio Imbrenda
2024-08-02 12:40 ` Steffen Eiden
2024-08-02 13:11 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f98cb85-de83-41ea-aaab-d76a22647ccb@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=nsg@linux.ibm.com \
--cc=seiden@linux.ibm.com \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox