linux-kernel - Re: [PATCH 4/4] x86,module: Detect CRn and DRn manipulation

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: <92E51AF2-D763-4B73-A573-6E24A6B46831@gmail.com>
Date:   Thu, 9 Apr 2020 22:37:12 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Christoph Hellwig <hch@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        mingo <mingo@...hat.com>, bp <bp@...en8.de>, hpa@...or.com,
        x86 <x86@...nel.org>, "Kenneth R. Crudup" <kenny@...ix.com>,
        Jessica Yu <jeyu@...nel.org>,
        Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Tony Luck <tony.luck@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        jannh@...gle.com, keescook@...omium.org, David.Laight@...lab.com,
        Doug Covelli <dcovelli@...are.com>, mhiramat@...nel.org
Subject: Re: [PATCH 4/4] x86,module: Detect CRn and DRn manipulation

> On Apr 9, 2020, at 3:18 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Thu, 09 Apr 2020 23:13:22 +0200
> Thomas Gleixner <tglx@...utronix.de> wrote:
>> 
>> __vmx_vcpu_run() is roughly the scope, but that wont work.
>> 
>> Looking at the vmmon source:
>> 
>> 

[ Snip ]

>> 
>>    8) Invoke monitor on some magic page which switches CR3 and GDT and
>>       clears CR4.PCIDE (at least thats what the comments claim)
>> 
>>       The monitor code is loaded from a binary only blob and that does
>>       the actual vmlaunch/vmresume ...
> 
> From what I understand (never looked at the code), is that this binary blob
> is the same for Windows and Apple. It's basically its own operating system
> that does all the work and vmmon is the way to switch to and from it. When
> this blob gets an interrupt that it doesn't know about, it assumes it
> belongs to the operating system its sharing the machine with and exits back
> to it, whether that's Linux, Windows or OSX.
> 
> It's not too unlike what jailhouse does with its hypervisor, to take over
> the machine and place the running Linux into its own "cell", except that it
> will switch full control of the machine back to Linux.
> 
> -- Steve
> 
> 
>>       And as this runs with a completely different CR3 sharing that
>>       code is impossible.

To complement Steven’s response, we are fully aware in VMware about this
issue since the patches were sent, and the hypervisor developers consider
how to address it. Indeed, vmmon does something similar to VirtualBox and
Jailhouse. The planned restriction on the creation of executable mappings by
modules would require changes in all of these hypervisors.

Actually, IIUC, even Mircosoft Hyper-V might be broken by the proposed
changes that prevent the creation of executable mappings. It may appear as
if there is no issue since the __vmalloc() that hyperv_init() uses in the
kernel to setup the hypercall pages will be changed into vmalloc_exec() [1].
But, AFAICT Microsoft can also setup the hypercall page in a module as part
of its Linux Integration Services. This code uses
__vmalloc(…PAGE_KERNEL_RX), and would therefore be broken. [2]

It seems to me that the proposed restrictions on which instructions a module
is allowed to run are completely new, have significant implications, and
therefore would hopefully not be rushed in. Alternatively, a transition
period in which the checks only trigger warnings would be beneficial.

I am not a developer of the VMware hypervisor, but my understanding is that
developers have every intention to fully comply with the new restrictions on
memory mappings and instructions that a module is allowed to run. They can
consider sharing VM-entry/exit code with KVM even if requires code changes
for VMware. They just ask for sufficient time to make the required
adaptations. It would help to have a reasonable timeline for when each
of the proposed changes (__vmalloc(), MOV-CR/DR, other instructions)
is expected to be merged.

[1] https://lore.kernel.org/lkml/20200408115926.1467567-2-hch@lst.de/
[2] https://github.com/LIS/lis-next/blob/master/hv-rhel7.x/hv/arch/x86/hyperv/hv_init.c#L187