Skip to content

Conversation

@minosgalanakis
Copy link
Contributor

@minosgalanakis minosgalanakis commented Jan 14, 2022

This PR is implementing the following:

Changes

  • Align 16.04 to 18.04 Docker images
  • Remove 16.04 related workarounds when possible
  • Updated the ARMLMD_LICENSE_FILE files and removed workarounds in groovy scripts
  • Created a 20.04 Docker Image file which is fully aligned to 18.04
  • Added the --security-opt seccomp=unconfined to the docker run parameter
  • Switched to distribution provided versions for abi-dumper, abi-compliance-checker libasn1

Testing

Image are tested locally using the build and run scripts, and isolated builds

  • Test job mbedtls-release-ci-testing 347 (RUN_BASIC_BUILD_TEST @ 16.04) -> Passed

  • Test job mbedtls-release-ci-testing 347 (RUN_BASIC_BUILD_TEST @ 18.04) -> Passed

  • Test job mbedtls-release-ci-testing 347 (RUN_BASIC_BUILD_TEST @ 20.04) -> Passed

  • Test job mbedtls-release-ci-testing 348 (RUN_ALL_SH@ 16.04) -> Passed

  • [x ] Test job mbedtls-release-ci-testing 348 (RUN_ALL_SH@ 20.04) -> Passed

  • Testing RUN_ABI_TEST in mbed-tls-pr-test-parametrized 225

  • Test job mbedtls-release-ci-testing 352 (RUN_ALL_SH@ 20.04) -> Failed

  • Test job mbedtls-release-ci-testing 352 (RUN_ALL_SH@ 20.04->18.04->16.04) -> Failed

Todo

Investigate why the following tests are failing at 20.04

  • all_u20-check_doxygen
  • all_u20-test_everest
  • all_u20-test_se_default

@minosgalanakis minosgalanakis added enhancement New feature or request needs: work labels Jan 14, 2022
@minosgalanakis minosgalanakis linked an issue Jan 14, 2022 that may be closed by this pull request
5 tasks
@minosgalanakis minosgalanakis added the size-s Estimated task size: small (~2d) label Jan 14, 2022
@minosgalanakis minosgalanakis force-pushed the dev/mg/update-docker-files branch from 58f1d00 to a3fcabb Compare January 17, 2022 17:09
@minosgalanakis
Copy link
Contributor Author

minosgalanakis commented Jan 18, 2022

Failure investigations

The following code was added to the get_release_jobs method in order to test including 20.04 images

`def gen_release_jobs(label_prefix='', run_examples=true) {
def jobs = [:]

common.get_branch_information()

if (env.RUN_BASIC_BUILD_TEST == "true") {
    jobs = jobs + gen_code_coverage_job('ubuntu-16.04');
}

if (env.RUN_ALL_SH == "true") {
    for (component in (common.available_all_sh_components['ubuntu-20.04'])) {
        jobs = jobs + gen_all_sh_jobs('ubuntu-20.04', component, label_prefix)
    }

    for (component in (common.available_all_sh_components['ubuntu-16.04'] -
                       common.available_all_sh_components['ubuntu-20.04'])) {
        jobs = jobs + gen_all_sh_jobs('ubuntu-16.04', component, label_prefix)
     }

    for (component in (common.available_all_sh_components['ubuntu-18.04'] -
                       common.available_all_sh_components['ubuntu-20.04'] -
                       common.available_all_sh_components['ubuntu-16.04'])) {
        jobs = jobs + gen_all_sh_jobs('ubuntu-18.04', component, label_prefix)
     }
}`

Job 352 only tested 20.4 and 353 tested previous docker platforms as well

The following items are currently failing with 20.04 image

  • all_u20-check_doxygen
  • all_u20-test_everest
  • all_u20-test_se_default

all_u20-check_doxygen

This is a known issue with newer versions of doxygen as reported in mbedtls issue #3497

all_u20-test_everest

The test appears to fail by a runtime error full_log

PSA cipher encrypt: invalid key type .............................. /var/lib/build/library/psa_crypto.c:3595:16: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /var/lib/build/library/psa_crypto.c:3595:16 in 

all_u20-test_se_default

The test also fails because of a runtime error full_log

test_suite_pkparse ................................................ PASS
test_suite_pkwrite ................................................ PASS
test_suite_poly1305 ............................................... PASS
test_suite_psa_crypto ............................................. psa_crypto.c:3595:16: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior psa_crypto.c:3595:16 in 
FAIL
--------------------- Begin test_suite_psa_crypto ---------------------

