linux-kernel - Re: [PATCH] ARM: decompressor: Flush tlb before swiching domain 0 to client mode

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:	Wed, 12 Dec 2012 14:27:22 -0800
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
Cc:	linux-kernel@...r.kernel.org, r.sricharan@...com,
	rmk+kernel@....linux.org.uk,
	ARM PORT <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: decompressor: Flush tlb before swiching domain 0 to
 client mode

On Wed, Dec 12, 2012 at 2:10 AM, Santosh Shilimkar
<santosh.shilimkar@...com> wrote:
> On Wednesday 12 December 2012 02:41 AM, Arve Hjønnevåg wrote:
>>
>> If the bootloader used a page table that is incompatible with domain 0
>> in client mode, then swithing domain 0 to client mode causes a fault
>> if we don't flush the tlb after updating the page table pointer.
>>
>> Signed-off-by: Arve Hjønnevåg <arve@...roid.com>
>> ---
>>   arch/arm/boot/compressed/head.S |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/compressed/head.S
>> b/arch/arm/boot/compressed/head.S
>> index 90275f0..9c8034c 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -704,6 +704,7 @@ __armv7_mmu_cache_on:
>>                 bic     r6, r6, #1 << 31        @ 32-bit translation
>> system
>>                 bic     r6, r6, #3 << 0         @ use only ttbr0
>>                 mcrne   p15, 0, r3, c2, c0, 0   @ load page table pointer
>> +               mcrne   p15, 0, r0, c8, c7, 0   @ flush I,D TLBs
>>                 mcrne   p15, 0, r1, c3, c0, 0   @ load domain access
>> control
>>                 mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
>>   #endif
>>
> The TLB's are already flushed few lines above so above patching
> shouldn't help if it was really dirty TLB entry issue. I suspect that
> your boot-loader clean-up [1] function may not be taking care of
> flushing caches which could potetially lead to the issue.
>
> Have you checked that ?
>

No, the problem is that the mmu is on when that first tlb flush
happens so the tlb entry for the code that is executing gets reloaded
from the old page table. This is probably a bootloader bug, but I
don't have the bootloader source and 3.4 boots with the same
bootloader.

-- 
Arve Hjønnevåg
--
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/