linux-kernel - Re: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:LINE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Nov 2017 17:46:22 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Nick Desaulniers <nick.desaulniers@...il.com>
Cc:     syzbot 
        <bot+eb276410a47365e399ee50d68e73650cac178e0f@...kaller.appspotmail.com>,
        borntraeger@...ibm.com, hpa@...or.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, lstoakes@...il.com, mhocko@...e.com,
        mingo@...hat.com, rkrcmar@...hat.com,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: BUG: sleeping function called from invalid context at
 ./include/linux/uaccess.h:LINE

On 06.11.2017 17:37, Paolo Bonzini wrote:
> On 06/11/2017 17:19, David Hildenbrand wrote:
>> On 06.11.2017 17:14, Paolo Bonzini wrote:
>>> On 06/11/2017 17:01, David Hildenbrand wrote:
>>>> On 06.11.2017 16:10, Nick Desaulniers 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.  But I'm not sure it's useful... maybe the
>>> asm_safe+memcpy could be moved to a separate noinline function, so that
>>> segmented_read_std is invoked with a leaner stack.
>>
>> That's basically what we had before 9d643f63128b, however without the
>> "noinline".
> 
> Indeed.  I do prefer the usage of __fxstate_size though that was
> introduced by 9d643f63128b.
> 
> Paolo
> 

So I'll modify my patch to have that inside a static noinline function
and resend.

Thanks.

-- 

Thanks,

David / dhildenb