This patch updates docker's run.sh with the aforementioned parameter
which disables the ASLR for zeroize test. The readme.md file has
been updated accordingly
This patch updates the ubuntu-16.04 & ubuntu-18.04 Dockerfiles
to use the up-to-date license license information, and removes the
workaround in gen_jobs.groovy script.
This patch installs the official distribution selected packages for
`abi-dumper` -> (version>=1.1-1) and
`abi-compliance-checker` -> (version>=2.3-0.2)
This patch updates GnuTLS 3.7 configure command to use the
distribution’s `libtasn1` -> (version>=4.13).

Comments have been amended accordingly
Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

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

This was just a first pass, I'll have a look at the test results tomorrow.

# - libtasn1: can use the Ubuntu version, except for GnuTLS 3.7 which needs
# libtasn1 4.9 (Ubuntu 16.04 has 4.6); an config option
# --with-included-libtasn1 is available, so use it for GnuTLS 3.7.
# - libtasn1: can use the Ubuntu version
Copy link
Contributor

Choose a reason for hiding this comment

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

Please leave a note about --with-included-libtasn1 as a reminder, if in the future we need a bleeding-edge version of GnuTLS for which the Ubuntu version is not enough (like the comment on libunistring below).

&& rm -rf /var/lib/apt/lists/

# Install abi-compliance-checker & abi-dumper
RUN apt-get update -q && apt-get install -yq abi-compliance-checker abi-dumper
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be better to add that to the big invocation of apt-get install that starts on line 39:

  • minimizing the number of times we call apt-get update reduces the time it takes to build the image
  • I think have everything in one place in a sorted list makes it easier to maintain

Copy link
Contributor

Choose a reason for hiding this comment

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

More importantly: the 16.04 says we want at least version 2.3 of abi-compliance-checker. Unless I'm mistaken, Ubuntu 18.04 only has 2.2. So, shouldn't we still compile 2.3?

(OTOH, abi-dumper seems OK as the Ubuntu repos have 1.1.)

ENV PATH=/opt/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH

# Install abi-compliance-checker
RUN apt-get update -q && apt-get install -yq abi-compliance-checker
Copy link
Contributor

Choose a reason for hiding this comment

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

Same note as for the 18.04 file: let's keep all things installed with apt in the same place as much as possible.

This patch updates ubuntu18-04 Dockerfiles to
compile abi-compliance-checker 2.3 from source.

Both files are slightly modified to remove
unessary apt-get updates when using the package
manager.

It also adds a note to OpenSSL comments, to
serve as reminder of the optional
`--with-included-libtasn1` parameter.
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

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

I reviewed the code changes. I haven't inspected CI results. Have you run the CI with the latest version? If not, please update the PR description once you do. You might wait until you've handled the review feedback.

This patch introduces the following 20.04 changes:
* Added a note to link an existing known issue to abi-tools
* Removed duplicate installation of abi-tools
* Removed unnecessary pip upgrade operation
* Reworded comments
This patch removes the afforementioned python
dependencies in ubuntu-16.04, ubuntu-18.04,
ubuntu-20.04.

Test jobs will install dependencies as required.
@minosgalanakis
Copy link
Contributor Author

I am quoting @gilles-peskine-arm from an slack channel thread

resources/docker_files/run.sh /some/directory ubuntu-16.04 no longer works out of the box because that results in HOME set to / which is not writable so installing python modules with scripts/min_requirements.py fails. Can we arrange to set HOME to the workspace directory mounted on /var/lib/ws

A new requirement/request is accepted to add an ENV entry for HOME->/var/lib/ws in all three images. It will be added in a single commit.

This patch introduces the aforementioned ENV
setting in ubuntu-16.04, ubuntu-18.04,
ubuntu-20.04.

This fixes the home directory to a known location
where scripts can access, to install and
configure additional dependencies.
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

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

Looks good to me except for HOME set to the wrong directory (sorry).

Please run at least a pr-merge test job and a release test job with the final version of the images.


# Note: scripts/min_requirements.py need a writable
# destination for installing python dependencies
ENV HOME=/var/lib/ws
Copy link
Contributor

Choose a reason for hiding this comment

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

/var/lib/ws doesn't exist by default, and it's a directory outside the Docker image. /var/lib/builds is the one that's created by default and owned by user. So I think HOME should be set to that instead. Sorry, I wasn't thinking properly when I suggested /var/lib/ws.

This patch changes the HOME location from
/var/lib/ws to /var/lib/builds
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

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

Looks good to me on code reading.

Copy link
Contributor

@mpg mpg left a comment

Choose a reason for hiding this comment

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

Looks good to me.

