On M3 pro - running elasticsearch 8.15.0 amd64 image fails with seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, while aarch64 runs ok

Description

Elasticsearch version 8.x image requires specific kernel parameters to be enabled regarding seccomp (i.e. CONFIG_SECCOMP). In the aarch64 this seems to be enabled while on Virtualization framework running kernel

6.10.4-linuxkit #1 SMP Mon Aug 12 08:47:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

this is not the case, and information given from java, probably grepping the kernel info gives

{
    "@timestamp": "2024-09-05T11:43:05.159Z",
    "log.level": "WARN",
    "message": "unable to install syscall filter: ",
    "ecs.version": "1.2.0",
    "service.name": "ES_ECS",
    "event.dataset": "elasticsearch.server",
    "process.thread.name": "main",
    "log.logger": "org.elasticsearch.bootstrap.JNANatives",
    "elasticsearch.node.name": "eae26c902e2b",
    "elasticsearch.cluster.name": "docker-cluster",
    "error.type": "java.lang.UnsupportedOperationException",
    "error.message": "seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed",
    "error.stack_trace": "java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.SystemCallFilter.linuxImpl(SystemCallFilter.java:331)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.SystemCallFilter.init(SystemCallFilter.java:622)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.JNANatives.tryInstallSystemCallFilter(JNANatives.java:35)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.Natives.tryInstallSystemCallFilter(Natives.java:59)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.Elasticsearch.initializeNatives(Elasticsearch.java:298)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.Elasticsearch.initPhase2(Elasticsearch.java:170)\n\tat org.elasticsearch.server@8.15.0/org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:75)\n"
}

I this considered a bug or intentional behavior? And if intentionally, is there a possible way to manipulate the kernel Virtualization framework uses for amd64?

Reproduce

run docker run --name elasticsearch --platform=linux/amd64 -p 9200:9200 -p 9300:9300 -d -m 1GB docker.elastic.co/elasticsearch/elasticsearch:8.15.0
follow docker logs elasticsearch -f and see the startup logs, but fails with ec 78 in few seconds due detected missing mandatory seccomp in kernel

Expected behavior

linuxkit amd64 kernel should have CONFIG_SECCOMP compiled and named image should start flawlessly

docker version

Client:
 Version:           27.2.0
 API version:       1.47
 Go version:        go1.21.13
 Git commit:        3ab4256
 Built:             Tue Aug 27 14:14:45 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.34.0 (165256)
 Engine:
  Version:          27.2.0
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.21.13
  Git commit:       3ab5c7d
  Built:            Tue Aug 27 14:15:41 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.20
  GitCommit:        8fc6bcff51318944179630522a095cc9dbf9f353
 runc:
  Version:          1.1.13
  GitCommit:        v1.1.13-0-g58aa920
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    27.2.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.16.2-desktop.1
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.2-desktop.2
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.34
  desktop: Docker Desktop commands (Alpha) (Docker Inc.)
    Version:  v0.0.15
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.25
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.3.0
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
  scout: Docker Scout (Docker Inc.)
    Version:  v1.13.0

Server:
 Containers: 8
  Running: 7
  Paused: 0
  Stopped: 1
 Images: 27
 Server Version: 27.2.0
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8fc6bcff51318944179630522a095cc9dbf9f353
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.10.4-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 9
 Total Memory: 7.655GiB
 Name: docker-desktop
 ID: c7b54c78-7f30-4f11-820b-cc6c0725795b
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/user/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

Diagnostics ID

CCDCEAD9-1409-4A88-9BFD-AF800BE28BE2/20240905123104

Additional Info

No response

docker / for-mac