linux-kernel - Re: ivtv: use arch_phys_wc_add() and require PAT disabled

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]

Date:   Thu, 8 Mar 2018 05:23:09 +0000
From:   "French, Nicholas A." <naf@...edu>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Andy Lutomirski <luto@...nel.org>
CC:     "hans.verkuil@...co.com" <hans.verkuil@...co.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Thu, Mar 08, 2018 at 04:14:11AM +0000, Luis R. Rodriguez wrote:
> On Thu, Mar 08, 2018 at 04:06:01AM +0000, Luis R. Rodriguez wrote:
>  > On Thu, Mar 08, 2018 at 03:16:29AM +0000, French, Nicholas A. wrote:
> > > 
>  > > Ah, I see. So my proposed ioremap_wc call was only "working" by aliasing the
>  > > ioremap_nocache()'d mem area and not actually using write combining at all.
>  > 
>  > There are some debugging PAT toys out there I think but I haven't played with
>  > them yet or I forgot how to to confirm or deny this sort of effort, but
>  > likeley.
> 
>  In fact come to think of it I believe some neurons are telling me that if
>  two type does not match we'd get an error?

I based my guess on some text i read in "PATting Linux" [1]:
"ioremap interfaces will succeed if there is an existing,
more lenient mapping. Example: If there is an existing
uncached mapping to a physical range, any request for
write-back or write-combine mapping will succeed, but
will eventually map the memory as uncached"

But I will try to get some debugpat going to confirm.

[1] = https://www.kernel.org/doc/ols/2008/ols2008v2-pages-135-144.pdf

> > So unless there is a io-re-remap to change the caching status of a subset of
> > the decoder's memory once we find out what the framebuffer offset is inside
> > the original iremap_nocache'd area, then its a no go for write combining to
> > the framebuffer with PAT.
> 
> No what if the framebuffer driver is just requested as a secondary step
> after firmware loading?

Its a possibility. The decoder firmware gets loaded at the beginning of the decoder
memory range and we know its length, so its possible to ioremap_nocache enough 
room for the firmware only on init and then ioremap the remaining non-firmware
decoder memory areas appropriately after the firmware load succeeds...
 
> > > On the other hand, it works fine for me with a nocache'd framebuffer. It's
> > > certainly better for me personally to have a nocache framebuffer with
> > > PAT-enabled than the framebuffer completely disabled with PAT-enabled, but I
> > > don't think I would even propose to rollback the x86 nopat requirement in
> > > general. Apparently the throngs of people using this super-popular driver
> > > feature haven't complained in the last couple years, so maybe its OK for me
> > > to just patch the pat-enabled guard out and deal with a nocache'd
> > > framebuffer.
> > 
> > Nope, best you add a feature to just let you disable wc stuff, to enable
> > life with PAT.

I'm not sure I understand what you mean.

Perhaps the easy answer is to change the fatal is-pat-enabled check to just a
warning like "you have PAT enabled, so wc is disabled for the framebuffer. 
if you want wc, use the nopat parameter"?

- Nick