From patchwork Fri Jun 4 19:02:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alper Nebi Yasak X-Patchwork-Id: 1488050 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=Gg6V3cIU; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4FxXGF1Vspz9sPf for ; Sat, 5 Jun 2021 05:02:58 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2956282EBC; Fri, 4 Jun 2021 21:02:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Gg6V3cIU"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8A0ED82EC9; Fri, 4 Jun 2021 21:02:45 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SPF_HELO_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 87ECF82CA0 for ; Fri, 4 Jun 2021 21:02:40 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=alpernebiyasak@gmail.com Received: by mail-ej1-x62d.google.com with SMTP id jt22so16035462ejb.7 for ; Fri, 04 Jun 2021 12:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=5BVwbJVw6Qmb/MkFuyHqGco4PBWHo052yE/W0ddAPbM=; b=Gg6V3cIUM1PbrzovCbSuo8R7NBhsEJ7K8qbNcpvxcAciJN5JDtuNB4mTxQtOqqGYyW eytXGwhwzMwLHfHvgjiYK1OFhEMzE9ILbzWeaOYZvruZHt4Eal2NcfE4YtvuFLmuF0ZG APb0OpOOHCWcMwoFca72YpveNTN0B5p2EytfdKZA6egoLcjIvJogzrDNfPh5ivWmEz1Q MkVYaouv6cqTDX3jWUITu0gA7bd2Y/MJgOlPem5cHpC3fycyYs0clx2+Ipl5UdqJ2ypQ Bv/fX+NZXt88oaMp8XcvY/j8on0VOl7doiQRncBmvep0BnfdYjq3pbQEgTJBPAcKiWFc saTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=5BVwbJVw6Qmb/MkFuyHqGco4PBWHo052yE/W0ddAPbM=; b=YoK9hfgAHI16BzJQIW7+8e9wWnX2YzgiSO4WC/6Srkz8vM4NN+9vEAkxIm7mWr3d+r mwhpA5aA8zfEQVAhWjrG1d7sCZfzEy/TtCFO+Bdd4OTpnhNRlAKxlrFOTKi4h3CGHlkm rP3vbPXlg3hJnVZqZ5EYPVb8nRDAfCpNQizl3c4msIlvIH48sJ4dRcL2X7EZbEaWfsgX GSkpM/SHaUnjrlosYYZhjHBzRP3qd2yGdA9X8js0n/bcRgrKIXnQnntPmQCJ3ieb2BcZ vLrAVxz/k+LTJc3zy1WbvfnptbVKxS/j/kZh42C+3y3BSUdbLuG24Cwjw89RqVkfhraH P5YA== X-Gm-Message-State: AOAM530Xsg7q2rGERZY85vDX65lCWcFyfVgUpXMdI5J5mSAmspQZbiMR ap8DpqKyKWqABVIVz/j/8hGRKA91W5w= X-Google-Smtp-Source: ABdhPJy8uYaoj2AOsU+2h58PJUaZ5SFvTL0Td5BqLbDEphPscm8OY0Q3N7IGObYcgWIVAOFyYg0qtg== X-Received: by 2002:a17:906:8345:: with SMTP id b5mr5576320ejy.14.1622833359691; Fri, 04 Jun 2021 12:02:39 -0700 (PDT) Received: from localhost.localdomain ([178.233.26.119]) by smtp.gmail.com with ESMTPSA id n2sm3668819edi.32.2021.06.04.12.02.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 12:02:39 -0700 (PDT) From: Alper Nebi Yasak To: u-boot@lists.denx.de Cc: Bin Meng , Heinrich Schuchardt , Tom Rini , Daniel Schwierzeck , Simon Glass , Marek Vasut , Alper Nebi Yasak Subject: [PATCH 0/4] Fix CIs skipping filesystem, EFI secure boot and EFI capsule tests Date: Fri, 4 Jun 2021 22:02:02 +0300 Message-Id: <20210604190207.44805-1-alpernebiyasak@gmail.com> X-Mailer: git-send-email 2.32.0.rc2 MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.4 at phobos.denx.de X-Virus-Status: Clean After my previous patch to fix filesystem tests [1] was merged, I noticed the GitLab CI was still skipping them and wanted to figure out why. In short: libguestfs tools (virt-make-fs, guestmount) fail because they need an installed kernel and the host /dev/fuse device, loop mounts need the host /dev/loop* devices, and mounting filesystems (loop and guestmount) fails because Docker containers need extra permissions to mount devices normally disabled for host security. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210520190947.21773-1-alpernebiyasak@gmail.com/ Patch #1 is meant to install a kernel into the container image that libguestfs can use, but the image will need to be regenerated manually. The need to regenerate it can be postponed with patch #4. Patch #2 makes virt-make-fs work, which should make these EFI tests run again. But guestmount doesn't work with this much because it needs more permissions to actually mount a filesystem. Patch #3 makes mounting filesystems and loop devices work, which should make the filesystem tests run again. This is separate from patch #2 because the parts using guestmount can theoretically be rewritten to use guestfish which would make the filesystem tests work without this patch, and giving mount permissions to the container processes seem to be insecure. So, this patch can be dropped if you think the impact isn't worth it. Patch #4 is actually for me to test the effects of patch #1 easier on Azure (via U-Boot GitHub repo) and locally with 'gitlab-runner exec docker'. It can be dropped if/when the container image is regenerated with patch #1 applied. I've pushed this as a GitHub pull request [2] (along with some other fixes to the filesystem test setup I'll send as patches shortly), so it would run on Azure and can be compared to the current master branch. Before this series the "test.py sandbox" job results in [3]: > [...] > SKIPPED [3] /u/test/py/tests/test_efi_capsule/conftest.py:68: Setup failed: virt-make-fs --partition=gpt --size=+1M --type=vfat /tmp/sandbox/persistent-data/test_efi_capsule /tmp/sandbox/persistent-data/test_efi_capsule.img > SKIPPED [14] /u/test/py/tests/test_efi_secboot/conftest.py:119: Setup failed: virt-make-fs --partition=gpt --size=+1M --type=vfat /tmp/sandbox/mnt_efisecure /tmp/sandbox/persistent-data/test_efi_secboot.img > SKIPPED [3] /u/test/py/tests/test_efi_secboot/conftest.py:235: Setup failed: virt-make-fs --partition=gpt --size=+1M --type=vfat /tmp/sandbox/persistent-data/mnt_efi_secboot_intca /tmp/sandbox/persistent-data/test_efi_secboot_intca.img > SKIPPED [13] /u/test/py/tests/test_fs/conftest.py:289: Mounting to folder failed for filesystem: fat16. Command 'guestmount -a /tmp/sandbox/persistent-data/3GB.fat16.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [13] /u/test/py/tests/test_fs/conftest.py:289: Mounting to folder failed for filesystem: fat32. Command 'guestmount -a /tmp/sandbox/persistent-data/3GB.fat32.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [13] /u/test/py/tests/test_fs/conftest.py:289: Mounting to folder failed for filesystem: ext4. Command 'guestmount -a /tmp/sandbox/persistent-data/3GB.ext4.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [11] /u/test/py/tests/test_fs/conftest.py:411: Mounting to folder failed for filesystem: fat16. Command 'guestmount -a /tmp/sandbox/persistent-data/128MB.fat16.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [11] /u/test/py/tests/test_fs/conftest.py:411: Mounting to folder failed for filesystem: fat32. Command 'guestmount -a /tmp/sandbox/persistent-data/128MB.fat32.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [4] /u/test/py/tests/test_fs/conftest.py:623: Mounting to folder failed for filesystem: ext4. Command 'guestmount -a /tmp/sandbox/persistent-data/1GB.ext4.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [7] /u/test/py/tests/test_fs/conftest.py:540: Mounting to folder failed for filesystem: fat16. Command 'guestmount -a /tmp/sandbox/persistent-data/128MB.fat16.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > SKIPPED [7] /u/test/py/tests/test_fs/conftest.py:540: Mounting to folder failed for filesystem: fat32. Command 'guestmount -a /tmp/sandbox/persistent-data/128MB.fat32.img -m /dev/sda /tmp/sandbox/persistent-data/mnt' returned non-zero exit status 1. > =========== 650 passed, 162 skipped, 2 warnings in 117.68s (0:01:57) =========== After this series the tests can be run [4], with the other fixes making all the quoted tests above succeed: > [...] > =========== 749 passed, 63 skipped, 2 warnings in 353.09s (0:05:53) ============ [2] https://github.com/u-boot/u-boot/pull/78 [3] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=2322&view=logs&j=50449d1b-398e-53ae-48fa-6bf338edeb51&t=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6&l=517 [4] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=2333&view=logs&j=50449d1b-398e-53ae-48fa-6bf338edeb51&t=97605dd2-f5a5-5dd7-2118-315ffdc8bcd6&l=657 This also exposes the following failure in the "test.py sandbox_clang" job [5], but the CIs have been skipping that test so far: > => => setenv -e -nv -bs -rt -at -i 4000000:$filesize dbx > No EFI system partition > Failed to persist EFI variables > => => printenv -e -n -guid d719b2cb-3d3a-4596-a3bc-dad00e67656f dbx > Error: "dbx" not defined > [...] > FAILED test/py/tests/test_efi_secboot/test_authvar.py::TestEfiAuthVar::test_efi_var_auth1 > ====== 1 failed, 748 passed, 63 skipped, 3 warnings in 309.82s (0:05:09) ======= I can reproduce the failure locally on the current master branch with the following commands, so it's not due to this series: $ tools/buildman/buildman -O clang -o build-sandbox -w --boards="sandbox" $ test/py/test.py --bd sandbox -k test_authvar.py [5] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=2333&view=logs&j=f22b025e-3f3e-5478-618e-bef68154f752&t=0594e91d-c1b1-5d5d-b353-a764bbd01b55&l=1114 Similar changes to patch #2, #3 should be applicable to the GitLab CI and probably necessary to get the same effect, but I don't think it's configuration is accessible to me. Alper Nebi Yasak (4): tools: docker: Install a readable kernel for libguestfs-tools Azure: Add fuse device for sandbox test.py tests Azure: Add loop devices and CAP_SYS_ADMIN for sandbox test.py tests Azure/GitLab: Install a readable kernel for libguestfs-tools .azure-pipelines.yml | 25 ++++++++++++++++++++++++- .gitlab-ci.yml | 5 +++++ tools/docker/Dockerfile | 4 ++++ 3 files changed, 33 insertions(+), 1 deletion(-)