linux-kernel - Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve

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: <CALCETrUx+HkzBmTZo-BtOcOz7rs=oNcavJ9Go536Fcn2ugdobg@mail.gmail.com>
Date:	Tue, 15 Jul 2014 16:36:26 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Toshi Kani <toshi.kani@...com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	plagnioj@...osoft.com, tomi.valkeinen@...com,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stefan Bader <stefan.bader@...onical.com>,
	Dave Airlie <airlied@...il.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle
 WT type

On Tue, Jul 15, 2014 at 4:10 PM, Toshi Kani <toshi.kani@...com> wrote:
> On Tue, 2014-07-15 at 12:56 -0700, Andy Lutomirski wrote:
>> On Tue, Jul 15, 2014 at 12:34 PM, Toshi Kani <toshi.kani@...com> wrote:
>> > This patch changes reserve_memtype() to handle the new WT type.
>> > When (!pat_enabled && new_type), it continues to set either WB
>> > or UC- to *new_type.  When pat_enabled, it can reserve a given
>> > non-RAM range for WT.  At this point, it may not reserve a RAM
>> > range for WT since reserve_ram_pages_type() uses the page flags
>> > limited to three memory types, WB, WC and UC.
>>
>> FWIW, last time I looked at this, it seemed like all the fancy
>> reserve_ram_pages stuff was unnecessary: shouldn't the RAM type be
>> easy to track in the direct map page tables?
>
> Are you referring the direct map page tables as the kernel page
> directory tables (pgd/pud/..)?
>
> I think it needs to be able to keep track of the memory type per a
> physical memory range, not per a translation, in order to prevent
> aliasing of the memory type.

Actual RAM (the lowmem kind, which is all of it on x86_64) is mapped
linearly somewhere in kernel address space.  The pagetables for that
mapping could be used as the canonical source of the memory type for
the ram range in question.

This only works for lowmem, so maybe it's not a good idea to rely on it.

--Andy
--
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/