ql_syscall_shmat is dummy implementation and sometimes returns 0 address

[SRSG]

Is your feature request related to a problem? Please describe.
When I simulated the Tenda /bin/webs program, I found that while qiling has successfully implemented shmget, shmat was just dummy implementation.This has been written as a comment at line 246,https://github.com/qilingframework/qiling/blob/master/qiling/os/posix/syscall/mman.py.

During the simulation process, at first ,I got an error "syscall ql_syscall_ipc number = 0x1015(4117) not implemented".Before long I wrote my_syscall_ipc(code as below and only part of real syscall_ipc) to solve it.

def my_syscall_ipc(ql:Qiling, call: int, first: int, second: int, third: int, ptr: int, fifth: int):
    version = call >> 16
    call &= 0xffff
    if call == 23:
        return ql_syscall_shmget(ql, first, second, third)
    elif call == 21:
        if version != 1:
            ret = ql_syscall_shmat(ql, first, ptr, second)
            return ret
        elif version == 1:
            return -EINVAL
    else:
        return -ENOSYS

This syscall_ipc will call another 2 syscalls--shmget and shmat.Then an new error occured.shmat returned address 0 which cannot be used.Possible error part of qiling_syscall_shmat are as below:

 if shmaddr == 0:
        addr = ql.mem.map_anywhere(size)
else:
        addr = ql.mem.map(shmaddr, size, info="[shm]")
return addr

When the second argument shmaddr is 0,ql.mem.map_anywhere will return 0 address.

Describe the solution you'd like
Generally, most programs might check return value like if(ret) report error;else rigth step.So does qiling plan to correctly implement shmat or check why it return 0?

[elicn]

Thanks for reporting this.
I've just pushed a pack of maintenance fixes (#1336) and included a new implementation for shmget, shmat and ipc.
Can you give it a try and let me know if it solves the problem?

[SRSG]

It doesn't seem to work.Actually in shmget you assign the return value of map_anywhere() to key.For no limit on minaddr,shmget always return 0(that is key = 0) first.Then shmat will use 0 address, which the program cannot use yet and exit -1.
You may see it like this:

By the way I'd like to thanks for your work.May you try to fix it again?

[elicn]

Good point. I'll implement an incrementing key value instead of just using the address.
Any ideas about what should be the minimal allocation address? I haven't found a formal guideline (we could use the mmap minimal address for that, I guess).

[elicn]

@SRSG, I added the fix.
Can you pull the PR again and give it another try?

[SRSG]

I'd like to try it soon.By the way ,when I debug by IDA pro,I find that shmat(maybe in uclibc) require the return address greater than 0XFFFC0001 or it will be replaced by 0.It is quite strange.But I didn't debug it carefully, so it's only for reference.

[SRSG]

Your change to the address has worked but the PR can't run yet.

I traced the shmat(),which is in /lib/libuClibc-0.9.33.so for the program, again in IDA.It is as follow:

It's true that the addr is compared with 0xFFFC0001.If addr < 0xFFFC0001,the result will be reset to 0.That's why even if you have changed the address to 0x90001000, it is still < 0xFFFC0001 and shmat reset it to 0.So the PR exits for the 0.
The assembly code for the comparison jump section is as follows

li      $v1, 0xFFFC0001
sltu    $v1, $v0, $v1
beqz    $v1, loc_26540
nop

lw      $v0, 0x2C+var_C($sp)

loc_26540:                               # CODE XREF: shmat+44↑j
lw      $ra, 0x2C+var_s0($sp)
nop
jr      $ra
addiu   $sp, 0x30

[elicn]

I didn't find any reference to this number in the man pages; if you can point me, that would be great.
I did see though that shmat uses mmap under the hood, so they might share the same requirements as I suspected. Anyway, this is configurable on your end: go to "qiling/profiles/linux.ql" and change the value for mmap_address to the minimum you require and see if it works for you.

[SRSG]

That the number is not found possibly due to the version.My version of uclibc is 0.9.33.And in this version ,the shmat() is like this :

Compared to the C code decompiled by IDA,which I posted earlier, they're very similar, isn't it?Maybe you can study this version.There might be some connection between the number and SHMLBA.
Modify linux.ql seems to be feasible.We can add address in linux.ql and then read and use them.But it needs further test.The code of "read" may be not implement and some address might cause mmap error.

[elicn]

I re-implemented shmget and shmat and added shmdt.
Among the changes I also considered the SHMLBA alignment, which is different in MIPS (0x40000 instead of 0x1000).
Can you give it a try?

[SRSG]

Your latest changes may have gone wrong.

For the last ipc(shmat),its second is 0 which means it should return ptr.This ran correctly in the last change,but in this change it goes wrong.

[SRSG]

But I'd like to appreciate it that your changes about that number I mentioned and SHMLBA work and solve the problem.For this part,your changes have gone correct.

[elicn]

It seems like the address 0x50000000 was already taken, so it can't attach segment at shmaddr. In that case -1 should be returned.

Do you think it should have behaved differently? If so, can you point to a specific flow there you think should happen?
Please refer to:

• shmat man page: https://linux.die.net/man/2/shmat
• ipc syscall impl: https://elixir.bootlin.com/linux/v5.19.17/source/ipc/syscall.c#L81
• shmat impl: https://elixir.bootlin.com/linux/v5.19.17/source/ipc/shm.c#L1506

[SRSG]

I am sorry that I was wrong, which may have caused you a misunderstanding.I want to say that the second arg of shmat that is ptr rather than second it echoes to us.

When ptr is not 0(last ipc or shmat,and it is 0x50000000),it should attach to this address.This is explained in shmat man page: https://linux.die.net/man/2/shmat

If shmaddr isn't NULL and SHM_RND is specified in shmflg, the attach occurs at the address equal to shmaddr rounded down to the nearest multiple of SHMLBA.

For my program,this ipc initialize this memory for the first time,so maybe 0x50000000 could not be taken yet.Besides,your last changes(not this time) can return 0x50000000 correctly.

p.s.In last changes it cannot work about that number 0xfffc0001 so I patched the PR to make it run till this ipc,and it return correctly.

[elicn]

I understood that, and mentioned that the address was already taken so the segment couldn't be attached there. In this case (not being able to attach to the specified address) it should return -1.

If the common practice is that the program allocates the memory before calling shmat, then that could be the problem. If you could attach here the full log (as a text file, not image) that would help me see the full context of the call.

As for the last thing you mentioned, sorry but I didn't understand what you meant there..