We can't bump hardknott ahead of master, but as it turns out, I
already have pending k*s updates for master, so I can cherry pick them
to the stable branches after I'm finished testing.

Bruce

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Signed-off-by: Diego Sueiro <diego.sueiro@...>
---
recipes-containers/k3s/k3s_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-containers/k3s/k3s_git.bb b/recipes-containers/k3s/k3s_git.bb
index 2811fb8..f51d9d4 100644
--- a/recipes-containers/k3s/k3s_git.bb
+++ b/recipes-containers/k3s/k3s_git.bb
@@ -13,9 +13,9 @@ SRC_URI = "git://github.com/rancher/k3s.git;branch=release-1.20;name=k3s \
file://0001-Finding-host-local-in-usr-libexec.patch;patchdir=src/import \
"
SRC_URI[k3s.md5sum] = "363d3a08dc0b72ba6e6577964f6e94a5"
-SRCREV_k3s = "bc400f5396a3dd05584c5f45768a5ea6c43971d1"
+SRCREV_k3s = "9cb5fb5716bdfb13e755206aff5688961f5bafb3"

-PV = "v1.20.4+k3s1"
+PV = "v1.20.11+k3s2"

CNI_NETWORKING_FILES ?= "${WORKDIR}/cni-containerd-net.conf"

--
2.17.1

merged.

Bruce

In message: [meta-virtualization] [PATCH] xen: add missing pkgconfig inherit
on 12/10/2021 Ross Burton wrote:

New oe-core pulls in less default dependencies[1], so add an explicit
inherit of pkgconfig as it is needed to configure Xen.

[1] https://lists.openembedded.org/g/openembedded-core/message/156185

Signed-off-by: Ross Burton <ross.burton@...>
---
recipes-extended/xen/xen.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index c0a087e..d3c7a7d 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -2,7 +2,7 @@ HOMEPAGE =3D "http://xen.org"
LICENSE =3D "GPLv2"
SECTION =3D "console/tools"
=20
-inherit autotools-brokensep
+inherit autotools-brokensep pkgconfig
=20
require xen-arch.inc
=20
--=20
2.25.1

On 10/1/21 10:50 AM, Bruce Ashfield wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]
In message: [meta-virtualization][hardknott][PATCH] openvswitch: Security fix for CVE-2021-36980
on 29/09/2021 Xu, Yanfei wrote:

Open vSwitch (aka openvswitch) 2.11.0 through 2.15.0 has
a use-after-free in decode_NXAST_RAW_ENCAP (called from
ofpact_decode and ofpacts_decode) during the decoding of
a RAW_ENCAP action.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36980

Patches from:
format-patch from ovs v2.15.1

Signed-off-by: Yanfei Xu <yanfei.xu@...>
---
...use-after-free-while-decoding-RAW_EN.patch | 101 ++++++++++++++++++
.../openvswitch/openvswitch_git.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644 recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch

