memblock_reserve or memblock_remove to reserve a page

[Nikhil Utane]

MH,

If I am not mistaken, then data abort exception is available on arm. Ours
is ppc (e6500). Don't think this exception is supported.

*"Write a simple function to perform a CPU write through the linear mapping
address."*
Can you please elaborate on this? How exactly to do this? Pardon my
ignorance. I am not much of a kernel programmer.

Thank you for your help so far. Appreciate it.

-Regards
Nikhil


On Fri, Sep 16, 2016 at 4:52 AM, Min-Hua Chen <orca.chen at gmail.com> wrote:

>
>
> On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane <nikhil.subscribed at gmail.com
> > wrote:
>
>> MH,
>>
>> Let me give a bit of background of the issue.
>>
>> We are facing an issue where 4 bytes of physical memory is getting
>> corrupted (set to 0) at a fixed offset.
>> This offset is always fixed 0x00A4DDC0 (PFN: 0xA4D). The problem
>> manifests in form of SIGILL for some random user-space application where
>> its text area is corrupted. At this moment we are not able to identify who
>> is causing the corruption. While we continue to investigate that (no HW
>> breakpoint support :(), I thought we could at least mask the problem since
>> we know the corruption is always occurring at a fixed offset.
>> Therefore we want to reserve the memory so that kernel does not give it
>> to anyone.
>> We tried passing it via kernel command-line parameter (using memblock)
>> but did not see it working. Finally we modified the function
>> early_reserve_mem_dt() in file "linux-3.12.19/arch/powerpc/kernel/prom.c"
>> to directly reserve the memory.
>>
>> base1 = 0xA4D000; size1=0x1000;
>> memblock_reserve(base1, size1);
>>
>> To check if reservation is working and to monitor the corruption we wrote
>> a kernel module that does a ioremap to page 0xA4D. We then poison it with
>> fixed data. What we found was that, in few runs, this memory was intact and
>> in few others it would change. We tried both memblock_reserve() as well as
>> memblock_remove(). Unfortunately we continue to get the SIGILL at the same
>> offset.
>> Is there any other way to block a physical memory page?
>>
>> ioremap code (relevant lines):
>> static char* sigill_mon_addr;
>> #define ADDR_TEST 0xA4D00
>> sigill_mon_addr = (char*)ioremap(ADDR_TEST, 4096);
>>
>> -Thanks
>> Nikhil
>>
>>
> Hi Nikhil,
>
> How can a reserved page or reserved page with no-map causes a SIGILL? The
> reserved page should not be
> allocated to other users. Your applications should be fine even the
> corruption remains on the reserved page.
>
> I think you have to make sure the page is reserved reserved on your system.
> For a memblock_remove() pages. Write a simple function to perform a CPU
> write through the linear mapping address.
> You should get a data abort and make sure that no CPU can access the page.
> If the corruption remains, the corruption
> may be caused by other H/W modules.
>
> -MH
>
>
>> On Thu, Sep 15, 2016 at 5:35 AM, Min-Hua Chen <orca.chen at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane <
>>> nikhil.subscribed at gmail.com> wrote:
>>>
>>>> Thank You MH Chen for your response.
>>>>
>>>> So does that mean with memblock_reserve(), a kernel module can call
>>>> phys_to_virt(), create a linear mapping and modify that memory?
>>>> Where as with memblock_remove(), a kernel module can call ioremap() and
>>>> then modify the memory?
>>>>
>>>
>>> Not really. It depends on the wether the reserved memory is in a linear
>>> mapping range. For example, arm32 only creates linear mapping
>>> within 1GB range because arm32 has only 1GB of kernel space virtual
>>> memory. arm64 creates linear mapping for a large range
>>> of memory (depends on ARM64_VA_BITS_xx).
>>>
>>> for memblock_remove() memory, You can use ioremap() to access the memory.
>>>
>>>
>>>> What would explain that only in some runs the memory is modified and in
>>>> some runs it is not (for both the functions)? Shouldn't this
>>>> reserved/removed memory never be modified unless someone is directly trying
>>>> to write to that specific page?
>>>>
>>>>
>>> They should not be modified. How do you write to the reserved memory?
>>> Can you post the source code?
>>>
>>> -MH
>>>
>>>
>>>
>>>> -Regards
>>>> Nikhil
>>>>
>>>> On Sun, Sep 11, 2016 at 6:08 AM, Min-Hua Chen <orca.chen at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Nikhil,
>>>>>
>>>>> memblock_reserve() adds a given memory to the "memblock.reserved"
>>>>> list, it ends up to mark the given range of pages as "reserved". It means
>>>>> the pages are reserved and will not be allocated to other users. The kernel
>>>>> still can see the pages, create linear mappings on them, even access them
>>>>> by linear mappings.
>>>>>
>>>>> memblock_remove() removes a given memory from the "memblock.memory"
>>>>> list, it ends to removed from kernel's memory management system. The memory
>>>>> will not have page structure, no linear mapping on them. It prevents the
>>>>> memory from CPU accessing by the linear address. To access the memory (by
>>>>> CPU), you must use ioremap() to create a mapping to them.
>>>>>
>>>>>
>>>>> MH Chen
>>>>>
>>>>> On Fri, Sep 9, 2016 at 5:29 PM, Nikhil Utane <
>>>>> nikhil.subscribed at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I want to reserve a physical memory page with a fixed PFN. I do not
>>>>>> want this page to be used by anyone else. I am calling memblock_reserve()
>>>>>> to supposedly reserve the page. I am writing some content into this page.
>>>>>> What I see is that during some runs the content of this page is modified
>>>>>> (either fully or sometimes partially). In few runs, I see it as intact. Is
>>>>>> it expected that even after calling memblock_reserve() the kernel can
>>>>>> allocate this physical page for any other purpose? How is memblock_remove()
>>>>>> different from memblock_reserve? I tried reading up but didn't see any
>>>>>> useful information. What I understood is memblock_remove will completely
>>>>>> remove from kernel's allocation mechanism. Should I then be using remove
>>>>>> instead of reserve?
>>>>>>
>>>>>> -Thanks
>>>>>> Nikhil
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kernelnewbies mailing list
>>>>>> Kernelnewbies at kernelnewbies.org
>>>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160916/28eb7b32/attachment.html