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: <47fabc70-4500-1035-7dc7-7f0a3915471f@citrix.com>
Date:	Thu, 18 Aug 2016 11:16:31 +0100
From:	Andrew Cooper <andrew.cooper3@...rix.com>
To:	Jan Beulich <JBeulich@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Juergen Gross <JGross@...e.com>, <linux-kernel@...r.kernel.org>,
	<stefan.bader@...onical.com>, <david.vrabel@...rix.com>,
	<chuck.anderson@...cle.com>,
	xen-devel <xen-devel@...ts.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead
 of UC

On 18/08/16 11:06, Jan Beulich wrote:
>>>> On 17.08.16 at 22:32, <konrad.wilk@...cle.com> wrote:
>> One of the interesting things about XSA 154 fix ("x86: enforce consistent
>> cachability of MMIO mappings") is that when certain applications (mcelog)
>> are trying to map /dev/mmap and lurk in ISA regions - we get:
> DYM /dev/mem ? Most accesses to which are bogus in PV guests
> (often including Dom0) anyway.
>
>> [   49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 untrack_pfn+0x93/0xc0()
> What Linux version is this? untrack_pfn() doesn't span line 913 in
> 4.8-rc2. And follow_phys() appears to only check whether the write
> flag is set as expected; I can't see any cachability checks. Plus it
> gets called only when both incoming address and size are zero.
>
>> Anyhow what I am wondering:
>>
>>  a) Should we add a edge case in the hypervisor to allow multiple mappings
>>    for this region? I am thinking no.. but it sounds like mapping ISA region
>>    as WB is safe even in baremetal?
> We should never allow multiple mappings with different cachability.
> And I don't understand what makes you think the ISA region is safe
> to map WB? There might be ROMs, MMIO regions, or simply nothing
> there, neither of which is safe to map WB. ROMs certainly could be
> WP, but that would require a way to reliably size not only ISA
> extension ROMs, but also main and video BIOS.
>
>>  b) Or would it be better to let Linux do its thing and treat 640KB->1MB
>>    as uncached instead of writeback?
> According to what you wrote earlier the two parts of the sentence
> read contradictory to me.
>
>>    Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>>    The comment says:
>>    " /* Low ISA region is always mapped WB in page table. No need to track *"
> As per above it's not clear to me what this comment is backed by.

This states what is in the pagetables.  Not the combined result with MTRRs.

WB in the pagetables and WC/UB in the MTRRs is a legal combination which
functions correctly.

~Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