diff --git a/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
new file mode 100644
index 00000000..c88c097d
--- /dev/null
+++ b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
@@ -0,0 +1,101 @@
+From 802a31a7070cea910b95d7e926c9da30a1f9e54f Mon Sep 17 00:00:00 2001
+From: Ilya Maximets <i.maximets@...>
+Date: Tue, 16 Feb 2021 23:27:30 +0100
+Subject: [PATCH] ofp-actions: Fix use-after-free while decoding RAW_ENCAP.
+
+While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
+ofpbuf if there is no enough space left. However, function
+'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
+structure leading to write-after-free and incorrect decoding.
+
+ ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
+ 0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
+ WRITE of size 2 at 0x60600000011a thread T0
+ #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
+ #1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
+ #2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
+ #3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
+ #4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
+ #5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
+ #6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
+ #7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
+ #8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
+ #9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
+ #10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
+ #11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
+ #12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
+ #13 0x5391ae in main utilities/ovs-ofctl.c:179:9
+ #14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
+ #15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
+
+Fix that by getting a new pointer before using.
+
+Credit to OSS-Fuzz.
+
+Fuzzer regression test will fail only with AddressSanitizer enabled.
+
+Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
+Fixes: f839892a206a ("OF support and translation of generic encap and decap")
+Acked-by: William Tu <u9012063@...>
+Signed-off-by: Ilya Maximets <i.maximets@...>
+
+Upstream-Status: Backport
+CVE: CVE-2021-36980
+Signed-off-by: Yanfei Xu <yanfei.xu@...>
+---
+ lib/ofp-actions.c | 2 ++
+ tests/automake.mk | 3 ++-
+ tests/fuzz-regression-list.at | 1 +
+ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 | 0
+ 4 files changed, 5 insertions(+), 1 deletion(-)
+ create mode 100644 tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+
+diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
+index e2e829772..0342a228b 100644
+--- a/lib/ofp-actions.c
++++ b/lib/ofp-actions.c
+@@ -4431,6 +4431,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ {
+ struct ofpact_encap *encap;
+ const struct ofp_ed_prop_header *ofp_prop;
++ const size_t encap_ofs = out->size;
+ size_t props_len;
+ uint16_t n_props = 0;
+ int err;
+@@ -4458,6 +4459,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ }
+ n_props++;
+ }
++ encap = ofpbuf_at_assert(out, encap_ofs, sizeof *encap);
+ encap->n_props = n_props;
+ out->header = &encap->ofpact;
+ ofpact_finish_ENCAP(out, &encap);
+diff --git a/tests/automake.mk b/tests/automake.mk
+index 677b99a6b..fc80e027d 100644
+--- a/tests/automake.mk
++++ b/tests/automake.mk
+@@ -134,7 +134,8 @@ FUZZ_REGRESSION_TESTS = \
+ tests/fuzz-regression/ofp_print_fuzzer-5722747668791296 \
+ tests/fuzz-regression/ofp_print_fuzzer-6285128790704128 \
+ tests/fuzz-regression/ofp_print_fuzzer-6470117922701312 \
+- tests/fuzz-regression/ofp_print_fuzzer-6502620041576448
++ tests/fuzz-regression/ofp_print_fuzzer-6502620041576448 \
++ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+ $(srcdir)/tests/fuzz-regression-list.at: tests/automake.mk
+ $(AM_V_GEN)for name in $(FUZZ_REGRESSION_TESTS); do \
+ basename=`echo $$name | sed 's,^.*/,,'`; \
+diff --git a/tests/fuzz-regression-list.at b/tests/fuzz-regression-list.at
+index e3173fb88..2347c690e 100644
+--- a/tests/fuzz-regression-list.at
++++ b/tests/fuzz-regression-list.at
+@@ -21,3 +21,4 @@ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-5722747668791296])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6285128790704128])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6470117922701312])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6502620041576448])
++TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6540965472632832])
+diff --git a/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 b/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+new file mode 100644
+index 000000000..e69de29bb
+--
+2.27.0
+
diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb
index 16ec4c72..56f1297c 100644
--- a/recipes-networking/openvswitch/openvswitch_git.bb
+++ b/recipes-networking/openvswitch/openvswitch_git.bb
@@ -30,6 +30,7 @@ SRC_URI += "git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.15
file://0001-ovs-use-run-instead-of-var-run-for-in-systemd-units.patch \
file://0001-openvswitch-fix-do_configure-with-DPDK-19.11-error.patch \
file://0001-openvswitch-fix-netdev-dpdk-compile-error.patch \
+ file://0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch \

Sorry for this late rely due to a long vocation.

You are carrying local patches to your ovs recipe that don't match meta-virt.
As such, this didn't directly apply. I fixed it up and merged it.
> But you should consider carrying those patches in a bbappend, so that
upstream sends like this have proper context, and I can be more sure
of the testing that is done on submissions.

Thanks for remainding.

I also took this as an opportunity to bump OVS in master, since I wanted
to be sure that we have the same CVE addressed there.

I notice the ovs has been updated to 2.15.1, thanks a lot.

Cheers,
Yanfei

Bruce

"

LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab"
--
2.27.0

FYI: Christopher is having a look at these updates.

I just wanted to let everyone know that they haven't been missed.

Bruce

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Adding kernel-modules did the trick, the docker daemon issued iptables command now works and supports --to-destination for dnat.

Thank-you Bruce for taking the time to explain, I've learned a ton in the process!


On 01/10/2021, 13:50, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Fri, Oct 1, 2021 at 4:35 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Yes, you're spot on!
>
> Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"
>

In the K3S recipe, we actually have finer grained RRECOMMENDS than the
docker recipes (due to the way k3s was developed and integrated).

In K3S, I'm currently tracking:

