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]
Date:   Wed, 6 Sep 2017 10:03:27 -0400
From:   Boris Ostrovsky <>
To:     Thomas Gleixner <>
Cc:     Borislav Petkov <>,,
        X86 ML <>,
        "" <>,
        Ingo Molnar <>,
        "H. Peter Anvin" <>
Subject: Re: SME/32-bit regression

On 09/06/2017 09:57 AM, Thomas Gleixner wrote:
> On Wed, 6 Sep 2017, Boris Ostrovsky wrote:
>> On 09/06/2017 05:26 AM, Borislav Petkov wrote:
>>> On Tue, Sep 05, 2017 at 11:45:07PM -0400, Boris Ostrovsky wrote:
>>>> It appears there is a regression for 32-bit kernels due to SME changes.
>>>> I bisected my particular problem
>>> It being? Doesn't boot, splats?
>> Xen guest crashes very early, before a splat can can be generated.
>>>> (Xen PV guest) to
>>>> 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad()
>>>> errors on baremetal. This seems to be caused by sme_me_mask being an
>>>> unsigned long as opposed to phys_addr_t (the actual problem is that
>>>> __PHYSICAL_MASK is truncated). When I declare it as u64 and drop unsigned
>>>> long cast in __sme_set()/__sme_clr() the problem goes way. (This presumably
>>>> won't work for non-PAE which I haven't tried).
>>> Right, so I think we should do this because those macros should not have
>>> any effect on !CONFIG_AMD_MEM_ENCRYPT setups.
>> This won't help though if kernel is built with SME support.
> Which is not the case for 32bit. SME depends on 64bit

Oh, OK, I didn't realize that.


Powered by blists - more mailing lists