linux-kernel - Re: [PATCH 01/11] resource: Add System RAM resource type

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:	Tue, 22 Dec 2015 13:04:32 -0700
From:	Toshi Kani <toshi.kani@....com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arch@...r.kernel.org, Linux MM <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 01/11] resource: Add System RAM resource type

On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> > This scheme may have a problem, though.  For instance, when someone 
> > writes a loadable module that searches for "foo", but the "foo" entry 
> > may be initialized in a distro kernel/driver that cannot be modified. 
> >  Since this search is only necessary to obtain a range initialized by 
> > other module, this scenario is likely to happen.  We no longer have 
> > ability to search for a new entry unless we modify the code that
> > initializes the entry first.
> 
> Since when do we pay attention to out-of-tree modules which cannot be
> changed?

The above example referred the case with distros, not with the upstream. 
 That is, one writes a new loadable module and makes it available in the
upstream.  Then s/he makes it work on a distro used by the customers, but
may or may not be able to change the distro kernel/drivers used by the
customers.

> Regardless, we don't necessarily need to change the callers - we could
> add new ones of the form walk_iomem_resource_by_type() or whatever its
> name is going to be which uses the ->type attribute of the resource and
> phase out the old ones slowly. New code will call the better interfaces,
> we should probably even add a checkpatch rule to check for that.

I agree that we can add new interfaces with the type check.  This 'type'
may need some clarification since it is an assigned type, which is
different from I/O resource type.  That is, "System RAM" is an I/O resource
type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
to a particular range of System RAM.  A range may be associated with
multiple names, so as multiple assigned types.  For lack of a better idea,
I may call it 'assign_type'.  I am open for a better name.

> > Even if we avoid strcmp() with @name in the kernel, user applications
> > will continue to use @name since that is the only type available in
> > /proc/iomem.  For instance, kexec has its own search function with a
> > string name.
> 
> See above.
> 
> > When a new commonly-used search name comes up, we can define it as a 
> > new extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For 
> > the current remaining cases, i.e. crash, kexec, and einj, they have no
> > impact to performance.  Leaving these special cases aside will keep the
> > ability to search for any entry without changing the kernel, and save 
> > some memory space from adding the new 'type'.
> 
> Again, we can leave the old interfaces at peace but going forward, we
> should make the searching for resources saner and stop using silly
> strings.

OK, I will try to convert the existing callers with the new interfaces.

Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/