RRECOMMENDS:${PN} = "\
kernel-module-xt-addrtype \
kernel-module-xt-nat \
kernel-module-xt-multiport \
kernel-module-xt-conntrack \
kernel-module-xt-comment \
kernel-module-xt-mark \
kernel-module-xt-connmark \
kernel-module-vxlan \
kernel-module-xt-masquerade \
"

So you could try that list, or do what I normally recommend .. use the
meta package "kernel-modules" and get everything that was built. Since
if you are using a linux-yocto variant, you'll already be getting
fragments to build the right modules as part of the kernel build.

I do have a new set of tested planned for the fall that do barebones
testing to ensure that we've fully listed the rdepends/rrcommends for
many of the recipes in meta-virt.

But for now, I'd recommend that larger package, or you can do what I
did for k3s. Build a package-feed enabled image, start docker, look at
the error messages, install the required module, and then repeat to
get the minimum list (if a kernel module wasn't being built at all,
you may need to do some rebuilding in the middle).

Bruce


> But running the config script still shows the output below:
>
> root@generic-arm64:/usr/share/docker# ./check-config.sh
> info: reading kernel config from /proc/config.gz ...
> Generally Necessary:
> - cgroup hierarchy: properly mounted [/sys/fs/cgroup]
> - CONFIG_NAMESPACES: enabled
> - CONFIG_NET_NS: enabled
> - CONFIG_PID_NS: enabled
> - CONFIG_IPC_NS: enabled
> - CONFIG_UTS_NS: enabled
> - CONFIG_CGROUPS: enabled
> - CONFIG_CGROUP_CPUACCT: enabled
> - CONFIG_CGROUP_DEVICE: enabled
> - CONFIG_CGROUP_FREEZER: missing
> - CONFIG_CGROUP_SCHED: enabled
> - CONFIG_CPUSETS: enabled
> - CONFIG_MEMCG: enabled
> - CONFIG_KEYS: enabled
> - CONFIG_VETH: enabled
> - CONFIG_BRIDGE: enabled (as module)
> - CONFIG_BRIDGE_NETFILTER: missing
> - CONFIG_NF_NAT_IPV4: missing
> - CONFIG_IP_NF_FILTER: enabled (as module)
> - CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
> - CONFIG_NETFILTER_XT_MATCH_IPVS: missing
> - CONFIG_IP_NF_NAT: enabled (as module)
> - CONFIG_NF_NAT: enabled (as module)
> - CONFIG_NF_NAT_NEEDED: missing
> - CONFIG_POSIX_MQUEUE: enabled
>
> On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
> >
> > Thanks for the reply Bruce __ Let me know if these details help?
> >
> > root@generic-arm64:~# uname -r
> > 5.10.46-yocto-standard
> >
> > Only setting these two kernel configs at the moment:
> > CONFIG_ENA_ETHERNET=y
> > CONFIG_BLK_DEV_NVME=y
>
> It'll be the iptables and cgroups options that are causing issues.
>
> The standard layers and kernel are extensively tested with meta-virt,
> so there really shouldn't be something missing.
>
> You can also install the docker-contrib package to your image, and run
> the check-config.sh script to see if it reports any issues.
>
> Bruce
>
> >
> > And these are the layers, running harknott...
> > drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> > drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> > drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> > drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> > drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
> >
> >
> > On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
> >
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> > <stephibb=amazon.co.uk@...> wrote:
> > >
> > > Hello all!
> > >
> > > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> > >
> > > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> > >
> > > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> > >
> > > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> > >
> > > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> > >
> > > Any ideas for workarounds would be very much appreciated!
> >
> > It's your kernel configuration, coupled with the iptables modules
> > available .. but most often, it is a missing kernel module.
> >
> > So without knowing exactly what kernel and hardware you are running,
> > it is hard to say more.
> >
> > Bruce
> >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> >
> > Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
> >
> > Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

On Fri, Oct 1, 2021 at 4:35 AM Hibbert, Stephen <stephibb@...> wrote:

Yes, you're spot on!

Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"

In the K3S recipe, we actually have finer grained RRECOMMENDS than the
docker recipes (due to the way k3s was developed and integrated).

In K3S, I'm currently tracking:

RRECOMMENDS:${PN} = "\
kernel-module-xt-addrtype \
kernel-module-xt-nat \
kernel-module-xt-multiport \
kernel-module-xt-conntrack \
kernel-module-xt-comment \
kernel-module-xt-mark \
kernel-module-xt-connmark \
kernel-module-vxlan \
kernel-module-xt-masquerade \
"

