Why does Linux memory contain duplicate data? - linux

I'm running a Unity game on Android, and I found that when I execute cat /proc/[pid]/maps, it output this :
It is wired to me because it seems that the memory contain duplicate data. ( like virtual address 0c300000-0c301000 and virtual address 0c301000-0c302000, they are exactly the same data mapped from /system/lib/arm/nb/libdl.so )
Is this behavior on purpose ?

Related

Trace page table access of a Linux process

I am writing to inquire the feasibility of tracing the page table access (in terms of "index" of each page table access) of a common Linux user application. Basically, what I am doing is to re-produce the exploitation mentioned in this research article (https://www.ieee-security.org/TC/SP2015/papers-archived/6949a640.pdf). In particular, the data-page accesses need to be recorded for usage and inference of program secrets.
I understand the on Linux system, 64-bit x86 architecture, the page table size is 4K. And i have used pin (https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool) to log a trace of addresses for all virtual memory access. So can I simply calculate the "index" of each data page table access, with the following translation rule?
index = address >> 15
Since 4KB = 2 ^ 15. Is it correct? Thank you in advance for any suggestions or comments.
Also, I think one thing I want to point out is that conceptually, I don't need a "precise" identifier of each data page table ID, but just a number ("index") to distinguish the access of different data pages. This shall provide conceptually identical amount of information compared with their attacks.
Ok, so you don't really need an "index", but just some unique identifier to distinguish different pages in the virtual address of a process.
In such case, then you can just do address >> PAGE_SHIFT. In x86 with 4KB pages PAGE_SHIFT is 12, so you can do:
page_id = address >> 12
Then if address1 and address2 correspond to the same page the page_id will be the same for both addresses.
Alternatively, to achieve the same result, you could do address & PAGE_MASK, where PAGE_MASK is just 0xfffffffffffff000 (that is ~((1UL << PAGE_SHIFT) - 1)).

Zedboard_Adv7511_HDMI Project Vivado Tcl building error

When I was trying to run ADI's project https://wiki.analog.com/resources/fpga/xilinx/kc705/adv7511 in Vivado 2017.4, then got this message
ERROR: [BD 41-1075] Cannot create address segment for </axi_hdmi_clkgen/s_axi/reg0> in </sys_ps7/Data> at 0x079000000 [ 4G ]. The proposed address exceeds the base address limitations <0x40000000 [ 1G ]> of the interface(s) </sys_ps7/M_AXI_GP0> through which this peripheral is accessed by this address space
Then I tried to allocate every address of every peripheral by using the auto address assignment in Address Editter.
Then I altered zed_system_bd.tcl
but still got the same kind of error. According to ZYNQ_TRM, GP0 mapping at 0x4000_0000 to 0x7FFF_FFFF.
Can anyone please tell me what I can do?

data transfer from PL(fpga) to the PC via ethernet

I work with Zedboard and vivado v2017.3.
I have a custom IP in the PL part of zynq generating 32 bit values and stores them in one of the registers, say slv_reg0 (address : 0x43c00000).
In the PS part I read this register and I can print it in the gtkterm (simple one).
I now want to transmit these values over ethernet to to the PC.
Any suggestion on how to carry out this?
Thanks,
Upasana.
Xilinx supplies sample programs, one of these is an echo server. It should be quite simple to change it so that it serves the data you generate instead of just echo-ing the received message, and you can learn out of it how to use the lwip library in case you want a more suitable solution.

mpc85xx(P2040) startup using Nor Flash, where is Nor Flash mapped to?

I'm porting u-boot to P2040 based board these days.
As u-boot/arch/powerpc/mpc85xx/start.s commented:
The processor starts at 0xffff_fffc and the code is first executed in the last 4K page in flash/rom.
In u-boot/arch/powerpc/mpc85xx/resetvec.S:
.section .resetvec,"ax"
b _start_e500
And in u-boot.lds linker script:
.resetvec RESET_VECTOR_ADDRESS :
{
KEEP(*(.resetvec))
} :text = 0xffff
The reset vector is at 0xffff_fffc, which contains a jump instruction to _start_e500.
The E500MCRM Chapter 6.6 mentioned:
This default TLB entry translates the first instruction fetch out of reset(at effective address 0xffff_fffc).
This instruction should be a branch to the beginning of this page.
So, if I configure the HCW to let powerpc boot from Nor Flash, why should I suppose that the Nor Flash's
last 4K is mapped to 0xffff_f000~0xffff_ffff? Since there're no LAW setup yet and the default BR0/OR0 of Local Bus
does not match that range. I’m confused about how Nor Flash be access at the very beginning of core startup.
Another question is:
Does P2040 always have MMU enabled so as to translate effective address to real address even at u-boot stage?
If so, beside accessing to CCSRBAR, all other memory access should have TLB entry setup first.
Best Regards,
Hook Guo

writing to an ioport resulting in segfaults

I'm writing for an atmel at91sam9260 arm 9 cored single board computer [glomation gesbc9260]
Using request_mem_region(0xFFFFFC00,0x100,"name"); //port range runs from fc00 to fcff
that works fine and shows up in /proc/iomem
then i try to write to the last bit of the port at fc20 with
writel(0x1, 0xFFFFFC20);
and i segfault...specifically "unable to handle kernel paging request at virtual address fffffc20."
I'm of the mind that i'm not allocating the right memory space...
any helpful insight would be great...
You need to ioremap the mem region you requested. ioremap maps a virtual address to a physical one.
writel works with virtual addresses, not with physical ones.
/* request mem_region */
...
base = ioremap(0xFFFFFC00, 0x100);
if(base == NULL)
release_mem_region(...);
/* now you can use base */
writel(0x1, base + 20)
...
What you probably need is to write your driver as a platform_driver, and declare a platform device in your board_file
An example of a relatively simple platform_driver can be found here
In fact, navigating through the kernel sources using lxr is probably the best way to learn how to
stuff like this.

Resources