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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists