linux-kernel - Re: [PATCH RFC] MIPS: Remove detect_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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Feb 2021 09:37:44 +0800
From:   Jinyang He <hejinyang@...ngson.cn>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        John Crispin <john@...ozen.org>
Cc:     "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] MIPS: Remove detect_memory_region()

On 02/24/2021 11:40 PM, Jiaxun Yang wrote:

>
> On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
>> detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS: add
>> detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
>> ("MIPS: ralink: make use of the new memory detection code") and
>> Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory detection
>> code"). Its code is based on early ath79 platform code.
>>
>> What puzzles me is that how memcmp() detect the memory region. If `break`
>> was touched, the function could make sense. That means memcmp() should
>> return zero. Otherwise, the loop will be end by size > sz_max.
>>
>> I have tested detect_memory_region() on Loongson64 3A3000. On our design,
>> kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
>> function runs and last stopped on kseg1 where is uncached. In this process
>> memcmp also returned non-zero when detected kseg0 high 256MB. Then I did
>> another thing. memcpy first and test memcmp then (after &_end). It works
>> well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB maps
>> IO/PCI and it is dangerous to write like write memory.
>>
>> At last, read memory from where is not memory region may always return 0.
>> (Or trigger exception.) This function have been used several years and
>> seems no error occur. Maybe it's a fallback way.
> That is not true for other platforms like ath79 or mtk.
> They'll wrap around or return 0xffffffff for out of boundary accessing.
>
> Loongson does not apply to this case as it have special "Address Window"
> design to accurately describe address regions.
> Any access beyond described windows will be handled by MC and return 0 or random stuff.
>
> Again, please don't make changes because you can.
>
> Thanks.
>
> - Jiaxun

Hi, Jiaxun,

Thank you for answering this puzzle for me in detail.

Assume that the machine has 8MB real memory and dm address is (base + 3M).
When size = 8MB, there will be a phenomenon of `wrap around`, the actual
content of (dm + 8M + 3M) is content of (dm + 3M), so it will trigger
`break`, right? At this time, the kernel will add 8M to the memory.

Thanks,
Jinyang