So you could try that list, or do what I normally recommend .. use the
meta package "kernel-modules" and get everything that was built. Since
if you are using a linux-yocto variant, you'll already be getting
fragments to build the right modules as part of the kernel build.

I do have a new set of tested planned for the fall that do barebones
testing to ensure that we've fully listed the rdepends/rrcommends for
many of the recipes in meta-virt.

But for now, I'd recommend that larger package, or you can do what I
did for k3s. Build a package-feed enabled image, start docker, look at
the error messages, install the required module, and then repeat to
get the minimum list (if a kernel module wasn't being built at all,
you may need to do some rebuilding in the middle).

Bruce

But running the config script still shows the output below:

root@generic-arm64:/usr/share/docker# ./check-config.sh
info: reading kernel config from /proc/config.gz ...
Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: missing
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: missing
- CONFIG_NF_NAT_IPV4: missing
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: missing
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing
- CONFIG_POSIX_MQUEUE: enabled

On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Thanks for the reply Bruce __ Let me know if these details help?
>
> root@generic-arm64:~# uname -r
> 5.10.46-yocto-standard
>
> Only setting these two kernel configs at the moment:
> CONFIG_ENA_ETHERNET=y
> CONFIG_BLK_DEV_NVME=y

It'll be the iptables and cgroups options that are causing issues.

The standard layers and kernel are extensively tested with meta-virt,
so there really shouldn't be something missing.

You can also install the docker-contrib package to your image, and run
the check-config.sh script to see if it reports any issues.

Bruce

>
> And these are the layers, running harknott...
> drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
>
>
> On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> <stephibb=amazon.co.uk@...> wrote:
> >
> > Hello all!
> >
> > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> >
> > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> >
> > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> >
> > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> >
> > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> >
> > Any ideas for workarounds would be very much appreciated!
>
> It's your kernel configuration, coupled with the iptables modules
> available .. but most often, it is a missing kernel module.
>
> So without knowing exactly what kernel and hardware you are running,
> it is hard to say more.
>
> Bruce
>
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Yes, you're spot on!

Running the script reviled the following. The issue I'm having now is finding the correct way of including the configs, I tried setting them in my myKernelConfigs.cfg and IMAGE_INSTALL_append = "docker-moby-contrib kernel-module-nf-nat kernel-module-xt-conntrack kernel-module-xt-addrtype"

But running the config script still shows the output below:

root@generic-arm64:/usr/share/docker# ./check-config.sh
info: reading kernel config from /proc/config.gz ...
Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: missing
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: missing
- CONFIG_NF_NAT_IPV4: missing
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: missing
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing
- CONFIG_POSIX_MQUEUE: enabled

On 30/09/2021, 17:48, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:
>
> Thanks for the reply Bruce __ Let me know if these details help?
>
> root@generic-arm64:~# uname -r
> 5.10.46-yocto-standard
>
> Only setting these two kernel configs at the moment:
> CONFIG_ENA_ETHERNET=y
> CONFIG_BLK_DEV_NVME=y

It'll be the iptables and cgroups options that are causing issues.

The standard layers and kernel are extensively tested with meta-virt,
so there really shouldn't be something missing.

You can also install the docker-contrib package to your image, and run
the check-config.sh script to see if it reports any issues.

Bruce

>
> And these are the layers, running harknott...
> drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
> drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
> drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
> drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
> drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/
>
>
> On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
> <stephibb=amazon.co.uk@...> wrote:
> >
> > Hello all!
> >
> > The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
> >
> > Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
> >
> > iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
> >
> > level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
> >
> > Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
> >
> > Any ideas for workarounds would be very much appreciated!
>
> It's your kernel configuration, coupled with the iptables modules
> available .. but most often, it is a missing kernel module.
>
> So without knowing exactly what kernel and hardware you are running,
> it is hard to say more.
>
> Bruce
>
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

In message: [meta-virtualization][hardknott][PATCH] openvswitch: Security fix for CVE-2021-36980
on 29/09/2021 Xu, Yanfei wrote:

Open vSwitch (aka openvswitch) 2.11.0 through 2.15.0 has
a use-after-free in decode_NXAST_RAW_ENCAP (called from
ofpact_decode and ofpacts_decode) during the decoding of
a RAW_ENCAP action.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36980

