From: "Stecklina, Julian" <jsteckli@amazon.de>
To: "corbet@lwn.net" <corbet@lwn.net>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ahmedsoliman0x666@gmail.com" <ahmedsoliman0x666@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"ovich00@gmail.com" <ovich00@gmail.com>,
"x86@kernel.org" <x86@kernel.org>,
"igor.stoppa@gmail.com" <igor.stoppa@gmail.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"nigel.edwards@hpe.com" <nigel.edwards@hpe.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"ahmedsoliman@mena.vt.edu" <ahmedsoliman@mena.vt.edu>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"blukashev@sempervictus.com" <blukashev@sempervictus.com>
Subject: Re: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening
Date: Thu, 13 Dec 2018 13:36:27 +0000 [thread overview]
Message-ID: <1544708187.5826.1.camel@amazon.de> (raw)
In-Reply-To: <20181207124803.10828-1-ahmedsoliman@mena.vt.edu>
Ahmed,
On Fri, 2018-12-07 at 14:47 +0200, Ahmed Abd El Mawgood wrote:
> The reason why it would be better to implement this from inside kvm: instead
> of
> (host) user space is the need to access SPTEs to modify the permissions, while
> mprotect() from user space can work in theory. It will become a big
> performance
> hit to vmexit and switch to user space mode on each fault, on the other hand,
> having the permission handled by EPT should make some remarkable performance
> gain.
Given that writes to these areas should be exceptional occurrences, 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?
Julian
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
WARNING: multiple messages have this Message-ID (diff)
From: "Stecklina, Julian" <jsteckli@amazon.de>
To: "corbet@lwn.net" <corbet@lwn.net>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ahmedsoliman0x666@gmail.com" <ahmedsoliman0x666@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"ovich00@gmail.com" <ovich00@gmail.com>,
"x86@kernel.org" <x86@kernel.org>,
"igor.stoppa@gmail.com" <igor.stoppa@gmail.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"nigel.edwards@hpe.com" <nigel.edwards@hpe.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"ahmedsoliman@mena.vt.edu" <ahmedsoliman@mena.vt.edu>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
"linux-doc@vger
Subject: Re: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening
Date: Thu, 13 Dec 2018 13:36:27 +0000 [thread overview]
Message-ID: <1544708187.5826.1.camel@amazon.de> (raw)
In-Reply-To: <20181207124803.10828-1-ahmedsoliman@mena.vt.edu>
Ahmed,
On Fri, 2018-12-07 at 14:47 +0200, Ahmed Abd El Mawgood wrote:
> The reason why it would be better to implement this from inside kvm: instead
> of
> (host) user space is the need to access SPTEs to modify the permissions, while
> mprotect() from user space can work in theory. It will become a big
> performance
> hit to vmexit and switch to user space mode on each fault, on the other hand,
> having the permission handled by EPT should make some remarkable performance
> gain.
Given that writes to these areas should be exceptional occurrences, 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?
Julian
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
next prev parent reply other threads:[~2018-12-13 13:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 12:47 [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 01/10] KVM: State whether memory should be freed in kvm_free_memslot Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 02/10] KVM: X86: Add arbitrary data pointer in kvm memslot iterator functions Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 03/10] KVM: X86: Add helper function to convert SPTE to GFN Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 04/10] KVM: Document Memory ROE Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 05/10] KVM: Create architecture independent ROE skeleton Ahmed Abd El Mawgood
2018-12-07 12:47 ` [PATCH 06/10] KVM: X86: Enable ROE for x86 Ahmed Abd El Mawgood
2018-12-07 12:48 ` [PATCH 07/10] KVM: Add support for byte granular memory ROE Ahmed Abd El Mawgood
2018-12-07 12:48 ` [PATCH 08/10] KVM: X86: Port ROE_MPROTECT_CHUNK to x86 Ahmed Abd El Mawgood
2018-12-07 12:48 ` [PATCH 09/10] KVM: Add new exit reason For ROE violations Ahmed Abd El Mawgood
2018-12-07 12:48 ` [PATCH 10/10] KVM: Log ROE violations in system log Ahmed Abd El Mawgood
2018-12-07 16:23 ` RESEND " Ahmed Abd El Mawgood
2018-12-13 13:36 ` Stecklina, Julian [this message]
2018-12-13 13:36 ` [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening Stecklina, Julian
2018-12-13 16:00 ` Ahmed Soliman
2018-12-21 14:05 ` Ahmed Soliman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1544708187.5826.1.camel@amazon.de \
--to=jsteckli@amazon.de \
--cc=ahmedsoliman0x666@gmail.com \
--cc=ahmedsoliman@mena.vt.edu \
--cc=blukashev@sempervictus.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=hpa@zytor.com \
--cc=igor.stoppa@gmail.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nigel.edwards@hpe.com \
--cc=ovich00@gmail.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.