linux-kernel - Re: [RESEND PATCH V8 05/11] KVM: Create architecture independent ROE skeleton

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] [day] [month] [year] [list]

Message-ID: <20190122031049.GA18314@gao-cwp>
Date:   Tue, 22 Jan 2019 11:10:50 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     Ahmed Abd El Mawgood <ahmedsoliman@...a.vt.edu>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, rkrcmar@...hat.com,
        Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        hpa@...or.com, x86@...nel.org, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        ahmedsoliman0x666@...il.com, ovich00@...il.com,
        kernel-hardening@...ts.openwall.com, nigel.edwards@....com,
        Boris Lukashev <blukashev@...pervictus.com>,
        Igor Stoppa <igor.stoppa@...il.com>
Subject: Re: [RESEND PATCH V8 05/11] KVM: Create architecture independent ROE
 skeleton

On Mon, Jan 21, 2019 at 01:39:34AM +0200, Ahmed Abd El Mawgood wrote:
>This patch introduces a hypercall that can assist against subset of kernel
>rootkits, it works by place readonly protection in shadow PTE. The end
>result protection is also kept in a bitmap for each kvm_memory_slot and is
>used as reference when updating SPTEs. The whole goal is to protect the
>guest kernel static data from modification if attacker is running from
>guest ring 0, for this reason there is no hypercall to revert effect of
>Memory ROE hypercall. This patch doesn't implement integrity check on guest
>TLB so obvious attack on the current implementation will involve guest
>virtual address -> guest physical address remapping, but there are plans to
>fix that.

Hello Ahmed,

I don't quite understand the attack. Do you mean that even one guest
page is protected by ROE, an attacker can map the virtual address to
another unprotected guest page by editing guest page table?

Thanks
Chao