Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Dec 2019 19:10:13 +0100
From: Adam Zabrocki <>
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,
> Alexander

pi3 (pi3ki31ny) - pi3 (at) itsec 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.