[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c85e1ddc-71b6-4537-a80f-cd37f61ab6dd@tenstorrent.com>
Date: Tue, 18 Feb 2025 11:21:04 -0800
From: Cyril Bur <cyrilbur@...storrent.com>
To: Ben Dooks <ben.dooks@...ethink.co.uk>,
Charlie Jenkins <charlie@...osinc.com>
Cc: palmer@...belt.com, aou@...s.berkeley.edu, paul.walmsley@...ive.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
Jisheng Zhang <jszhang@...nel.org>
Subject: Re: [PATCH v2 1/4] riscv: implement user_access_begin and families
On 14/2/2025 3:16 am, Ben Dooks wrote:
> On 13/02/2025 17:07, Cyril Bur wrote:
>>
>>
>> On 6/2/2025 1:08 am, Ben Dooks wrote:
>>> On 17/01/2025 23:21, Charlie Jenkins wrote:
>>>> On Mon, Nov 18, 2024 at 11:01:09PM +0000, Cyril Bur wrote:
>>>>> From: Jisheng Zhang <jszhang@...nel.org>
>>>>>
>>>>> Currently, when a function like strncpy_from_user() is called,
>>>>> the userspace access protection is disabled and enabled
>>>>> for every word read.
>>>>>
>>>>> By implementing user_access_begin and families, the protection
>>>>> is disabled at the beginning of the copy and enabled at the end.
>>>>>
>>>>> The __inttype macro is borrowed from x86 implementation.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang <jszhang@...nel.org>
>>>>> Signed-off-by: Cyril Bur <cyrilbur@...storrent.com>
>>>
>>> If we're doing this, then saving the STATUS.SUM flag is going to
>>> be more important than before. We had this discussion when the
>>> initial user-access with syzbot stress testing turned up.
>>>
>>> We partially fixed this by rewriting the ordering in the __put_user
>>> function to stop the 'x' argument being evaluated inside the area
>>> where SUM is enabled, but this is going to make the window of
>>> opportunity of a thread switch much bigger and the bug will just
>>> come back and bite harder.
>>>
>>> If you want I can look at re-doing my original patch and resubmitting.
>>
>> Oh! Could you please link the patch? I haven't seen it and can't seem
>> to find it now.
>
> https://lore.kernel.org/linux-riscv/20210318151010.100966-1-
> ben.dooks@...ethink.co.uk/
I agree we want this patch. Or at least we want clarity around calling
schedule inside SUM enabled sections.
Other arches are stricter about not calling schedule at all. I'm not
really going to advocate for one way or the other right now but I
believe your patch would solve the problem.
Cyril
>
>> Thanks.
>>
>>>
>>>
>>
>>
>
>
Powered by blists - more mailing lists