I noticed an outdated comment, but we might choose to ignore it for now in order to merge this PR quickly and unblock work that depends on it.

# fails). The subsequent use of "pip config" (which requires pip >=10)
# will however fail if the installation of a more recent pip failed.
RUN python3 -m pip install 'pip<21' --upgrade | cat && \
RUN python3 -m pip install pip --upgrade | cat && \
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: the comment above is outdated, as it says " Install pip<21" which is no longer what we're doing. (Non-blocker as this is only a comment.)

@gilles-peskine-arm
Copy link
Contributor

@minosgalanakis I notice you've run at least https://jenkins-mbedtls.oss.arm.com/job/mbedtls-release-ci-testing/372/ on the latest commit. Can you please make a list of the jobs you've run?

@minosgalanakis
Copy link
Contributor Author

As requested by @gilles-peskine-arm I am attaching the summary of the testing:

  • Test job mbedtls-release-ci-testing 372 (RUN_BASIC_BUILD_TEST @ 16.04) -> Passed
  • Test job mbedtls-release-ci-testing 372 (RUN_BASIC_BUILD_TEST @ 18.04) -> Passed
  • Test job mbedtls-release-ci-testing 372 (RUN_BASIC_BUILD_TEST @ 20.04) -> Passed
  • Test job mbedtls-release-ci-testing 348 (RUN_ALL_SH@ 16.04) -> Passed
  • Test job mbedtls-release-ci-testing 348 (RUN_ALL_SH@ 18.04) -> Passed
  • Test job mbedtls-release-ci-testing 348 (RUN_ALL_SH@ 20.04) -> Passed
  • Testing RUN_ABI_TEST in mbed-tls-pr-test-parametrized 327 (RUN_ABI_CHECK) --> Failed
  • Testing RUN_ALL in mbed-tls-pr-test-parametrized 327 (RUN_ALL_SH@ 16.04) --> Passed
  • Testing RUN_ABI_TEST in mbed-tls-pr-test-parametrized 327 (RUN_ALL_SH@ 18.04) --> Passed

The abi-check failure can be reviewed here

<problems_with_types severity="High">
  <header name="ssl.h">
    <type name="struct mbedtls_ssl_context">
      <problem id="Removed_Field">
        <change target="client_auth">Field @target has been removed from this type.</change>
        <effect target="client_auth" type_name="struct mbedtls_ssl_context">Recompilation of a client program may be broken with the error message: '@type_name' has no member named '@target'.</effect>
      </problem>
      </type>
  </header>
</problems_with_types>

I am investigating weather that issue is caused by the tools/versions or the codebase

@gilles-peskine-arm
Copy link
Contributor

gilles-peskine-arm commented Feb 21, 2022

327 attempts to merge bff88ab into a7a1dea which is quite a bit older. So API/ABI differences are to be expected.

I'm happy with the positive testing from 327, 372 and 348 for development. We should also check the LTS branch and some jobs that are expected to report failures. We can do that with the mbed-tls-pr-ci-testing job after reconfiguring it to point to the desired branch of mbedtls-test, then kicking off some PR jobs.

@mpg
Copy link
Contributor

mpg commented Feb 22, 2022

Testing looks good to me, but I want to clarify something: what do you mean when you write RUN_BASIC_BUILD_TEST @ 20.04? Looking at the job, it seems to me that basic-build-test.sh was only run on 16.04 as usual. But the job built the 20.04 image successfully. (Same for all.sh: it ran mostly on 16.04, some components on 18.04, and none on 20.04 AFAICS.)

Said otherwise, I think we have sufficient testing to be confident that we can merge this PR without breaking anything which is the goal.

I don't think we've tested how all.sh and basic-build-test.sh would run on the 18.04 or 20.04 images, but that's IMO out of scope for this task will be done later.

@gilles-peskine-arm
Copy link
Contributor

Looking at the job, it seems to me that basic-build-test.sh was only run on 16.04 as usual. But the job built the 20.04 image successfully. (Same for all.sh: it ran mostly on 16.04, some components on 18.04, and none on 20.04 AFAICS.)

I don't think we've tested how all.sh and basic-build-test.sh would run on the 18.04 or 20.04 images, but that's IMO out of scope for this task will be done later.

Right, the goal here was only to update the Docker images. We're still dispatching jobs to 16.04 if possible, otherwise 18.04, and now 20.04 added as a third option. But since all current jobs can run on either 16.04 or 20.04, nothing is getting run on 20.04 yet.

@gilles-peskine-arm gilles-peskine-arm merged commit e1a6125 into master Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request needs: ci size-s Estimated task size: small (~2d)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Update and clean up Ubuntu docker files

4 participants