linux-kernel - Re: [PATCH v2 05/13] KVM: s390: pv: handle secure storage exceptions for normal guests

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <103c158c-dba6-7421-af8d-4d771c1cf087@linux.ibm.com>
Date:   Thu, 29 Jul 2021 14:17:11 +0200
From:   Janosch Frank <frankja@...ux.ibm.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>, kvm@...r.kernel.org
Cc:     cohuck@...hat.com, borntraeger@...ibm.com, thuth@...hat.com,
        pasic@...ux.ibm.com, david@...hat.com, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 05/13] KVM: s390: pv: handle secure storage exceptions
 for normal guests

On 7/28/21 4:26 PM, Claudio Imbrenda wrote:
> With upcoming patches, normal guests might touch secure pages.
> 
> This patch extends the existing exception handler to convert the pages
> to non secure also when the exception is triggered by a normal guest.
> 
> This can happen for example when a secure guest reboots; the first
> stage of a secure guest is non secure, and in general a secure guest
> can reboot into non-secure mode.
> 
> If the secure memory of the previous boot has not been cleared up
> completely yet, a non-secure guest might touch secure memory, which
> will need to be handled properly.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
> ---
>  arch/s390/mm/fault.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index eb68b4f36927..b89d625ea2ec 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -767,6 +767,7 @@ void do_secure_storage_access(struct pt_regs *regs)
>  	struct vm_area_struct *vma;
>  	struct mm_struct *mm;
>  	struct page *page;
> +	struct gmap *gmap;
>  	int rc;
>  
>  	/*
> @@ -796,6 +797,16 @@ void do_secure_storage_access(struct pt_regs *regs)
>  	}
>  
>  	switch (get_fault_type(regs)) {
> +	case GMAP_FAULT:
> +		gmap = (struct gmap *)S390_lowcore.gmap;
> +		/*
> +		 * Very unlikely, but if it happens, simply try again.
> +		 * The next attempt will trigger a different exception.
> +		 */

If we keep this the way it currently is then the comment needs to go to
the EFAULT check since it makes no sense above the gmap_translate().

> +		addr = __gmap_translate(gmap, addr);

So we had a valid gmap PTE to end up here where the guest touched a
secure page and triggered the exception. But we suddenly can't translate
the gaddr to a vmaddr because the gmap tracking doesn't have an entry
for the address.

My first instinct is to SIGSEGV the process since I can't come up with a
way out of this situation except for the process to map this back in.
The only reason I can think of that it was removed from the mapping is
malicious intent or a bug.

I think this is needs a VM_FAULT_BADMAP and a do_fault_error() call.

> +		if (addr == -EFAULT)
> +			break;
> +		fallthrough;
>  	case USER_FAULT:
>  		mm = current->mm;
>  		mmap_read_lock(mm);
> @@ -824,7 +835,6 @@ void do_secure_storage_access(struct pt_regs *regs)
>  		if (rc)
>  			BUG();
>  		break;
> -	case GMAP_FAULT:
>  	default:
>  		do_fault_error(regs, VM_READ | VM_WRITE, VM_FAULT_BADMAP);
>  		WARN_ON_ONCE(1);
>