linux-kernel - Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

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: <c25989fb-b1da-ea88-37de-6c36ecdf72d2@citrix.com>
Date:   Wed, 2 May 2018 16:28:18 +0100
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Jan Beulich <JBeulich@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
CC:     Juergen Gross <jgross@...e.com>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long
 mode

On 02/05/18 16:09, Jan Beulich wrote:
>>>> On 02.05.18 at 17:08, <boris.ostrovsky@...cle.com> wrote:
>> On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>>>> On 02.05.18 at 16:57, <boris.ostrovsky@...cle.com> wrote:
>>>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>>>> On 30.04.18 at 18:23, <boris.ostrovsky@...cle.com> wrote:
>>>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>
>>>>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
>>>>>
>>>>> But to understand why things have been working nevertheless it would
>>>>> have been nice if the commit message wasn't empty, but instead said
>>>>> something like "The two happen to be identical on 64-bit."
>>>> Why do you think they are identical? __KERNEL_CS points to entry#12
>>>> (which we don't specify in PVH GDT) while __BOOT_CS is the second entry
>>>> (which we do create).
>>> That's 32-bit's __KERNEL_CS. If the two weren't identical, the ljmp
>>> you adjust would never have worked afaict.
>>
>> Oh, right. My theory was that we were picking up something from the
>> stack (which is where 12th entry would be pointing) and the L bit, which
>> I think is the only one we'd care about, happened to always be set there.
> I don't think the L bit is the only one we care about, as I don't think you
> can load a non-code selector into CS (even if none of the attributes are
> later used for anything).

The type/s/dpl/p/d/l attributes still very much matter even in 64bit.

~Andrew