Patches from:
format-patch from ovs v2.15.1

Signed-off-by: Yanfei Xu <yanfei.xu@...>
---
...use-after-free-while-decoding-RAW_EN.patch | 101 ++++++++++++++++++
.../openvswitch/openvswitch_git.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644 recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch

diff --git a/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
new file mode 100644
index 00000000..c88c097d
--- /dev/null
+++ b/recipes-networking/openvswitch/files/0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch
@@ -0,0 +1,101 @@
+From 802a31a7070cea910b95d7e926c9da30a1f9e54f Mon Sep 17 00:00:00 2001
+From: Ilya Maximets <i.maximets@...>
+Date: Tue, 16 Feb 2021 23:27:30 +0100
+Subject: [PATCH] ofp-actions: Fix use-after-free while decoding RAW_ENCAP.
+
+While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
+ofpbuf if there is no enough space left. However, function
+'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
+structure leading to write-after-free and incorrect decoding.
+
+ ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
+ 0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
+ WRITE of size 2 at 0x60600000011a thread T0
+ #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
+ #1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
+ #2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
+ #3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
+ #4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
+ #5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
+ #6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
+ #7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
+ #8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
+ #9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
+ #10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
+ #11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
+ #12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
+ #13 0x5391ae in main utilities/ovs-ofctl.c:179:9
+ #14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
+ #15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
+
+Fix that by getting a new pointer before using.
+
+Credit to OSS-Fuzz.
+
+Fuzzer regression test will fail only with AddressSanitizer enabled.
+
+Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
+Fixes: f839892a206a ("OF support and translation of generic encap and decap")
+Acked-by: William Tu <u9012063@...>
+Signed-off-by: Ilya Maximets <i.maximets@...>
+
+Upstream-Status: Backport
+CVE: CVE-2021-36980
+Signed-off-by: Yanfei Xu <yanfei.xu@...>
+---
+ lib/ofp-actions.c | 2 ++
+ tests/automake.mk | 3 ++-
+ tests/fuzz-regression-list.at | 1 +
+ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 | 0
+ 4 files changed, 5 insertions(+), 1 deletion(-)
+ create mode 100644 tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+
+diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
+index e2e829772..0342a228b 100644
+--- a/lib/ofp-actions.c
++++ b/lib/ofp-actions.c
+@@ -4431,6 +4431,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ {
+ struct ofpact_encap *encap;
+ const struct ofp_ed_prop_header *ofp_prop;
++ const size_t encap_ofs = out->size;
+ size_t props_len;
+ uint16_t n_props = 0;
+ int err;
+@@ -4458,6 +4459,7 @@ decode_NXAST_RAW_ENCAP(const struct nx_action_encap *nae,
+ }
+ n_props++;
+ }
++ encap = ofpbuf_at_assert(out, encap_ofs, sizeof *encap);
+ encap->n_props = n_props;
+ out->header = &encap->ofpact;
+ ofpact_finish_ENCAP(out, &encap);
+diff --git a/tests/automake.mk b/tests/automake.mk
+index 677b99a6b..fc80e027d 100644
+--- a/tests/automake.mk
++++ b/tests/automake.mk
+@@ -134,7 +134,8 @@ FUZZ_REGRESSION_TESTS = \
+ tests/fuzz-regression/ofp_print_fuzzer-5722747668791296 \
+ tests/fuzz-regression/ofp_print_fuzzer-6285128790704128 \
+ tests/fuzz-regression/ofp_print_fuzzer-6470117922701312 \
+- tests/fuzz-regression/ofp_print_fuzzer-6502620041576448
++ tests/fuzz-regression/ofp_print_fuzzer-6502620041576448 \
++ tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+ $(srcdir)/tests/fuzz-regression-list.at: tests/automake.mk
+ $(AM_V_GEN)for name in $(FUZZ_REGRESSION_TESTS); do \
+ basename=`echo $$name | sed 's,^.*/,,'`; \
+diff --git a/tests/fuzz-regression-list.at b/tests/fuzz-regression-list.at
+index e3173fb88..2347c690e 100644
+--- a/tests/fuzz-regression-list.at
++++ b/tests/fuzz-regression-list.at
+@@ -21,3 +21,4 @@ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-5722747668791296])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6285128790704128])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6470117922701312])
+ TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6502620041576448])
++TEST_FUZZ_REGRESSION([ofp_print_fuzzer-6540965472632832])
+diff --git a/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832 b/tests/fuzz-regression/ofp_print_fuzzer-6540965472632832
+new file mode 100644
+index 000000000..e69de29bb
+--
+2.27.0
+
diff --git a/recipes-networking/openvswitch/openvswitch_git.bb b/recipes-networking/openvswitch/openvswitch_git.bb
index 16ec4c72..56f1297c 100644
--- a/recipes-networking/openvswitch/openvswitch_git.bb
+++ b/recipes-networking/openvswitch/openvswitch_git.bb
@@ -30,6 +30,7 @@ SRC_URI += "git://github.com/openvswitch/ovs.git;protocol=git;branch=branch-2.15
file://0001-ovs-use-run-instead-of-var-run-for-in-systemd-units.patch \
file://0001-openvswitch-fix-do_configure-with-DPDK-19.11-error.patch \
file://0001-openvswitch-fix-netdev-dpdk-compile-error.patch \
+ file://0001-ofp-actions-Fix-use-after-free-while-decoding-RAW_EN.patch \

