Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

infra/helper.py not working on Mac M2, Fix for it please review. #9727

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hardik05
Copy link

I was trying oss-fuzz on following setup:
Host: MacBook Pro M2 chip(ARM)
Guest: Kali Linux with parallels Desktop

When i tried infra/helper.py i found following:

  1. By default it was taking architecture as x86_64.
  2. In many places if architecture is not taken from args then it is passed as x86_64 in the script.
  3. Few calls made to buildx etc were not working and when i removed them, it worked fine. i was able to use build_image, build_fuzzer and run_fuzzers without any issues.

I have created a patch, first please check why arm build are not working with infra/helper.py and then please check with my script. I am not very sure if this is a issue specific to M2 Mac or not but i dont have any other hardware to test it.

Also on the other note, base images for java and python will not work on Arm architecture, need to have base image for them to work with OSS-Fuzz.

@google-cla
Copy link

google-cla bot commented Feb 16, 2023

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@hardik05 hardik05 changed the title fix fir m2 infra/helper.py not working on Mac M2, Fix for it please review. Feb 16, 2023
@hardik05
Copy link
Author

Also looks like there is no workflow build for ARM yet?

@jonathanmetzman
Copy link
Contributor

Also looks like there is no workflow build for ARM yet?

There is none correct. The images were built by me using helper.py and manually pushed.

@@ -616,26 +613,13 @@ def build_image_impl(project, cache=True, pull=False, architecture='x86_64'):

build_args = []
image_name = 'gcr.io/%s/%s' % (image_project, image_name)
if architecture == 'aarch64':
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you need to remove this? I think doing so breaks aarch64 builds on x86_64 hosts.

Copy link
Author

@hardik05 hardik05 Feb 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when i use build_fuzzer command as below:

python3.10 infra/helper.py build_fuzzers --architecture aarch64 --sanitizer address libtiff

I get following error on Mac M2:

unknown flag: --platform
See 'docker --help'.

looks like some issue with docker command, here is the detailed log:

Run 'docker COMMAND --help' for more information on a command.

To get more help with docker, check out our guides at https://docs.docker.com/go/guides/

Traceback (most recent call last):
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 1674, in <module>
    sys.exit(main())
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 185, in main
    result = build_fuzzers(args)
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 926, in build_fuzzers
    return all(
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 927, in <genexpr>
    build_fuzzers_impl(args.project,
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 775, in build_fuzzers_impl
    if build_project_image and not build_image_impl(project,
  File "/home/parallels/Research/oss-fuzz/infra/helper.py", line 637, in build_image_impl
    subprocess.check_call(command)
  File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['docker', 'buildx', 'build', '--platform', 'linux/arm64', '--progress', 'plain', '--load', '-t', 'gcr.io/oss-fuzz/libtiff', '--file', '/home/parallels/Research/oss-fuzz/projects/libtiff/Dockerfile', '/home/parallels/Research/oss-fuzz/projects/libtiff']' returned non-zero exit status 125.

when i remove, its working fine and i can build image/fuzzers and can run them.

As this change is breaking aarch64 build on x86_64 hosts, we can specify a arg "--cross_compile=1" which can be used in case we want to generate aarch64 build on x86_64. If we just want to create aarch64 build on arch64 itself we dont need to use "--cross_compile" args at all? does it make sense? or i am not sure if there is any other alternative fix. Please let me know if any.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unknown flag: --platform

I think it indicates that it isn't supported by docker. Assuming this is run in the guest VM my guess would be that either the guest OS is out of date there or docker was installed from out-of-date repositories somehow (or both).

That being said I think the right fix would be to not pass --platform to docker unless --architecture is passed to helper.py explicitly. This way helper.py would always build fuzz targets using the native architecture by default.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming this is run in the guest VM

FWIW if it's run on the host it could be that docker was installed via brew install docker and that version of docker doesn't support the platform option. brew install --cask docker should install the official docker app where the platform option should work. Either way that error message indicates that docker isn't compatible with helper.py in its current form.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was run on guest Linux vm. It's Kali Linux and docker was installed using apt install.
Yes helper.py is not compatible with the docker it seems.
Will check the docker version and provide here so that it can help.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can remember there are two ways to install Docker on Debian-based distributions. I think docker-ce should work
https://docs.docker.com/engine/install/debian/#uninstall-old-versions
https://www.kali.org/docs/containers/installing-docker-on-kali/#installing-docker-ce-on-kali-linux.

@hardik05
Copy link
Author

Also looks like there is no workflow build for ARM yet?

There is none correct. The images were built by me using helper.py and manually pushed.

Sorry if it caused any confusion, i meant to say i dont see any CI/CD aarch64 build in pull requests. i see following:

Project tests / build (libfuzzer, address, x86_64) (pull_request) Successful in 38m
Required
[Details](https://github.com/google/oss-fuzz/actions/runs/4196230953/jobs/7285082798)
@github-actions
Project tests / build (libfuzzer, memory, x86_64) (pull_request) Successful in 37m
Required
[Details](https://github.com/google/oss-fuzz/actions/runs/4196230953/jobs/7285082926)
@github-actions
Project tests / build (libfuzzer, undefined, x86_64) (pull_request) Successful in 37m
Required
[Details](https://github.com/google/oss-fuzz/actions/runs/4196230953/jobs/7285083049)
@github-actions
Project tests / build (libfuzzer, coverage, x86_64) (pull_request) Successful in 37m
Required
[Details](https://github.com/google/oss-fuzz/actions/runs/4196230953/jobs/7285083179)

@hardik05
Copy link
Author

I checked, my docker version is : 20.10.23+dfsg1, build 7155243
buildx does not seems to be supported on it it seems.

@evverx
Copy link
Contributor

evverx commented Feb 22, 2023

20.10.23+dfsg1

Looks like it came from the docker.io package.

Have you tried installing docker-ce:
https://docs.docker.com/engine/install/debian/#uninstall-old-versions
https://www.kali.org/docs/containers/installing-docker-on-kali/#installing-docker-ce-on-kali-linux
? It should make helper.py work. Though it doesn't fix the issue with docker where --platform isn't supported in general.

@hardik05
Copy link
Author

hardik05 commented Feb 23, 2023 via email

@evverx
Copy link
Contributor

evverx commented Feb 23, 2023

I'm not entirely sure but I think it's kind of expected by helper.py that docker supports that option. That isn't documented anywhere though as far as I can see so at least the documentation should probably be updated. If it's decided that this use case should be supported as mentioned in #9727 (comment) I think helper.py should pass --platform only if --architecture is passed to helper.py explicitly. I'd wait for @jonathanmetzman to weigh in here though.

By the way among other things this mess with docker packages on Debian and also RPM-based distributions is why I use podman with a few patches on top of helper.py instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants