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
| ||
|
Date: Thu, 9 Sep 2021 08:48:02 +0000 From: "Yu, Lang" <Lang.Yu@....com> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org> CC: Joe Perches <joe@...ches.com>, "Rafael J . Wysocki" <rafael@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH] sysfs: Remove page boundary align limitation on sysfs_emit and sysfs_emit_at [Public] >-----Original Message----- >From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> >Sent: Thursday, September 9, 2021 4:00 PM >To: Yu, Lang <Lang.Yu@....com> >Cc: Joe Perches <joe@...ches.com>; Rafael J . Wysocki <rafael@...nel.org>; >linux-kernel@...r.kernel.org >Subject: Re: [PATCH] sysfs: Remove page boundary align limitation on sysfs_emit >and sysfs_emit_at > >On Thu, Sep 09, 2021 at 07:48:38AM +0000, Yu, Lang wrote: >> [Public] >> >> >> >> >-----Original Message----- >> >From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> >> >Sent: Thursday, September 9, 2021 2:36 PM >> >To: Yu, Lang <Lang.Yu@....com> >> >Cc: Joe Perches <joe@...ches.com>; Rafael J . Wysocki >> ><rafael@...nel.org>; linux-kernel@...r.kernel.org >> >Subject: Re: [PATCH] sysfs: Remove page boundary align limitation on >> >sysfs_emit and sysfs_emit_at >> > >> >On Thu, Sep 09, 2021 at 06:22:54AM +0000, Yu, Lang wrote: >> >> [Public] >> >> >> >> >> >> >> >> >-----Original Message----- >> >> >From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> >> >> >Sent: Thursday, September 9, 2021 2:08 PM >> >> >To: Yu, Lang <Lang.Yu@....com> >> >> >Cc: Joe Perches <joe@...ches.com>; Rafael J . Wysocki >> >> ><rafael@...nel.org>; linux-kernel@...r.kernel.org >> >> >Subject: Re: [PATCH] sysfs: Remove page boundary align limitation >> >> >on sysfs_emit and sysfs_emit_at >> >> > >> >> >On Thu, Sep 09, 2021 at 05:52:23AM +0000, Yu, Lang wrote: >> >> >> [Public] >> >> >> >> >> >> >> >> >> >> >> >> >-----Original Message----- >> >> >> >From: Joe Perches <joe@...ches.com> >> >> >> >Sent: Thursday, September 9, 2021 1:44 PM >> >> >> >To: Yu, Lang <Lang.Yu@....com>; Greg Kroah-Hartman >> >> >> ><gregkh@...uxfoundation.org>; Rafael J . Wysocki >> >> >> ><rafael@...nel.org>; >> >> >> >linux- kernel@...r.kernel.org >> >> >> >Subject: Re: [PATCH] sysfs: Remove page boundary align >> >> >> >limitation on sysfs_emit and sysfs_emit_at >> >> >> > >> >> >> >On Thu, 2021-09-09 at 05:27 +0000, Yu, Lang wrote: >> >> >> >> [AMD Official Use Only] >> >> >> > >> >> >> >this is a public list and this marker is not appropriate. >> >> >> >> >> >> Sorry for that. >> >> >> > >> >> >> >> > -----Original Message----- >> >> >> >> > From: Joe Perches <joe@...ches.com> On Wed, 2021-09-08 at >> >> >> >> > 20:07 >> >> >> >> > +0800, Lang Yu wrote: >> >> >> >> > > The key purpose of sysfs_emit and sysfs_emit_at is to >> >> >> >> > > ensure that no overrun is done. Make them more equivalent with >scnprintf. >> >> >> >> > >> >> >> >> > I can't think of a single reason to do this. >> >> >> >> > sysfs_emit and sysfs_emit_at are specific to sysfs. >> >> >> >> > >> >> >> >> > Use of these functions outside of sysfs is not desired or supported. >> >> >> >> > >> >> >> >> Thanks for your reply. But I'm still curious why you put such a >limitation. >> >> >> >> As "Documentation/filesystems/sysfs.rst" described, we can >> >> >> >> just use scnprintf(buf, PAGE_SIZE, "%s\n", dev->name) in show >> >> >> >> functions without such a limitation. >> >> >> > >> >> >> >There's nothing particularly wrong with the use of scnprintf as above. >> >> >> > >> >> >> >The only real reason that sysfs_emit exists is to be able to >> >> >> >reduce the kernel treewide quantity of uses of the sprintf >> >> >> >family of functions that need to be analyzed for possible buffer overruns. >> >> >> > >> >> >> >The issue there is that buf is already known to be both a >> >> >> >PAGE_SIZE buffer and PAGE_SIZE aligned for sysfs show functions >> >> >> >so there's no real reason to use scnprintf. >> >> >> > >> >> >> >sysfs_emit is a shorter/smaller function and using it could >> >> >> >avoid some sprintf defects. >> >> >> > >> >> >> >> Some guys just try to replace scnprintf with sysfs_emit() or >> >> >> >> sysfs_emit_at() per >> >> >> >above documents. >> >> >> > >> >> >> >So don't do that. >> >> >> > >> >> >> >> But sprintf and sysfs_emit/sysfs_emit_at are not totally >> >> >> >> equivalent(e.g., page >> >> >> >boundary align). >> >> >> >> >> >> >> >> In my opinion, we add a new api and try to replace an old api. >> >> >> >> Does we need to make it more compatible with old api? >> >> >> > >> >> >> >IMO: no. >> >> >> > >> >> >> But why you said " - show() should only use sysfs_emit() or >> >> >> sysfs_emit_at() when formatting the value to be returned to user >> >> >> space. " in >> >> >Documentation/filesystems/sysfs.rst ? >> >> >> >> >> >> Obviously, sysfs_emit() and sysfs_emit_at() can't cover all the >> >> >> cases in show >> >> >functions. >> >> > >> >> >Why not, what usage model can it not cover? >> >> >> >> Of course, we can modify driver code to obey sysfs_emit and >> >> sysfs_emit_at >> >rules or just use scnprintf in show functions. >> > >> >Great, please do. >> > >> >> Now that you introduced them, why not make them more flexible like >> >> scnprintf >> >family functions. >> > >> >Because that is not what they are for. >> > >> >> The page boundary align rule makes life hard and I don't like it : >> >> ). Many thanks >> >for your explanations! >> > >> >Then fix your sysfs files to not violate the sysfs rules. >> > >> >Again, which files are having problems and need to be fixed? I will >> >be glad to do this for you. >> >> Thanks. I can do it by myself instead of wasting your time... Many thanks! > >When doing so, please switch to using DEVICE_ATTR_RO() instead of the "open >coded" DEVICE_ATTR() usage in the driver. That way we all "know" >that these are read-only attributes. Many thanks for you reminders! Have a nice day! Regards, Lang > >thanks, > >greg k-h
Powered by blists - more mailing lists