Date: Sat, 7 Dec 2019 19:10:13 +0100 From: Adam Zabrocki <pi3@....com.pl> To: lkrg-users@...ts.openwall.com Subject: Re: bug: LKRG kills VirtualBox host VMs [- lkrg-users list] Hi Alexander, I've removed mailing list for now. On Sat, Dec 07, 2019 at 12:45:47PM +0100, Solar Designer wrote: > Hi Adam, > > On Mon, Dec 02, 2019 at 07:00:44PM +0100, Adam Zabrocki wrote: > > This is a 'hacky' feature and it's violating some of the integrity rules which > > LKRG's ED feature enforces. However, I've introduced 2 compilation options > > which can relax some of the validation in LKRG and allows such a nasty > > functionality. They are DISABLED by default but if you really want you can > > enable it and compile LKRG with them. If you do so, you might run LKRG and > > VirtualBox together. To do that you should edit "src/p_lkrg_main.h" file and > > uncomment following definitions: > > > > #define P_LKRG_CI_X86_NO_MSR > > #define P_LKRG_PCFI_NO_STACKWALK > > > > and recompile LKRG. > > VirtualBox is pretty common, and the above is obscure. We need to at > least document this prominently, or better yet introduce a module option > to enable VirtualBox compatibility in an existing build of LKRG, so that > a rebuild would not be necessary. > I understand that VBox is common. However, the logic which they have is very nasty. I understand that's not an excuse for LKRG to not support it. That's why I've analyzed what could be the possibilities to deal with it. The reason why I went into the way of the different compilation definition is because of the security. Both of that options implies weaker security validation affecting both CI as well as ED. In case of CI from weird reasons VBox set to NULL most of the MSRs (bot not IDT). However, I can deal with that. Nevertheless in case of ED it requires NOT to do stack walk/validation. That's pretty significant relax of ED / pCFI validation. That validation is pretty effective in catching various SMEP bypasses. If we make it option (relax of stack validation) then attacker could 'flip' our internal flag very easily (since it would need to be kept as a global variable). The way how we have it now, there is no way to relax such validation in a dynamic way. I would really prefer to keep it how it is and find some clear way of documention it. However, don't know what would be the best way of doing it. Maybe do you have something in your mind? Thanks, Adam > Thanks, > > Alexander -- pi3 (pi3ki31ny) - pi3 (at) itsec pl http://pi3.com.pl
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.