RE: [Question]Deprecation of force_access_*

[Cris_Tai@xxxxxxxxxxxxxx]

Hi Eric and Arnd,

Thanks for your quick and great answers.
Below is a further question：
Since set_fs(KERNEL_DS) cannot be used now, does it mean that there is no usual access check now?
If kernel driver uses set_fs(KERNEL_DS) for kernel-space buffer access, can set_fs(KERNEL_DS) be removed safely on recent kernels?
Are functions that rely on set_fs(KERNRL_DS) needed to be replaced? If yes, could you help recommend some references?
-----------------------------------------
Normally, that boundary should be firmly fixed in place. When the need to move it arises, the reason is usually the same: some kernel subsystem needs to invoke a function that is intended to access user-space data, but on a kernel-space address. Think, for example, of the simple task of reading the contents of a file into a memory buffer; the read() system call will do that, but it also performs all of the usual access checks, meaning that it will refuse to read into a kernel-space buffer. If a kernel subsystem must perform such a read, it first calls set_fs() to disable those checks; if all goes well, it remembers to restore the old boundary with another set_fs() call when the work is done.
-----------------------------------------
I'm not sure if linux-kernel@xxxxxxxxxxxxxxx is correct linux kernel mailing list. If not, could you help tell me the correct mail list?

Thank you for taking the time to review the questions and provide advice.
Once again, thank you so much for your help.

Best Regards,
Cris


-----Original Message-----
From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Sent: 2023年5月30日 21:04
To: Cris Tai (RD-CN) <Cris_Tai@xxxxxxxxxxxxxx>
Cc: Sam Ravnborg <sam@xxxxxxxxxxxx>; Stafford Horne <shorne@xxxxxxxxx>; Dinh Nguyen <dinguyen@xxxxxxxxxx>; Arnd Bergmann <arnd@xxxxxxxx>
Subject: Re: [Question]Deprecation of force_access_*


This message was sent from outside of Trend Micro. Please do not click links or open attachments unless you recognise the source of this email and know the content is safe.


"Arnd Bergmann" <arnd@xxxxxxxx> writes:

> On Tue, May 30, 2023, at 06:43, Cris_Tai@xxxxxxxxxxxxxx wrote:
>> Dear Linux Kernel Developers,
>>
>> I would like to ask a question about a modification in the Linux
>> kernel.
>> 1.     The modification commit is
>> https://ddei5-0-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=htt
>> ps%3a%2f%2fgithub.com%2ftorvalds%2flinux%2fcommit%2f967747bbc084b93b5
>> 4e66f9047d342232314cd25&umid=1D7E0A19-FCE8-A105-8BD5-7B76B66897E3&aut
>> h=fc8a9372b4bf20ee415a3b83a27b87ca25f1a9a5-6cd61b3d8aa607c40c5ea97135
>> 48f97bc36ac674
>>
>> The functions force_uaccess_* are removed. And the code in the commit
>> shows that force_uaccess_* functions can be directly removed.
>
> Please Cc the mailing list about questions like this.
>
>> 2. The question is: Could you help confirm that the force_uaccess_*()
>> functions are no longer necessary and calling them can be *safely*
>> removed? Or what shall we care about?
>
> It was only used in the kernel to switch back to USER_DS when an
> ancient driver called set_fs(KERNEL_DS). All drivers are fixed to no
> longer do this, so the set_fs() and force_uaccess_*() functions have
> no function any more, and copy_from_user() always references actual
> user addresses.


Yes.  A few rare pieces of code used the idiom set_fs(KERNEL_DS); ... code that calls copy_from_user...
set_fs(USER_DS);

The use of set_fs in that way allowed passing in a pointer to kernel memory to functions that expect a pointer to userspace memory.

If you have an old out of tree driver that you are trying to get working that used that idiom you need to find a function to call that takes a pointer to kernel memory instead of a pointer to userspace memory.

If you need help with that please Cc linux-kernel as well as the relevant people when asking the question.  It makes for a much better discussion.

Eric
TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

For details about what personal information we collect and why, please see our Privacy Notice on our website at: Read privacy policy<http://www.trendmicro.com/privacy>