Tracing x86 binaries in Ubuntu 22.04 is not working

[michaelbrownuc]

While testing a fix for #467, I observed that tracing an x86 executable on ubuntu 22.04 is no longer working. Specifically, it does not appear that the target binary is ever opened (no hostfiles message, no execution detector messages, module load messages etc.)

I've attached the binary I used (args used are both concrete, 1 and 2), as well as output from the 18.04 version of S2E and the 22.04 version. The environment I ran this in was a brand new ubuntu 22.04 VM with a fresh install of S2E following the instructions in the Docs.

Archive.zip

Not sure whats going on here, seems to be a fairly deep bug in S2E.

[vitalych]

Could you please run s2e export_project?

[michaelbrownuc]

Sure! Here it is.

eq2.zip

[vitalych]

Sorry, I meant s2e export_project --export-results, so that I can see the output

[michaelbrownuc]

Sure, here's the new on
eq2.zip
e

[vitalych]

Looks like a libc incompatibility between the host and the guest. Turns out I only built it on Ubuntu 22.04 and did not run :(
It works on Debian 11 hosts, even though libc is not the same version either.

[vitalych]

I upgraded the guest image to Debian 11.3 as well, still the same error. s2e tools that are built on Ubuntu 22.04 use glibc 2.34, which does not run on libc in the guest. Any dynamically linked binary build on 22.04 would have this problem in the guest.

[vitalych]

It's the main function that causes versions problems:

DYNAMIC SYMBOL TABLE:
00000000      DF *UND*  00000000 (GLIBC_2.0)  strcmp
00000000      DF *UND*  00000000 (GLIBC_2.34) __libc_start_main
00000000      DF *UND*  00000000 (GLIBC_2.0)  printf
00000000      DF *UND*  00000000 (GLIBC_2.0)  free
00000000      DF *UND*  00000000 (GLIBC_2.0)  strdup
00000000      DF *UND*  00000000 (GLIBC_2.0)  unlink
00000000      DF *UND*  00000000 (GLIBC_2.0)  fwrite
00000000      DF *UND*  00000000 (GLIBC_2.0)  puts
00000000  w   D  *UND*  00000000  Base        __gmon_start__
00000000      DF *UND*  00000000 (GLIBC_2.0)  exit
00000000      DF *UND*  00000000 (GLIBC_2.0)  getcwd
00000000      DF *UND*  00000000 (GLIBC_2.0)  strlen
00000000      DF *UND*  00000000 (GLIBC_2.0)  fprintf
00000000      DF *UND*  00000000 (GLIBC_2.0)  write
00000000      DF *UND*  00000000 (GLIBC_2.0)  creat
00000000      DF *UND*  00000000 (GLIBC_2.0)  memset
00000000      DF *UND*  00000000 (GLIBC_2.0)  snprintf
00000000      DF *UND*  00000000 (GLIBC_2.0)  __xpg_basename
00000000      DF *UND*  00000000 (GLIBC_2.0)  close
00000000      DF *UND*  00000000 (GLIBC_2.0)  calloc
0804c060 g    DO .bss   00000004 (GLIBC_2.0)  stderr

[vitalych]

https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread#the_developer_view

A downside of these changes is that we had to add many new GLIBC_2.34 symbol versions for existing functions. However, we had to add a new __libc_start_main@@GLIBC_2.34 symbol version to implement a long-requested feature, [startup code hardening](https://sourceware.org/bugzilla/show_bug.cgi?id=23323). __libc_start_main is called by all applications during startup. This new symbol version prevents applications that have been built against glibc 2.34 from launching on systems that have installed glibc 2.33 and earlier. Further GLIBC_2.34 symbols added for integrating libpthread and the other components did not seem much of an additional burden because of that.

Debian 11 uses older glibc that doesn't have this issue, that's why I didn't notice it. One solution is to provide Ubuntu 22.04 guest images that people can use instead of Debian-based images in case they have an Ubuntu 22.04 host.

[michaelbrownuc]

yes, that seems to the best option if S2E wants to support Ubuntu 22.04+. I took a look at the docs to build new images and it seems complex. I'm not sure this is something I can tackle but I am happy to stress test an image if one is made available.

[vitalych]

Unfortunately Ubuntu doesn't use the same method as Debian for unattended installations, so it will require some work.

[michaelbrownuc]

Ah too bad. Happy to help, please let me know what I can do.

[vitalych]

No worries, I got the image install working already.

[vitalych]

@michaelbrownuc please test S2E/guest-images#42

$ (cd $S2EENV/source/guest-images && get pull --rebase s2e master)
$ s2e image_build -g ubuntu-22.04-x86_64
$ s2e new_project -f -i ubuntu-22.04-x86_64 ...

[michaelbrownuc]

I've tested the new image build on a couple of samples, and they appear to be working properly now. I also tried the new image with custom plugins we are using and they worked as well. Thanks for updating this!