You are carrying local patches to your ovs recipe that don't match meta-virt.

As such, this didn't directly apply. I fixed it up and merged it.

But you should consider carrying those patches in a bbappend, so that
upstream sends like this have proper context, and I can be more sure
of the testing that is done on submissions.

I also took this as an opportunity to bump OVS in master, since I wanted
to be sure that we have the same CVE addressed there.

Bruce

"

LIC_FILES_CHKSUM = "file://LICENSE;md5=1ce5d23a6429dff345518758f13aaeab"
--
2.27.0

I've been watching for these as well, but haven't gotten to doing
my 'all' builds to trigger them.

Out of curiosity, what level of coverage do you end up with on
the meta-virt layers ? I'm just trying to scope out how many more
of these may be lurking :D

I've grabbed this, and will push it shortly.

Bruce

In message: [meta-virtualization][PATCH] oath: inherit pkgconfig
on 30/09/2021 Martin Jansa wrote:

In message: [meta-virtualization] [PATCH] kubernetes: update sed expression
on 26/09/2021 kai wrote:

From: Kai Kang <kai.kang@...>

It misses a backslash in sed expression and causes warning when
run do_compile:

Since this wasn't actually doing anything, we could likely drop it now.
I remember adding it, and without it, we'd have build issues .. so the
fact that it was building without it being properly done is a good
sign.

That being said, since we are far along in the dev cycle, I'd rather
not experiment with dropping it completely, so I've merged and pushed
the change.

Bruce

| sed: -e expression #1, char 35: Unmatched ) or \)

