linux-kernel - Re: [PATCH V2 3/3] 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>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 05 Jun 2015 14:43:27 -0700
From:	"Zhang, Jonathan Zhixiong" <zjzhang@...eaurora.org>
To:	Borislav Petkov <bp@...en8.de>
CC:	Matt Fleming <matt@...eblueprint.co.uk>, rjw@...ysocki.net,
	lenb@...nel.org, ying.huang@...el.com, leif.lindholm@...aro.org,
	al.stone@...aro.org, fu.wei@...aro.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linaro-acpi@...ts.linaro.org, vgandhi@...eaurora.org,
	Tony Luck <tony.luck@...il.com>
Subject: Re: [PATCH V2 3/3] acpi, apei: use EFI memmap to map GHES memory



On 6/5/2015 10:12 AM, Borislav Petkov wrote:
> On Fri, Jun 05, 2015 at 10:05:13AM -0700, Zhang, Jonathan Zhixiong wrote:
>>> What is DDR?
>>>
>>> I think this needs to be clarified first before we go any further.
>> I thought the word "memory" might be confusing, because there are
>
> So you mean normal RAM here?
Yes, exactly. I should use this word RAM instead.
>
>> memories on the system that is not accessible by Linux. In this
>> context, the APEI error data is accessed (read and write) by both Linux
>> and platform firmware; hence both sides should access the memory using
>> same cache attribute. I wanted to emphasize the idea that even though
>> normally DDR is cachable, but in this case when platform access it with
>> un-cached attribute, Linux should do the same.
>
> Makes sense.
>
> Btw, do we need synchronization between firmware and Linux then? Does
> Linux need to know when it is ok to touch that memory?
Good question. Linux zeros out error status code in the error data
after the data is consumed, this is good; but it alone does not solve
the synchronization concern.

For interrupt notification type (SCI or NMI) error source, this may not
be an issue since both sides can operate under the rule that the error
data is only overwritten but never appended. But what about poll
notification type? In this case, platform gathers error, updates the
memory region as needed; Linux checks the same memory region
periodically.

An ACPI APEI proposal intended to solve this concern has been discussed
in UEFI forum. The idea is to have OS to send platform a signal (through
updating a designated register) after error data is consumed. Therefore,
when OS is accessing the memory region, platform does not try to access
the same memory region in the mean time.

After this proposal is approved and published, I will submit a patch
to implement it.

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