linux-kernel - Re: Problem with atomic accesses in pstore on some ARM CPUs

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:	Tue, 16 Aug 2016 06:21:08 -0700
From:	Guenter Roeck <groeck@...gle.com>
To:	Will Deacon <will.deacon@....com>
Cc:	Robin Murphy <robin.murphy@....com>,
	Kees Cook <keescook@...omium.org>,
	Jeffy Chen <jeffy.chen@...k-chips.com>,
	Colin Cross <ccross@...roid.com>,
	Tony Luck <tony.luck@...el.com>,
	Douglas Anderson <dianders@...omium.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: Problem with atomic accesses in pstore on some ARM CPUs

On Tue, Aug 16, 2016 at 3:45 AM, Will Deacon <will.deacon@....com> wrote:
> On Tue, Aug 16, 2016 at 11:32:04AM +0100, Robin Murphy wrote:
>> On 16/08/16 00:19, Guenter Roeck wrote:
>> > we are having a problem with atomic accesses in pstore on some ARM
>> > CPUs (specifically rk3288 and rk3399). With those chips, atomic
>> > accesses fail with both pgprot_noncached and pgprot_writecombine
>> > memory. Atomic accesses do work when selecting PAGE_KERNEL protection.
>>
>> What's the pstore backed by? I'm guessing it's not normal DRAM.
>
> Regardless, pgprot_noncached and pgprot_writecombine map to Device-nGnRnE
> and Normal-non-cacheable respectively, and so it's IMP DEP whether or not
> exclusives will work there.
>
>> > Debugging on rk3399 shows the following crash.
>> >
>> > [    0.912669] Bad mode in Error handler detected, code 0xbf000002 -- SError
>> > [    0.920140] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.4.14 #389
>> > [    0.926838] Hardware name: Google Kevin (DT)
>> > [    0.931533] task: ffffffc0edfe0000 ti: ffffffc0edf7c000 task.ti:
>> > ffffffc0edf 7c000
>> > [    0.939780] PC is at __ll_sc___cmpxchg_case_mb_4+0x2c/0x5c
>> > [    0.945811] LR is at 0x1
>> >
>> > The "solution" for this problem in various Chrome OS releases is to
>> > disable atomic accesses in pstore entirely, which seems to be a bit
>> > brute-force. Question is what a proper upstream-acceptable solution
>
> Why do you require atomics to the pstore? If you need to serialise updates
> from coherent observers (e.g. CPUs), is it acceptable to use a lock in
> normal memory instead?
>

Sure, this is just how pstore works today, and I would prefer not
having to hack upstream code. This is normal DRAM. The initialization
code does the following.

        if (pfn_valid(start >> PAGE_SHIFT))
                prz->vaddr = persistent_ram_vmap(start, size, memtype);
        else
                prz->vaddr = persistent_ram_iomap(start, size, memtype);

persistent_ram_vmap() uses atomics, persistent_ram_iomap() uses
spinlocks. For normal DRAM, pfn_valid() returns true.

Thanks,
Guenter