Signed-off-by: Kai Kang <kai.kang@...>
---
recipes-containers/kubernetes/kubernetes_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-containers/kubernetes/kubernetes_git.bb b/recipes-containers/kubernetes/kubernetes_git.bb
index e165ebe..1ba52b6 100644
--- a/recipes-containers/kubernetes/kubernetes_git.bb
+++ b/recipes-containers/kubernetes/kubernetes_git.bb
@@ -50,7 +50,7 @@ do_compile() {
export CGO_CFLAGS="${BUILD_CFLAGS}"
# as of go 1.15.5, there are some flags the CGO doesn't like. Rather than
# clearing them all, we sed away the ones we don't want.
- export CGO_LDFLAGS="$(echo ${BUILD_LDFLAGS} | sed 's/-Wl,-O1//g' | sed 's/-Wl,--dynamic-linker.*?( \|$\)//g')"
+ export CGO_LDFLAGS="$(echo ${BUILD_LDFLAGS} | sed 's/-Wl,-O1//g' | sed 's/-Wl,--dynamic-linker.*?\( \|$\)//g')"
export CC="${BUILD_CC}"
export LD="${BUILD_LD}"

--
2.17.1

On Thu, Sep 30, 2021 at 11:40 AM Hibbert, Stephen <stephibb@...> wrote:

Thanks for the reply Bruce __ Let me know if these details help?

root@generic-arm64:~# uname -r
5.10.46-yocto-standard

Only setting these two kernel configs at the moment:
CONFIG_ENA_ETHERNET=y
CONFIG_BLK_DEV_NVME=y

It'll be the iptables and cgroups options that are causing issues.

The standard layers and kernel are extensively tested with meta-virt,
so there really shouldn't be something missing.

You can also install the docker-contrib package to your image, and run
the check-config.sh script to see if it reports any issues.

Bruce

And these are the layers, running harknott...
drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/


On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
<stephibb=amazon.co.uk@...> wrote:
>
> Hello all!
>
> The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
>
> Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
>
> iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
>
> level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
>
> Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
>
> Any ideas for workarounds would be very much appreciated!

It's your kernel configuration, coupled with the iptables modules
available .. but most often, it is a missing kernel module.

So without knowing exactly what kernel and hardware you are running,
it is hard to say more.

Bruce

>
>
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Thanks for the reply Bruce __ Let me know if these details help?

root@generic-arm64:~# uname -r
5.10.46-yocto-standard

Only setting these two kernel configs at the moment:
CONFIG_ENA_ETHERNET=y
CONFIG_BLK_DEV_NVME=y

And these are the layers, running harknott...
drwxrwxr-x 12 ubuntu ubuntu 4096 Sep 29 14:02 meta-arm/
drwxrwxr-x 8 ubuntu ubuntu 4096 Sep 29 14:00 meta-ewaol/
drwxrwxr-x 11 ubuntu ubuntu 4096 Sep 29 15:09 meta-openembedded/
drwxrwxr-x 24 ubuntu ubuntu 4096 Sep 29 14:02 meta-security/
drwxrwxr-x 17 ubuntu ubuntu 4096 Sep 29 14:02 meta-virtualization/


On 30/09/2021, 16:32, "Bruce Ashfield" <bruce.ashfield@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
<stephibb=amazon.co.uk@...> wrote:
>
> Hello all!
>
> The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.
>
> Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/
>
> iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/
>
> level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go
>
> Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099
>
> Any ideas for workarounds would be very much appreciated!

It's your kernel configuration, coupled with the iptables modules
available .. but most often, it is a missing kernel module.

So without knowing exactly what kernel and hardware you are running,
it is hard to say more.

Bruce

>
>
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA Sarl, UK Branch, 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom, registered in England and Wales, UK Establishment No. BR019315

On Thu, Sep 30, 2021 at 10:41 AM Stephen via lists.yoctoproject.org
<stephibb=amazon.co.uk@...> wrote:

Hello all!

The current meta-virtualisation docker is incompatible with the legacy v1.8.7 iptables.

Docker version 20.10.3, build 41b3ea7e47 http://layers.openembedded.org/layerindex/recipe/176817/

iptables v1.8.7 (legacy) https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/iptables/

level=info time=2021-09-30T08:58:56Z msg="TaskHandler: Sending task change: TaskChange: [arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGra viton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623551d39c6ab -> STOPPED, Known Sent: NONE, PullStartedAt: 2021-09-30 08:58:55.809460935 +0000 UTC m=+5 2315.765706001, PullStoppedAt: 2021-09-30 08:58:55.919351717 +0000 UTC m=+52315.875596782, ExecutionStoppedAt: 2021-09-30 08:58:56.159356552 +0000 UTC m=+52316.115601617, container change: arn:aws:ecs:eu-west-1:116589935960:task/GravitonID-ecs-ECSGraviton2DA545608-tzdG3bupgLcn/ef8d9ea15a434c298a9623 551d39c6ab web -> STOPPED, Reason CannotStartContainerError: Error response from daemon: driver failed programming external connectivity on endpoint e cs-GravitonIDecsTaskDefA2CA7A76-4-web-9eb9aba094eccadb1300 (db13dc1931d5be70284cac4de6899246035db8e5f9e0cf9ee3773000801a70b0): (iptables failed: ipta bles --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8080 -j DNAT --to-destination 172.17.0.2:3000 ! -i docker0: iptables v1.8.7 (legacy): unknown optio n \"--to-destination\"\nTry `iptables -h' or 'iptables --help' for more information.\n (exit status 2)), Known Sent: NONE] sent: false" module=task_ha ndler_types.go

Possibly linked to this issue and nftables support? https://github.com/moby/moby/issues/38099

Any ideas for workarounds would be very much appreciated!

It's your kernel configuration, coupled with the iptables modules
available .. but most often, it is a missing kernel module.

So without knowing exactly what kernel and hardware you are running,
it is hard to say more.

Bruce

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi Luca,

On 30 Sep 2021, at 15:54, Luca Fancellu <Luca.Fancellu@...> wrote:

The mmc probing order has become unpredictable
due to recent linux kernel changes, therefore devices
like the raspberry pi that have two mmc interface most
of the time can't boot from the hard-coded root path.

Modify the u-boot script to fetch the PARTUUID of the
second partition of the sd card and use it to put
root=PARTUUID=<xxx> in the command line passed to
the dom0 kernel.

Signed-off-by: Luca Fancellu <luca.fancellu@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Cheers
Bertrand

---
.../xen-rpi-u-boot-scr/files/boot.cmd.xen.in | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/files/boot.cmd.xen.in b/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/files/boot.cmd.xen.in
index 0367e36..9874220 100644
--- a/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/files/boot.cmd.xen.in
+++ b/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/files/boot.cmd.xen.in
@@ -13,10 +13,6 @@ fdt resize 0x1000
echo Add boot arguments for Xen
fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=/soc/serial@7e215040 dom0_mem='@@RPI_DOM0_MEM@@' @@RPI_DEBUG_XEN_ARGS@@"

-echo Add boot arguments for dom0
-setenv dom0_bootargs "console=hvc0 earlycon=xenboot debug root=/dev/mmcblk0p2 rootwait"
-fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
-
echo Add a dom0 node to chosen to put Linux boot information in
fdt mknode /chosen dom0

@@ -32,6 +28,13 @@ fdt rm /scb/pcie@7d500000/pci@1,0/usb@1,0
echo Delay to allow the MMC card to be ready
sleep 1

+# Retrieve PARTUUID for the rootfs partition of the sdcard
+part uuid mmc 1:2 rootfs_partuuid
+
+echo Add boot arguments for dom0
+setenv dom0_bootargs "console=hvc0 earlycon=xenboot debug root=PARTUUID=${rootfs_partuuid} rootwait"
+fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
+
echo Load Xen into memory
fatload mmc 1:1 ${xen_loadaddr} xen
echo Xen loaded, size: 0x$filesize
--
2.17.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Luca,

On 30 Sep 2021, at 15:54, Luca Fancellu <Luca.Fancellu@...> wrote:

Syntax conversion for bbappend linux-yocto_5.10
and linux-yocto-dev inside the raspberrypi
dynamic layer.

Signed-off-by: Luca Fancellu <luca.fancellu@...>

Reviewed-by: Bertrand Marquis <bertrand.marquis@...>

Thanks a lot for that :-)

