[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACT4Y+aQEkT2TnGbs3VZu42e1EKcM8M_Q=VGZveZH-dLkOXSrg@mail.gmail.com>
Date: Tue, 7 Nov 2017 13:44:43 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: David Hildenbrand <david@...hat.com>,
Nick Desaulniers <nick.desaulniers@...il.com>,
syzbot
<bot+eb276410a47365e399ee50d68e73650cac178e0f@...kaller.appspotmail.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
"H. Peter Anvin" <hpa@...or.com>, KVM list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Lorenzo Stoakes <lstoakes@...il.com>,
Michal Hocko <mhocko@...e.com>, Ingo Molnar <mingo@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
syzkaller-bugs@...glegroups.com,
Thomas Gleixner <tglx@...utronix.de>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:LINE
On Tue, Nov 7, 2017 at 1:29 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>>>>> Does it have to be stack allocated?
>>>>
>>>> We can't use kmalloc and friends in emulate.c. We would have to
>>>> introduce new emulator callbacks.
>>>>
>>>> a) for malloc and free. hmmm.
>>>> b) for carrying out the fxrstr/fixup.
>>>>
>>>> Paolo, what do you suggest?
>>>
>>> You can use kmalloc. Any userspace user of emulate.c would have to
>>> write a wrapper.
>>
>>
>> Can you please tell me more about this? Is it used for testing? Is
>> there an example code that builds and tests this in user-space?
>
> Not quite, there's no user outside KVM yet. But the emulator code is
> designed to be independent from KVM's memory access primitives; with
> "nm" you can see how there are very few undefined symbols:
>
> U ex_handler_default
> U find_first_bit
> U find_next_bit
> U memcpy
> U printk
>
> Exceptions are only used for div/idiv, if it gets in the way it's okay
> to just revert commit b8c0b6ae498f ("KVM: x86 emulator: convert DIV/IDIV
> to fastop", 2013-05-21).
>
> On the other hand, dependencies on Linux headers have sneaked in more
> and more, but refactoring those away should not be too hard.
Thanks for the info. We may be potentially interested in fuzzing this
in user-space.
Powered by blists - more mailing lists