linux-kernel - Re: SEV guest regression in 4.18

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:   Tue, 21 Aug 2018 09:37:56 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     brijesh.singh@....com, "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Pavel Tatashin <pasha.tatashin@...cle.com>
Subject: Re: SEV guest regression in 4.18

Hi Boris,


On 08/21/2018 03:39 AM, Borislav Petkov wrote:
> On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
>> Hi All,
>>
>> The following commit
>>
>> "
>> x86/kvmclock: Remove memblock dependency
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
>>
>> "
>> broke the SEV support in 4.18.
>>
>> Since the guest physical address holding the wall_clock and
>> vcpu_time_info are shared with the hypervisor  it must be mapped
>> as "decrypted" when SEV is active. To clear the C-bit we use
>> kernel_physical_mapping_init() to split the large pages into 4K before
>> changing the C-bit. Now the kernel_physical_mapping_init() is failing to
>> allocate the memory because its called very early.
>>
>> [    0.000000] Call Trace:
>> [    0.000000]  ? dump_stack+0x5c/0x80
>> [    0.000000]  ? panic+0xe7/0x247
>> [    0.000000]  ? alloc_low_pages+0x130/0x130
>> [    0.000000]  ? kernel_physical_mapping_init+0xe0/0x204
>> [    0.000000]  ? early_set_memory_enc_dec+0x123/0x174
>> [    0.000000]  ? 0xffffffffae000000
>> [    0.000000]  ? kvmclock_init+0x60/0x1ea
>> [    0.000000]  ? kvm_init_platform+0xa/0x16
>> [    0.000000]  ? setup_arch+0x434/0xce9
>> [    0.000000]  ? start_kernel+0x67/0x52e
>> [    0.000000]  ? load_ucode_bsp+0x76/0x12e
>> [    0.000000]  ? secondary_startup_64+0xa4/0xb0
> 
> Silly question: can we delay the call to kernel_physical_mapping_init()
> to right before those variables are accessed by the guest for the first
> time, assuming we can allocate memory at that point?
> 


Those variables are accessed immediately by the tsc calibration code
path hence we will not able to delay the allocation. Before the above
patch series, kvmclock_init() and early tsc calibration was called a
bit late in setup_arch() hence it all worked fine.

-Brijesh