Cheers
Bertrand

---
.../recipes-kernel/linux/linux-yocto-dev.bbappend | 6 +++---
.../recipes-kernel/linux/linux-yocto_5.10.bbappend | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto-dev.bbappend b/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto-dev.bbappend
index 8381e44..5f43052 100644
--- a/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1,8 +1,8 @@
# For a Xen-enabled distro on the Raspberry Pi, override the contents of cmdline.txt
# with Xen-on-ARM-specific command line options

-KBRANCH_raspberrypi4-64 ?= "standard/bcm-2xxx-rpi"
-KMACHINE_raspberrypi4-64 ?= "bcm-2xxx-rpi4"
-COMPATIBLE_MACHINE_raspberrypi4-64 = "(raspberrypi4-64)"
+KBRANCH:raspberrypi4-64 ?= "standard/bcm-2xxx-rpi"
+KMACHINE:raspberrypi4-64 ?= "bcm-2xxx-rpi4"
+COMPATIBLE_MACHINE:raspberrypi4-64 = "(raspberrypi4-64)"

require linux-yocto_xen-rpi.inc
diff --git a/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto_5.10.bbappend b/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto_5.10.bbappend
index af92493..f279ef7 100644
--- a/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/dynamic-layers/raspberrypi/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -1,6 +1,6 @@
# Enable use of the linux-yocto 5.10 kernel for the Raspberry Pi 4
-KBRANCH_raspberrypi4-64 ?= "v5.10/standard/bcm-2xxx-rpi"
-KMACHINE_raspberrypi4-64 ?= "bcm-2xxx-rpi4"
-COMPATIBLE_MACHINE_raspberrypi4-64 = "(raspberrypi4-64)"
+KBRANCH:raspberrypi4-64 ?= "v5.10/standard/bcm-2xxx-rpi"
+KMACHINE:raspberrypi4-64 ?= "bcm-2xxx-rpi4"
+COMPATIBLE_MACHINE:raspberrypi4-64 = "(raspberrypi4-64)"

require linux-yocto_xen-rpi.inc
--
2.17.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.