* Design Decision for KVM based anti rootkit @ 2018-06-16 11:49 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-16 11:49 UTC (permalink / raw) To: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel Following up on these threads: - https://marc.info/?l=kvm&m=151929803301378&w=2 - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 I lost the original emails so I couldn't reply to them, and also sorry for being late, it was the end of semester exams. I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will help having better insights. 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. I was planning to use KVM as my hypervisor, until I found out that KVM can't do that on its own so one will need a custom virtio driver to do this kind of guest-host communication/coordination, I am still sticking to KVM, and have no plans to do this for Xen at least for now, this means that in order to get it to work there must be a QEMU support our specific driver we are planning to write in order for things to work properly. The question is is this the right approach? or is there a simpler way to achieve this goal? ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-16 11:49 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-16 11:49 UTC (permalink / raw) To: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel Following up on these threads: - https://marc.info/?l=kvm&m=151929803301378&w=2 - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 I lost the original emails so I couldn't reply to them, and also sorry for being late, it was the end of semester exams. I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will help having better insights. 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. I was planning to use KVM as my hypervisor, until I found out that KVM can't do that on its own so one will need a custom virtio driver to do this kind of guest-host communication/coordination, I am still sticking to KVM, and have no plans to do this for Xen at least for now, this means that in order to get it to work there must be a QEMU support our specific driver we are planning to write in order for things to work properly. The question is is this the right approach? or is there a simpler way to achieve this goal? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit 2018-06-16 11:49 ` [Qemu-devel] " Ahmed Soliman @ 2018-06-18 14:34 ` David Hildenbrand -1 siblings, 0 replies; 15+ messages in thread From: David Hildenbrand @ 2018-06-18 14:34 UTC (permalink / raw) To: Ahmed Soliman, kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 16.06.2018 13:49, Ahmed Soliman wrote: > Following up on these threads: > - https://marc.info/?l=kvm&m=151929803301378&w=2 > - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 > > I lost the original emails so I couldn't reply to them, and also sorry > for being late, it was the end of semester exams. > > I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will > help having better insights. > > 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. > > I was planning to use KVM as my hypervisor, until I found out that KVM > can't do that on its own so one will need a custom virtio driver to do > this kind of guest-host communication/coordination, I am still > sticking to KVM, and have no plans to do this for Xen at least for > now, this means that in order to get it to work there must be a QEMU > support our specific driver we are planning to write in order for > things to work properly. > > The question is is this the right approach? or is there a simpler way > to achieve this goal? > Especially if you want to support multiple architectures in the long term, virtio is the way to go. Design an architecture independent and extensible (+configurable) interface and be happy :) This might of course require some thought. (and don't worry, implementing a virtio driver is a lot simpler than you might think) But be aware that the virtio "hypervisor" side will be handled in QEMU, so you'll need a proper QEMU->KVM interface to get things running. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-18 14:34 ` David Hildenbrand 0 siblings, 0 replies; 15+ messages in thread From: David Hildenbrand @ 2018-06-18 14:34 UTC (permalink / raw) To: Ahmed Soliman, kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 16.06.2018 13:49, Ahmed Soliman wrote: > Following up on these threads: > - https://marc.info/?l=kvm&m=151929803301378&w=2 > - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 > > I lost the original emails so I couldn't reply to them, and also sorry > for being late, it was the end of semester exams. > > I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will > help having better insights. > > 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. > > I was planning to use KVM as my hypervisor, until I found out that KVM > can't do that on its own so one will need a custom virtio driver to do > this kind of guest-host communication/coordination, I am still > sticking to KVM, and have no plans to do this for Xen at least for > now, this means that in order to get it to work there must be a QEMU > support our specific driver we are planning to write in order for > things to work properly. > > The question is is this the right approach? or is there a simpler way > to achieve this goal? > Especially if you want to support multiple architectures in the long term, virtio is the way to go. Design an architecture independent and extensible (+configurable) interface and be happy :) This might of course require some thought. (and don't worry, implementing a virtio driver is a lot simpler than you might think) But be aware that the virtio "hypervisor" side will be handled in QEMU, so you'll need a proper QEMU->KVM interface to get things running. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit 2018-06-18 14:34 ` [Qemu-devel] " David Hildenbrand (?) @ 2018-06-18 16:35 ` Ahmed Soliman -1 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-18 16:35 UTC (permalink / raw) To: David Hildenbrand Cc: riel, Kees Cook, kvm, Ard Biesheuvel, Kernel Hardening, qemu-devel, virtualization, Hossam Hassan, Ahmed Lotfy Shortly after I sent the first email, we found that there is another way to achieve this kind of communication, via KVM Hypercalls, I think they are underutilised in kvm, but they exist. We also found that they are architecture dependent, but the advantage is that one doesn't need to create QEMU<-> kvm interface So from our point of view it is either have things easily compatible with many architectures out of the box (virtio) VS compatiability with almost every front end including QEMU and any other one without modification (Hypercalls)? If it is the case, We might stick to hypercalls at the beginning, because it can be easily tested with out modifying QEMU, but then later we can move to virtio if there turned out to be clearer advantage, especially performance wise. Does that sounds like good idea? I wanted to make sure because maybe maybe hypercalls aren't that much used in kvm for a reason, so I wanted to verify that. On 18 June 2018 at 16:34, David Hildenbrand <david@redhat.com> wrote: > On 16.06.2018 13:49, Ahmed Soliman wrote: >> Following up on these threads: >> - https://marc.info/?l=kvm&m=151929803301378&w=2 >> - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 >> >> I lost the original emails so I couldn't reply to them, and also sorry >> for being late, it was the end of semester exams. >> >> I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will >> help having better insights. >> >> 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. >> >> I was planning to use KVM as my hypervisor, until I found out that KVM >> can't do that on its own so one will need a custom virtio driver to do >> this kind of guest-host communication/coordination, I am still >> sticking to KVM, and have no plans to do this for Xen at least for >> now, this means that in order to get it to work there must be a QEMU >> support our specific driver we are planning to write in order for >> things to work properly. >> >> The question is is this the right approach? or is there a simpler way >> to achieve this goal? >> > > Especially if you want to support multiple architectures in the long > term, virtio is the way to go. > > Design an architecture independent and extensible (+configurable) > interface and be happy :) This might of course require some thought. > > (and don't worry, implementing a virtio driver is a lot simpler than you > might think) > > But be aware that the virtio "hypervisor" side will be handled in QEMU, > so you'll need a proper QEMU->KVM interface to get things running. > > -- > > Thanks, > > David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit @ 2018-06-18 16:35 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-18 16:35 UTC (permalink / raw) To: David Hildenbrand Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel Shortly after I sent the first email, we found that there is another way to achieve this kind of communication, via KVM Hypercalls, I think they are underutilised in kvm, but they exist. We also found that they are architecture dependent, but the advantage is that one doesn't need to create QEMU<-> kvm interface So from our point of view it is either have things easily compatible with many architectures out of the box (virtio) VS compatiability with almost every front end including QEMU and any other one without modification (Hypercalls)? If it is the case, We might stick to hypercalls at the beginning, because it can be easily tested with out modifying QEMU, but then later we can move to virtio if there turned out to be clearer advantage, especially performance wise. Does that sounds like good idea? I wanted to make sure because maybe maybe hypercalls aren't that much used in kvm for a reason, so I wanted to verify that. On 18 June 2018 at 16:34, David Hildenbrand <david@redhat.com> wrote: > On 16.06.2018 13:49, Ahmed Soliman wrote: >> Following up on these threads: >> - https://marc.info/?l=kvm&m=151929803301378&w=2 >> - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 >> >> I lost the original emails so I couldn't reply to them, and also sorry >> for being late, it was the end of semester exams. >> >> I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will >> help having better insights. >> >> 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. >> >> I was planning to use KVM as my hypervisor, until I found out that KVM >> can't do that on its own so one will need a custom virtio driver to do >> this kind of guest-host communication/coordination, I am still >> sticking to KVM, and have no plans to do this for Xen at least for >> now, this means that in order to get it to work there must be a QEMU >> support our specific driver we are planning to write in order for >> things to work properly. >> >> The question is is this the right approach? or is there a simpler way >> to achieve this goal? >> > > Especially if you want to support multiple architectures in the long > term, virtio is the way to go. > > Design an architecture independent and extensible (+configurable) > interface and be happy :) This might of course require some thought. > > (and don't worry, implementing a virtio driver is a lot simpler than you > might think) > > But be aware that the virtio "hypervisor" side will be handled in QEMU, > so you'll need a proper QEMU->KVM interface to get things running. > > -- > > Thanks, > > David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-18 16:35 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-18 16:35 UTC (permalink / raw) To: David Hildenbrand Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel Shortly after I sent the first email, we found that there is another way to achieve this kind of communication, via KVM Hypercalls, I think they are underutilised in kvm, but they exist. We also found that they are architecture dependent, but the advantage is that one doesn't need to create QEMU<-> kvm interface So from our point of view it is either have things easily compatible with many architectures out of the box (virtio) VS compatiability with almost every front end including QEMU and any other one without modification (Hypercalls)? If it is the case, We might stick to hypercalls at the beginning, because it can be easily tested with out modifying QEMU, but then later we can move to virtio if there turned out to be clearer advantage, especially performance wise. Does that sounds like good idea? I wanted to make sure because maybe maybe hypercalls aren't that much used in kvm for a reason, so I wanted to verify that. On 18 June 2018 at 16:34, David Hildenbrand <david@redhat.com> wrote: > On 16.06.2018 13:49, Ahmed Soliman wrote: >> Following up on these threads: >> - https://marc.info/?l=kvm&m=151929803301378&w=2 >> - http://www.openwall.com/lists/kernel-hardening/2018/02/22/18 >> >> I lost the original emails so I couldn't reply to them, and also sorry >> for being late, it was the end of semester exams. >> >> I was adviced on #qemu and #kernelnewbies IRCs to ask here as it will >> help having better insights. >> >> 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. >> >> I was planning to use KVM as my hypervisor, until I found out that KVM >> can't do that on its own so one will need a custom virtio driver to do >> this kind of guest-host communication/coordination, I am still >> sticking to KVM, and have no plans to do this for Xen at least for >> now, this means that in order to get it to work there must be a QEMU >> support our specific driver we are planning to write in order for >> things to work properly. >> >> The question is is this the right approach? or is there a simpler way >> to achieve this goal? >> > > Especially if you want to support multiple architectures in the long > term, virtio is the way to go. > > Design an architecture independent and extensible (+configurable) > interface and be happy :) This might of course require some thought. > > (and don't worry, implementing a virtio driver is a lot simpler than you > might think) > > But be aware that the virtio "hypervisor" side will be handled in QEMU, > so you'll need a proper QEMU->KVM interface to get things running. > > -- > > Thanks, > > David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit 2018-06-18 16:35 ` [Qemu-devel] " Ahmed Soliman (?) @ 2018-06-18 19:01 ` David Hildenbrand -1 siblings, 0 replies; 15+ messages in thread From: David Hildenbrand @ 2018-06-18 19:01 UTC (permalink / raw) To: Ahmed Soliman Cc: riel, Kees Cook, kvm, Ard Biesheuvel, Kernel Hardening, qemu-devel, virtualization, Hossam Hassan, Ahmed Lotfy On 18.06.2018 18:35, Ahmed Soliman wrote: > Shortly after I sent the first email, we found that there is another > way to achieve this kind of communication, via KVM Hypercalls, I think > they are underutilised in kvm, but they exist. > > We also found that they are architecture dependent, but the advantage > is that one doesn't need to create QEMU<-> kvm interface > > So from our point of view it is either have things easily compatible > with many architectures out of the box (virtio) VS compatiability with > almost every front end including QEMU and any other one without > modification (Hypercalls)? My gut feeling (I might of course be wrong) is that hypercalls will not be accepted easily in KVM (I assume only if it is really highly specialized for e.g. x86 and/or required very early during boot and/or has very specific performance requirements - e.g. pvspinlocks or kvmclock). > > If it is the case, We might stick to hypercalls at the beginning, > because it can be easily tested with out modifying QEMU, but then > later we can move to virtio if there turned out to be clearer > advantage, especially performance wise. hypercalls might be good for prototyping, but I assume that the challenging part will rather be a clean KVM mmu interface. And once you have that, a kernel interface might not be too hard (I remember some work being done by malwarebytes). > > Does that sounds like good idea? > I wanted to make sure because maybe maybe hypercalls aren't that much > used in kvm for a reason, so I wanted to verify that. I assume the same. Another thing to note is performance, having to go via QEMU might be performance wise not that good. (usually chunking is the answer to reduce the overhead). But if it is really a "protect once, forget until reboot" thing, that should not be relevant. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit @ 2018-06-18 19:01 ` David Hildenbrand 0 siblings, 0 replies; 15+ messages in thread From: David Hildenbrand @ 2018-06-18 19:01 UTC (permalink / raw) To: Ahmed Soliman Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 18.06.2018 18:35, Ahmed Soliman wrote: > Shortly after I sent the first email, we found that there is another > way to achieve this kind of communication, via KVM Hypercalls, I think > they are underutilised in kvm, but they exist. > > We also found that they are architecture dependent, but the advantage > is that one doesn't need to create QEMU<-> kvm interface > > So from our point of view it is either have things easily compatible > with many architectures out of the box (virtio) VS compatiability with > almost every front end including QEMU and any other one without > modification (Hypercalls)? My gut feeling (I might of course be wrong) is that hypercalls will not be accepted easily in KVM (I assume only if it is really highly specialized for e.g. x86 and/or required very early during boot and/or has very specific performance requirements - e.g. pvspinlocks or kvmclock). > > If it is the case, We might stick to hypercalls at the beginning, > because it can be easily tested with out modifying QEMU, but then > later we can move to virtio if there turned out to be clearer > advantage, especially performance wise. hypercalls might be good for prototyping, but I assume that the challenging part will rather be a clean KVM mmu interface. And once you have that, a kernel interface might not be too hard (I remember some work being done by malwarebytes). > > Does that sounds like good idea? > I wanted to make sure because maybe maybe hypercalls aren't that much > used in kvm for a reason, so I wanted to verify that. I assume the same. Another thing to note is performance, having to go via QEMU might be performance wise not that good. (usually chunking is the answer to reduce the overhead). But if it is really a "protect once, forget until reboot" thing, that should not be relevant. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-18 19:01 ` David Hildenbrand 0 siblings, 0 replies; 15+ messages in thread From: David Hildenbrand @ 2018-06-18 19:01 UTC (permalink / raw) To: Ahmed Soliman Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 18.06.2018 18:35, Ahmed Soliman wrote: > Shortly after I sent the first email, we found that there is another > way to achieve this kind of communication, via KVM Hypercalls, I think > they are underutilised in kvm, but they exist. > > We also found that they are architecture dependent, but the advantage > is that one doesn't need to create QEMU<-> kvm interface > > So from our point of view it is either have things easily compatible > with many architectures out of the box (virtio) VS compatiability with > almost every front end including QEMU and any other one without > modification (Hypercalls)? My gut feeling (I might of course be wrong) is that hypercalls will not be accepted easily in KVM (I assume only if it is really highly specialized for e.g. x86 and/or required very early during boot and/or has very specific performance requirements - e.g. pvspinlocks or kvmclock). > > If it is the case, We might stick to hypercalls at the beginning, > because it can be easily tested with out modifying QEMU, but then > later we can move to virtio if there turned out to be clearer > advantage, especially performance wise. hypercalls might be good for prototyping, but I assume that the challenging part will rather be a clean KVM mmu interface. And once you have that, a kernel interface might not be too hard (I remember some work being done by malwarebytes). > > Does that sounds like good idea? > I wanted to make sure because maybe maybe hypercalls aren't that much > used in kvm for a reason, so I wanted to verify that. I assume the same. Another thing to note is performance, having to go via QEMU might be performance wise not that good. (usually chunking is the answer to reduce the overhead). But if it is really a "protect once, forget until reboot" thing, that should not be relevant. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit 2018-06-16 11:49 ` [Qemu-devel] " Ahmed Soliman @ 2018-06-19 17:37 ` David Vrabel -1 siblings, 0 replies; 15+ messages in thread From: David Vrabel @ 2018-06-19 17:37 UTC (permalink / raw) To: Ahmed Soliman, kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-19 17:37 ` David Vrabel 0 siblings, 0 replies; 15+ messages in thread From: David Vrabel @ 2018-06-19 17:37 UTC (permalink / raw) To: Ahmed Soliman, kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit 2018-06-19 17:37 ` [Qemu-devel] " David Vrabel (?) @ 2018-06-19 18:12 ` Ahmed Soliman -1 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-19 18:12 UTC (permalink / raw) To: David Vrabel Cc: riel, Kees Cook, kvm, Ard Biesheuvel, Kernel Hardening, qemu-devel, virtualization, Hossam Hassan, Ahmed Lotfy On 19 June 2018 at 19:37, David Vrabel <david.vrabel@nutanix.com> wrote: > It's not clear how this increases security. What threats is this > protecting again? It won't completely protect prevent rootkits, because still rootkits can edit dynamic kernel data structures, but it will limit what rootkits damage to only dynamic data. This way system calls can't be changed, or Interrupt tables. > 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. I think I was missing this part out, but I meant to say completely prevent any modification to pages including the guest physical address to guest virtual address mapping for those protected pages, Another tricky (something random just popped up in my mind right now, better to say it than to forget it) solution is making new memory mappings inherit the same protection as old one, I assume that Hyper visor can do either things. Also that was the kind of performance hit I was talking about. I am not sure if that might break things or I can say it will for sure heavily limit some functionalities. like maybe hibernating guest. But that will be the kind of trades off I am expecting at least at the begining. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Design Decision for KVM based anti rootkit @ 2018-06-19 18:12 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-19 18:12 UTC (permalink / raw) To: David Vrabel Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 19 June 2018 at 19:37, David Vrabel <david.vrabel@nutanix.com> wrote: > It's not clear how this increases security. What threats is this > protecting again? It won't completely protect prevent rootkits, because still rootkits can edit dynamic kernel data structures, but it will limit what rootkits damage to only dynamic data. This way system calls can't be changed, or Interrupt tables. > 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. I think I was missing this part out, but I meant to say completely prevent any modification to pages including the guest physical address to guest virtual address mapping for those protected pages, Another tricky (something random just popped up in my mind right now, better to say it than to forget it) solution is making new memory mappings inherit the same protection as old one, I assume that Hyper visor can do either things. Also that was the kind of performance hit I was talking about. I am not sure if that might break things or I can say it will for sure heavily limit some functionalities. like maybe hibernating guest. But that will be the kind of trades off I am expecting at least at the begining. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Design Decision for KVM based anti rootkit @ 2018-06-19 18:12 ` Ahmed Soliman 0 siblings, 0 replies; 15+ messages in thread From: Ahmed Soliman @ 2018-06-19 18:12 UTC (permalink / raw) To: David Vrabel Cc: kvm, Kernel Hardening, riel, Kees Cook, Ard Biesheuvel, Hossam Hassan, Ahmed Lotfy, virtualization, qemu-devel On 19 June 2018 at 19:37, David Vrabel <david.vrabel@nutanix.com> wrote: > It's not clear how this increases security. What threats is this > protecting again? It won't completely protect prevent rootkits, because still rootkits can edit dynamic kernel data structures, but it will limit what rootkits damage to only dynamic data. This way system calls can't be changed, or Interrupt tables. > 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. I think I was missing this part out, but I meant to say completely prevent any modification to pages including the guest physical address to guest virtual address mapping for those protected pages, Another tricky (something random just popped up in my mind right now, better to say it than to forget it) solution is making new memory mappings inherit the same protection as old one, I assume that Hyper visor can do either things. Also that was the kind of performance hit I was talking about. I am not sure if that might break things or I can say it will for sure heavily limit some functionalities. like maybe hibernating guest. But that will be the kind of trades off I am expecting at least at the begining. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-06-19 18:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-16 11:49 Design Decision for KVM based anti rootkit Ahmed Soliman 2018-06-16 11:49 ` [Qemu-devel] " Ahmed Soliman 2018-06-18 14:34 ` David Hildenbrand 2018-06-18 14:34 ` [Qemu-devel] " David Hildenbrand 2018-06-18 16:35 ` Ahmed Soliman 2018-06-18 16:35 ` Ahmed Soliman 2018-06-18 16:35 ` [Qemu-devel] " Ahmed Soliman 2018-06-18 19:01 ` David Hildenbrand 2018-06-18 19:01 ` David Hildenbrand 2018-06-18 19:01 ` [Qemu-devel] " David Hildenbrand 2018-06-19 17:37 ` David Vrabel 2018-06-19 17:37 ` [Qemu-devel] " David Vrabel 2018-06-19 18:12 ` Ahmed Soliman 2018-06-19 18:12 ` Ahmed Soliman 2018-06-19 18:12 ` [Qemu-devel] " Ahmed Soliman
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.