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: <975a0c6f-fdff-556f-b447-06edf24141df@linux.alibaba.com>
Date:   Fri, 25 Oct 2019 10:24:14 +0800
From:   Shannon Zhao <shannon.zhao@...ux.alibaba.com>
To:     James Morse <james.morse@....com>
Cc:     kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
        suzuki.poulose@....com, christoffer.dall@....com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC 0/7] Support KVM being compiled as a kernel module on
 arm64

Hi James,

On 2019/10/24 18:58, James Morse wrote:
> Hi Shannon,
> 
> On 24/10/2019 11:27, Shannon Zhao wrote:
>> Curently KVM ARM64 doesn't support to compile as a kernel module. It's
>> useful to compile KVM as a module.
> 
>> For example, it could reload kvm without rebooting host machine.
> 
> What problem does this solve?
> 
> KVM has some funny requirements that aren't normal for a module. On v8.0 hardware it must
> have an idmap. Modules don't usually expect their code to be physically contiguous, but
> KVM does. KVM influences they way some of the irqchip stuff is set up during early boot
> (EOI mode ... not that I understand it).
> 
> (I think KVM-as-a-module on x86 is an artifact of how it was developed)
> 
> 
>> This patchset support this feature while there are some limitations
>> to be solved. But I just send it out as RFC to get more suggestion and
>> comments.
> 
>> Curently it only supports for VHE system due to the hyp code section
>> address variables like __hyp_text_start.
> 
> We still need to support !VHE systems, and we need to do it with a single image.
> 
I didn't make it clear. With this patchset we still support !VHE systems 
by choose CONFIG_KVM_ARM_HOST as y and by default CONFIG_KVM_ARM_HOST is 
y. And during module init, I add a check to avoid wrong usage for kvm 
module.

if (IS_MODULE(CONFIG_KVM_ARM_HOST) && !is_kernel_in_hyp_mode()) {
         kvm_err("kvm arm kernel module only supports for VHE system\n");
         return -ENODEV;
}


> 
>> Also it can't call
>> kvm_update_va_mask when loading kvm module and kernel panic with below
>> errors. So I make kern_hyp_va into a nop funtion.
> 
> Making this work for the single-Image on v8.0 is going to be a tremendous amount of work.
> What is the payoff?
> 
Actually we can limit this feature only working for VHE systems and 
don't influence !VHE systems.

Thanks,
Shannon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