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: <CALCETrUV2NseM8u6YqQ3trqLy+10_A6sd7nmfkgO3Rnw3GSxiQ@mail.gmail.com>
Date:	Tue, 15 Jul 2014 16:54:45 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Toshi Kani <toshi.kani@...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:46 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 07/15/2014 04:36 PM, Andy Lutomirski wrote:
>> 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.
>>
>
> We could do that, but would it be better?

>From vague memory, the current mechanism for tracking RAM memtypes (as
opposed to memtypes for everything that isn't RAM) is limited to a
very small number of types, leading to oddities like not being able to
create WT ram with this patchset.

Using the pagetables directly would be simpler (no extra data
structure) and would automatically exactly track the set of memtypes
that can fit in the pagetable structures.

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