linux-kernel - Re: [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory

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>] [day] [month] [year] [list]

Message-ID: <55AD90AE.6030804@codeaurora.org>
Date:	Mon, 20 Jul 2015 17:22:06 -0700
From:	"Zhang, Jonathan Zhixiong" <zjzhang@...eaurora.org>
To:	Matt Fleming <matt@...eblueprint.co.uk>, bp@...en8.de
Cc:	Thomas Gleixner <tglx@...utronix.de>, fu.wei@...aro.org,
	al.stone@...aro.org, tony.luck@...il.com, rjw@...ysocki.net,
	lenb@...nel.org, ying.huang@...el.com, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org
Subject: Re: [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory

Hi Matt/Borislav, thanks for the discussion. I am sorry that somehow
I did not see this message in my inbox. I found it by surprise through
an internet search.

> On Mon, 22 Jun, at 06:11:31AM, Matt Fleming wrote:
>>
>> Right, but see my previous comment about x86 discarding a bunch of
>> attributes for memory regions because the kernel "knows better".
>>
>> And in most places, yes, the kernel really does know better. But this
>> APEI case is special because irrespective of what the kernel says we
>> want to be compatible with the firmware's memory map.
>>
>> And we don't have an API for that.
>
> Maybe what we want is a new PAGE_* protection that is compatible with
> any firmware mappings? That'd be nice because we wouldn't have to
> introduce a whole new API for this GHES case and ioremap_* could do
> whatever it wanted under the hood.
>
> Thougts?
>
Agree. That being said, I do not know if this GHES case is the only
user case that will benefit from such framework. If it is, then it may
be controversial to introduce a framework for only one use case.

To me, there are two ways that will help GHES case:
a. Define ioremap_page_range_[no]cache() functions for archs, similar
like the case for ioremap_[no]cache.
b. Define a set of PAGE_* protection types (in particular
PAGE_KERNEL_NOCACHE). Right now it seems like only a few protection
types (such as PAGE_KERNEL) are defined across the archs.

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/