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]

Message-ID: <1450280642.29051.76.camel@hpe.com>
Date:	Wed, 16 Dec 2015 08:44:02 -0700
From:	Toshi Kani <toshi.kani@....com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	akpm@...ux-foundation.org, linux-arch@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH 01/11] resource: Add System RAM resource type

On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> > I/O resource type, IORESOURCE_MEM, is used for all types of
> > memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> > reserved, and so on.  This requires walk_system_ram_range(),
> > walk_system_ram_res(), and region_intersects() to use strcmp()
> > against string "System RAM" to search System RAM ranges in the
> > iomem table, which is inefficient.  __ioremap_caller() and
> > reserve_memtype() on x86, for instance, call walk_system_ram_range()
> > for every request to check if a given range is in System RAM ranges.
> > 
> > However, adding a new I/O resource type for System RAM is not
> > a viable option [1].
> 
> I think you should explain here why it isn't a viable option instead of
> quoting some flaky reference which might or might not be there in the
> future.

Agreed.  I will include summary of the descriptions here.

> > Instead, this patch adds a new modifier
> > flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> > extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> > 
> > To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> > work continuously for System RAM, resource_ext_type() is added
> > for extracting extended type bit(s).
> > 
> > Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Borislav Petkov <bp@...en8.de>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Cc: Dan Williams <dan.j.williams@...el.com>
> > Reference[1]: https://lkml.org/lkml/2015/12/3/540
> > Reference[2]: https://lkml.org/lkml/2015/12/3/582
> 
> References should look something like this:
> 
> Link: http://lkml.kernel.org/r/<Message-ID>;

I see.  I will update per the format.

> > Signed-off-by: Toshi Kani <toshi.kani@....com>
> > ---
> >  include/linux/ioport.h |   11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 24bea08..4b65d94 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -49,12 +49,19 @@ struct resource {
> >  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by
> > bridge */
> >  #define IORESOURCE_MUXED	0x00400000	/* Resource is
> > software muxed */
> >  
> > +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource
> > extended types */
> 
> Should this be 0x07000000 so that we make all there bits belong to the
> extended types? Are we going to need so many?

Besides "System RAM", which is commonly searched by multiple callers, we
only have a few other uncommon cases:
 - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
Storage".
 - kexec_file.c searches for "Crash kernel".
 - einj.c will search for "Persistent Memory".

This is because drivers typically know their ranges without searching
through the resource table.  So, it does not seem that we need to
preallocate the bits at this point.

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/