• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 609 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CODECOMPOSER: CGT 7.4.24 Docker Container Bad System Call

Jordan Dahlke
Prodigy 20 points
Part Number: CODECOMPOSER

My company rolled out docker desktop in an enterprise environment with Enhanced Container Isolation enabled.  I am trying to create a development environment container with the cl6x toolchain.  From the ubuntu 23.10 base image I installed CGT 7.4.24 successfully.  When trying to run the compiler though, even just for version info produces a Bad System Call.

cl6x --compiler_revision

invalid system call  cl6x --compiler_revision

Additionally cl6x works fine in a non-enterprise container so I know somehow some security restrictions are blocking it.  My question really comes down to, what is cl6x doing that requires these more privileged system calls?  gcc runs fine as does any other software development tools I've tried.  ECI is supposed to have minimal functional or performance impact to developers, yet cl6x is non-functional.  Any insight you could provide would be appreciated.  If I could identify the specific system call causing the issue maybe I could work with IT Security team to allow it but without knowing more I've gotten nowhere.

I have tried running the docker container with the following options with no success: docker run --security-opt seccomp=unconfined --cap-add=ALL

This is an strace of the above command:

/# strace cl6x --compiler_revision
execve("/usr/local/bin/cl6x", ["cl6x", "--compiler_revision"], 0x7fffa9fd1358 /* 8 vars */) = 0
[ Process PID=257 runs in 32 bit mode. ]
uname({sysname="Linux", nodename="572b2f1a40d1", ...}) = 0
brk(NULL) = 0xa2a8000
brk(0xa2a8d40) = 0xa2a8d40
set_thread_area({entry_number=-1, base_addr=0xa2a8840, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)
readlink("/proc/self/exe", "/opt/c6000_7.4.24/bin/cl6x", 4096) = 26
brk(0xa2c9d40) = 0xa2c9d40
brk(0xa2ca000) = 0xa2ca000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGINT, {sa_handler=0x8052690, sa_mask=[INT], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x8052690, sa_mask=[TERM], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x8052690, sa_mask=[HUP], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGILL, {sa_handler=0x8052690, sa_mask=[ILL], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGABRT, {sa_handler=0x8052690, sa_mask=[ABRT], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGFPE, {sa_handler=0x8052690, sa_mask=[FPE], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=0x8052690, sa_mask=[SEGV], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTRAP, {sa_handler=0x8052690, sa_mask=[TRAP], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGBUS, {sa_handler=0x8052690, sa_mask=[BUS], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGSYS, {sa_handler=0x8052690, sa_mask=[SYS], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGXCPU, {sa_handler=0x8052690, sa_mask=[XCPU], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGXFSZ, {sa_handler=0x8052690, sa_mask=[XFSZ], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fe3000
write(1, "7.4.24\n", 77.4.24
) = 7
exit_group(0) = ?
+++ exited with 0 +++

Version 8.3.12 works ever so slightly better actually outputting its version information before failing:

/opt/ti-cgt-c6000_8.3.12/bin/cl6x --compiler_revision
8.3.12
❯ /opt/ti-cgt-c6000_8.3.12/bin/cl6x -version
TMS320C6x C/C++ Compiler                v8.3.12
Build Number 1WBIN-2LI-UASAR-TAR-C08D

[1]    552 invalid system call  /opt/ti-cgt-c6000_8.3.12/bin/cl6x -version

  • 0
    TI__Guru**** 451251 points

    Hello,

    I brought this thread to the attention of the compiler experts. They will be able to assist further.

    Thanks

    ki

  • 0
    TI__Guru**** 244930 points

    We do not test the compiler under Docker.  Though I am surprised to see these problems.

    Jordan Dahlke said:
    what is cl6x doing that requires these more privileged system calls?

    It does not rely on any privileged systems calls.  It calls the typical I/O functions such as fopen, fprintf, etc.

    Looking more closely at the strace output ...

    Jordan Dahlke said:
    write(1, "7.4.24\n", 77.4.24
    ) = 7
    exit_group(0) = ?

    That is a successful call to write.  I cannot explain why that string does not appear.  I don't understand why the next system call is to exit_group.  Something must have gone wrong in between these two calls.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 20 points

    My bad George, I attached a copy of the strace from a PC without any of these security restriction where the docker image works fine.  The following is the Docker Desktop Enterprise security strace that fails.

    strace cl6x --compiler_revision
    execve("/usr/local/bin/cl6x", ["cl6x", "--compiler_revision"], 0x7ffcbbfbea78 /* 19 vars */) = 0
    [ Process PID=177 runs in 32 bit mode. ]
    uname({sysname="", nodename="", ...}) = 122
    +++ killed by SIGSYS +++
    [1] 174 invalid system call strace cl6x --compiler_revision

  • 0 in reply to Jordan Dahlke
    TI__Guru**** 244930 points

    I don't have a full understanding of the problem.  It is likely there is some incompatibility between how cl6x calls uname and how the implementation of uname inside this variant of Docker responds to that call.  Please understand cl6x does not call uname directly.  Something in the startup code, or an fopen call, or something like that, calls uname.  Unfortunately, we are unable to give you a better explanation.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 20 points

    Just to follow up on this.  It is almost certainly because it is a 32 bit mode application.

    From Seccomp Significant syscalls blocked by the default profile

    vm86 In kernel x86 real mode virtual machine. Also gated by CAP_SYS_ADMIN.
  • 0 in reply to Jordan Dahlke
    TI__Guru**** 244930 points

    The output of strace above shows that cl6x is a 32-bit application.  It occurred to me this could be part of the problem.  But I never was confident enough to say it.

    Thanks and regards,

    -George