linux-kernel - Re: [PATCH] ramoops appears geared to not support ARM

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:	Sun, 30 Oct 2011 23:03:27 -0700
From:	Bryan Freed <bfreed@...omium.org>
To:	Marco Stornelli <marco.stornelli@...il.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	msb@...omium.org, seiji.aguchi@....com
Subject: Re: [PATCH] ramoops appears geared to not support ARM

On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
<marco.stornelli@...il.com> wrote:
>
> Il 30/10/2011 03:07, Bryan Freed ha scritto:
>>
>> Right, and that is what I do to get ARM working.  The reserve() function
>> calls memblock_reserve() to reserve the memory for RAMOOPS.  Keeping it
>> part of main memory (by not using memblock_remove()) gets the memory
>> properly mapped.
>>
>
> According to Russell, it needs to use memblock_remove to exclude that piece of memory.
>
>> The problem I think we need to resolve is that this makes the ramoops
>> driver messy.
>
> I agree. Indeed I think we don't need to do anything in the driver. The problem is only how to exclude a piece of memory from kernel main memory view. For x86 it's trivial, for ARM it doesn't, but it's still possible.
>
> Marco

I will give that (using mem_remove()) a shot tomorrow.
My recollection on using it in last week's investigation showed the
ramoops driver ioremap() giving a mapping that did not correspond with
what the /dev/mem expected to see.  I vaguely recall /dev/mem was
effectively calling __va(0x02000000) which added a base address of
0xc0000000 giving 0xc2000000 as the resulting virtual address.  The
ramoops ioremap(), however, gave some arbitrary virtual address for
this memory.
The result was that using /dev/mem to read 0x02000000 caused a panic.

Another problem was that removing just 512KiB of memory for ramoops
screwed up the system memory initialization.  It appeared to me that
the ARM memory code expected sections to be 1MiB aligned.  I could
memblock_reserve anything, but I could only memblock_remove on a 1MiB
boundary.

And I cannot shake the feeling that we have a fairly simple disconnect
here.  Ramoops expects to use _device_ memory because it uses
ioremap().  But the buffer itself is accessed through /dev/mem which
(as we use it with no mmap() calls) expects to give access to _system_
memory.
It seems this disconnect could be removed if we provided a
/sys/class/ramoops/buffer file that an application could read instead
of having to rely on /dev/mem.

Marco, what is your opinion on that?

bryan.
--
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/