On 19 June 2018 at 19:37, David Vrabel <david.vrabel@xxxxxxxxxxx> 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.
