linux-kernel - Re: [PATCH v2 1/5] KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks

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]

Date:   Fri, 3 Apr 2020 21:55:02 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.com>
Cc:     David Hildenbrand <david@...hat.com>, kvm@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Janosch Frank <frankja@...ux.ibm.com>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/5] KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks



> Am 03.04.2020 um 19:56 schrieb Christian Borntraeger <borntraeger@...ibm.com>:
> 
> 
> 
>> On 03.04.20 17:30, David Hildenbrand wrote:
>> In case we have a region 1 ASCE, our shadow/g3 address can have any value.
>> Unfortunately, (-1UL << 64) is undefined and triggers sometimes,
>> rejecting valid shadow addresses when trying to walk our shadow table
>> hierarchy.
> 
> I thin the range of the addresses do not matter.
> Took me a while to understand maybe rephrase that:
> 
> In case we have a region 1 the following calculation 
> (31 + ((gmap->asce & _ASCE_TYPE_MASK) >> 2)*11)
> results in 64. As shifts beyond the size are undefined the compiler is free to use
> instructions like sllg. sllg will only use 6 bits of the shift value (here 64)
> resulting in no shift at all. That means that ALL addresses will be rejected.

Interestingly, it would not fail when shadowing the r2t, but only when trying to shadow the r3t.

> 
> With that this makes sense. 
> 
> Reviewed-by: Christian Borntraeger <borntraeger@...ibm.com>
> 

In case there are no other comments, can you fixup when applying, or do you want me to resend?

Cheers