linux-kernel - Re: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening

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: <CANBxJ=FP9GSfMES3e5dSct2qV0Z=uz7uPXufQNqoi5e+sWxvgQ@mail.gmail.com>
Date:   Thu, 13 Dec 2018 18:00:05 +0200
From:   Ahmed Soliman <ahmedsoliman@...a.vt.edu>
To:     jsteckli@...zon.de
Cc:     Jonathan Corbet <corbet@....net>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Ahmed Soliman <ahmedsoliman0x666@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        김인겸 <ovich00@...il.com>, x86@...nel.org,
        Igor Stoppa <igor.stoppa@...il.com>, hpa@...or.com,
        Ingo Molnar <mingo@...hat.com>, nigel.edwards@....com,
        Paolo Bonzini <pbonzini@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        kernel-hardening@...ts.openwall.com, rkrcmar@...hat.com,
        linux-doc@...r.kernel.org,
        Boris Lukashev <blukashev@...pervictus.com>
Subject: Re: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening

Hello,

> Given that writes to these areas should be exceptional occurrences,

No not in the case of partially protected page.

> I don't  understand why this path needs to be optimized. To me it seems, a straight-
> forward userspace implementation with no additional code in the kernel achieves
> the same feature. Can you elaborate?

The performance hit I was talking about was when dealing with page with
mixed content, given that page is partially read only and partially writable.
The way this is handled is by emulating the writes from inside kvm, now if this
was done from host's userspace, then every write operating (a size of at most
1 cpu  word I guess ?) will require switching from guest to kvm and then to host
userspace, which is major performance hit. I originally made it for protecting
guest's page table part that shouldn't be remapped ever. Since the page table
gets modified a lot, emulating the writes from host user space instead
of the kernel
would add an unnecessary overhead. Also it doesn't sound right to me
to place the
protection inside the page table when it can be placed inside the
virtualization EPT.

But aside from that, I think I was wrong about hinting that it is
simple when done from
user space, handling cases like THP and huge pages (which I did not support yet)
doesn't seam to be easy when done from user space and when doing Registers
ROE has some arch specific details. That's why I think it is better to
continue doing
it from KVM kernel module.

thanks,
Ahmed