Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [RESEND RFC 0/2] Paravirtualized Control Register pinning
From:   Liran Alon <liran.alon@oracle.com>
In-Reply-To: <F82D153A-F083-432B-864C-1CF6A02C19DD@oracle.com>
Date:   Wed, 25 Dec 2019 00:56:03 +0200
Cc:     John Andersen <john.s.andersen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>, mingo@redhat.com,
        bp@alien8.de, x86@kernel.org, pbonzini@redhat.com, hpa@zytor.com,
        sean.j.christopherson@intel.com, vkuznets@redhat.com,
        wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <12D7EEB4-C77E-4BD1-AF61-8B0FBBA2ED05@oracle.com>
References: <20191220192701.23415-1-john.s.andersen@intel.com>
 <F82D153A-F083-432B-864C-1CF6A02C19DD@oracle.com>
To:     Liran Alon <liran.alon@oracle.com>,
        kernel-hardening@lists.openwall.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

+kernel-hardening mailing list.

> On 23 Dec 2019, at 16:30, Liran Alon <liran.alon@oracle.com> wrote:
>=20
>=20
>=20
>> On 20 Dec 2019, at 21:26, John Andersen <john.s.andersen@intel.com> =
wrote:
>>=20
>> Paravirtualized Control Register pinning is a strengthened version of
>> existing protections on the Write Protect, Supervisor Mode Execution =
/
>> Access Protection, and User-Mode Instruction Prevention bits. The
>> existing protections prevent native_write_cr*() functions from =
writing
>> values which disable those bits. This patchset prevents any guest
>> writes to control registers from disabling pinned bits, not just =
writes
>> from native_write_cr*(). This stops attackers within the guest from
>> using ROP to disable protection bits.
>>=20
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__web.archive.org_web=
_20171029060939_http-3A__www.blackbunny.io_linux-2Dkernel-2Dx86-2D64-2Dbyp=
ass-2Dsmep-2Dkaslr-2Dkptr-5Frestric_&d=3DDwIDAg&c=3DRoP1YumCXCgaWHvlZYR8PZ=
h8Bv7qIrMUB65eapI_JnE&r=3DJk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=3D=
-H3SsRpu0sEBqqn9-OOVimBDXk6TimcJerlu4-ko5Io&s=3DTrjU4_UEZIoYjxtoXcjsA8Riu0=
QZ8eI7a4fH96hSBQc&e=3D=20
>>=20
>> The protection is implemented by adding MSRs to KVM which contain the
>> bits that are allowed to be pinned, and the bits which are pinned. =
The
>> guest or userspace can enable bit pinning by reading MSRs to check
>> which bits are allowed to be pinned, and then writing MSRs to set =
which
>> bits they want pinned.
>>=20
>> Other hypervisors such as HyperV have implemented similar protections
>> for Control Registers and MSRs; which security researchers have found
>> effective.
>>=20
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.abatchy.com_201=
8_01_kernel-2Dexploitation-2D4&d=3DDwIDAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7q=
IrMUB65eapI_JnE&r=3DJk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=3D-H3SsR=
pu0sEBqqn9-OOVimBDXk6TimcJerlu4-ko5Io&s=3DFg3e-BSUebNg44Ocp_y19xIoK0HJEHPW=
2AgM958F3Uc&e=3D=20
>>=20
>=20
> I think it=E2=80=99s important to mention how Hyper-V implements this =
protection as it is done in a very different architecture.
>=20
> Hyper-V implements a set of PV APIs named VSM (Virtual Secure Mode) =
aimed to allow a guest (partition) to separate itself to multiple =
security domains called VTLs (Virtual Trust Level).
> The VSM API expose an interface to higher VTLs to control the =
execution of lower VTLs. In theory, VSM supports up to 16 VTLs, but =
Windows VBS (Virtualization Based Security) that is
> the only current technology which utilise VSM, use only 2 VTLs. VTL0 =
for most of OS execution (Normal-Mode) and VTL1 for a secure OS =
execution (Secure-Mode).
>=20
> Higher VTL controls execution of lower VTL by the following VSM =
mechanisms:
> 1) Memory Access Protections: Allows higher VTL to restrict memory =
access to physical pages. Either making them inaccessible or limited to =
certain permissions.
> 2) Secure Intercepts: Allows a higher VTL to request hypervisor to =
intercept certain events in lower VTLs for handling by higher VTL. This =
includes access to system registers (e.g. CRs & MSRs).
>=20
> VBS use above mentioned mechanisms as follows:
> a) Credentials Guard: Prevents pass-the-hash attacks. Done by =
encrypting credentials using a VTL1 trustlet to encrypt them by an =
encryption-key stored in VTL1-only accessible memory.
> b) HVCI (Hypervisor-based Code-Integrity): Prevents execution of =
unsigned code. Done by marking all EPT entries with NX until signature =
verified by VTL1 service. Once verified, mark EPT entries as RO+X.
> (HVCI also supports enforcing code-signing only on Ring0 code =
efficiently by utilising Intel MBEC or AMD GMET CPU features. Which =
allows setting NX-bit on EPT entries based on guest CPL).
> c) KDP (Kernel Data Protection): Marks certain pages after =
initialisation as read-only on VTL0 EPT.
> d) kCFG (Kernel Control-Flow Guard): VTL1 protects bitmap,specifying =
valid indirect branch targets, by protecting it with read-only on VTL0 =
EPT.
> e) HyperGuard: VTL1 use =E2=80=9CSecure Intercepts=E2=80=9D mechanism =
to prevent VTL0 from modifying important system registers. Including CR0 =
& CR4 as done by this patch.
>    HyperGuard also implements a mechanism named NPIEP (Non-Privileged =
Instruction Execution Prevention) that prevents VTL0 Ring3 executing =
SIDT/SGDT/SLDT/STR to leak Ring0 addresses.
>=20
> To sum-up, In Hyper-V, the hypervisor expose a relatively thin API to =
allow guest to partition itself to multiple security domains (enforced =
by virtualization).
> Using this framework, it=E2=80=99s possible to implement multiple =
OS-level protection mechanisms. Only one of them are pinning certain =
registers to specific values as done by this patch.
>=20
> Therefore, as I also tried to say in recent KVM Forum, I think KVM =
should consider exposing a VSM-like API to guest to allow various guest =
OS,
> Including Linux, to implement VBS-like features. To decide on how this =
API should look like, we need to have a more broad discussion with Linux
> Security maintainers and KVM maintainers on which security features we =
would like to implement using such API and what should be their =
architecture.
> Then, we can implement this API in KVM and start to gradually =
introduce more security features in Linux which utilise this API.
>=20
> Once Linux will have security features implemented with this new KVM =
API, we could also consider implementing them on top of other similar =
hypervisor APIs
> such as Hyper-V VSM. To achieve, for example, Linux being more secure =
when running on Microsoft Azure compute instances.
>=20
> Therefore, I see this patch as a short-term solution to quickly gain =
real security value on a very specific issue.
> But if we are serious about improving Linux security using =
Virtualization, we should have this more broad discussion.
>=20
> -Liran
>=20