Re: RE: [cip-dev] ldconfig segfault on RZ/Five was Re: Preparing isar-cip-core for RZ/Five

[Pavel Machek <pavel@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

Hi!

> >> This is very good observation. Thanks!
> >>
> >> And indeed it looks like _any_ non-PIE executable fails. See:
> >>
> > 
> > Just a brief about the issue and solution:
> > 
> > TEXT_START_ADDR is the start of text segment of an application. This is being set to 0x10000 for RISCV platforms.
> > 
> > So when an application is compiled with the static flag the load would start from 0x10000 - xyz (depending on size of the application)
> > 
> > Entry point 0x101c0
> > There are 5 program headers, starting at offset 64Program Headers:
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   LOAD           0x0000000000000000 0x0000000000010000 0x0000000000010000
> >                  0x0000000000059b48 0x0000000000059b48  R E    0x1000
> >   LOAD           0x0000000000059b60 0x000000000006ab60 0x000000000006ab60
> >                  0x0000000000001f68 0x0000000000003528  RW     0x1000
> > So for the above application which is compiled statically we can see the entry point is 0x101c0 and load 0x0000000000010000.
> > 
> > Andes cores have local memories ILM and DLM that are mapped in the
> >>region H'0_0003_0000 - H'0_0004_FFFF on the RZ/Five SoC. When the
> >>virtual address falls in this range the MMU doesnt trigger a page
> >>fault and assume the virtual address as physical address and hence
> >>the application fails to run (panics somewhere).

...

> Good that the issue is understood and likely solved now. Make sure to
> upstream this as quickly as possible. It targets a fundamental tool and
> requires recompilation of many components. And Debian will freeze the
> toolchain in early January - although:
> 
> "It is unlikely that the release arch of bookworm will include riscv64."
> [1] :(

I'm pretty sure this is not complete fix. Yes, we should change the
toolchain, but the problem is really in the hardware: you can't just
take part of _virtual_ address space and reserve it. Not if you want
to claim board is riscv64 compatible. Someone else (manual mmap, some
kind of JIT, some kind of emulator) might want normal RAM there.

I believe this is quite important and should be solved in hardware (at
least in next generation).

Can ILM/DLM be disabled?

If we can not fix it at hardware level, we'll really need to prevent
attempts to map anything at that virtual memory range. Clear -EPERM
from mmap is better than strange behaviour at runtime, and it is
must-have from security perspective.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]