From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Design Decision for KVM based anti rootkit Date: Tue, 19 Jun 2018 18:37:53 +0100 Message-ID: <7337582f-0007-d006-0809-cf41fd93b31e@nutanix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Ahmed Soliman , kvm@vger.kernel.org, Kernel Hardening , riel@redhat.com, Kees Cook , Ard Biesheuvel , Hossam Hassan <7ossam9063@gmail.com>, Ahmed Lotfy , virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: Content-Language: en-US List-Id: kvm.vger.kernel.org On 16/06/18 12:49, Ahmed Soliman wrote: > > To wrap things up, the basic design will be a method for communication > between host and guest is guest can request certain pages to be read > only, and then host will force them to be read-only by guest until > next guest reboot, then it will impossible for guest OS to have them > as RW again. The choice of which pages to be set as read only is the > guest's. So this way mixed pages can still be mixed with R/W content > even if holds kernel code. It's not clear how this increases security. What threats is this protecting again? As an attacker, modifying the sensitive pages (kernel text?) will require either: a) altering the existing mappings for these (to make them read-write or user-writable for example); or b) creating aliased mappings with suitable permissions. If the attacker can modify page tables in this way then it can also bypass the suggested hypervisor's read-only protection by changing the mappings to point to a unprotected page. David From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVKaU-00082J-J7 for qemu-devel@nongnu.org; Tue, 19 Jun 2018 13:38:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVKaR-0006hZ-Bk for qemu-devel@nongnu.org; Tue, 19 Jun 2018 13:38:38 -0400 Received: from mx0b-002c1b01.pphosted.com ([148.163.155.12]:35488) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fVKaQ-0006gt-J6 for qemu-devel@nongnu.org; Tue, 19 Jun 2018 13:38:35 -0400 References: From: David Vrabel Message-ID: <7337582f-0007-d006-0809-cf41fd93b31e@nutanix.com> Date: Tue, 19 Jun 2018 18:37:53 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Design Decision for KVM based anti rootkit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ahmed Soliman , kvm@vger.kernel.org, Kernel Hardening , riel@redhat.com, Kees Cook , Ard Biesheuvel , Hossam Hassan <7ossam9063@gmail.com>, Ahmed Lotfy , virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org On 16/06/18 12:49, Ahmed Soliman wrote: > > To wrap things up, the basic design will be a method for communication > between host and guest is guest can request certain pages to be read > only, and then host will force them to be read-only by guest until > next guest reboot, then it will impossible for guest OS to have them > as RW again. The choice of which pages to be set as read only is the > guest's. So this way mixed pages can still be mixed with R/W content > even if holds kernel code. It's not clear how this increases security. What threats is this protecting again? As an attacker, modifying the sensitive pages (kernel text?) will require either: a) altering the existing mappings for these (to make them read-write or user-writable for example); or b) creating aliased mappings with suitable permissions. If the attacker can modify page tables in this way then it can also bypass the suggested hypervisor's read-only protection by changing the mappings to point to a unprotected page. David