From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 51CE42A2D3; Tue, 16 Aug 2022 15:51:09 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 121842A2C0; Tue, 16 Aug 2022 15:51:06 +0000 (UTC) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by atuin.qyliss.net (Postfix) with ESMTPS id C666F2A2BF for ; Tue, 16 Aug 2022 15:51:01 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id y13so19654499ejp.13 for ; Tue, 16 Aug 2022 08:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=6gpQMY9Am8JdwtDUidTZmhAhOCyNAd+3QF1P8ppluiU=; b=VYrnULy6cDoB1b04ObqBH6JNLciGeDdMyre9yZp9RSVXBFayLdQLyTgmaQ2a9BZXt5 TLhYs7/hkoDN7slq4VrBG7pgP57WDRwLysc4o4ZN27WKSFzCo60ginrgDacRywO7ms7N 42GuGGB26P8eZSJSgNGmlwwCnbNDkIFAxpIVx05Fj1tES/zSlaUZG6Lfk/Ao5ZnvCq2g HIUFJQ8Ao6SDNv1DbCxBamDy3bq6Rmj0ZHOUuxxTPK9C4tX9Uh4XQY9fYVekqPaDxu1f uuktQQt27gZVd6Hy6ysNmRXuWcYaNQWOUs6v7VAGnr7TUAF+4ncf3o6ey1zpxxwHt1ce NadQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=6gpQMY9Am8JdwtDUidTZmhAhOCyNAd+3QF1P8ppluiU=; b=vb7wdbaPaT0NaLNpcBuuTWKXIxFhuhm1DaPHB4GpKqZLxcuzL4JH3v629oI6PZap5P xkv/2GoRGum2huHaWO7zsmrfRdmUhhgPM029Gn64yummD7isS8xb8UljuWSdXXG3fSif +nzCJuJxBMsHYL3L+m7iZTTRK3Mz/M5zX5/rj/X2e7qtmRQ24+9Dyz8BBT8NmV7KNqDR 26Zwj1uFLuU1XgDIAeJUdVh7kAQgteOdsBxPsrtbsjbE8rDFu+BWFJVVTvdF9eORZgVW H28K6NQJq4+VrIYylZ3a8LTxiXgVupXoPMpndslDgpUHdrtcEFuniruOHgS3fohTO/qL 7oSA== X-Gm-Message-State: ACgBeo2vPIQGedhoF+hCiznFjlID05RTIEs/DQ2e2kqRkuEwKcVyWt4q HoBeRHBOQEv0OxLPF1/X4rz/L3R6uWoI2sU+f8JRQj09B3D4+Q== X-Google-Smtp-Source: AA6agR4ihxOuKWOBVnOj4aDlmbzfk+unRgMFlPig/f4rYyaemnRjR2Y0ovRUbGRVxOfRmfinVJkUqsQotzFXSiVMUC8= X-Received: by 2002:a17:906:9b14:b0:730:984e:a51c with SMTP id eo20-20020a1709069b1400b00730984ea51cmr13509630ejc.435.1660665059183; Tue, 16 Aug 2022 08:50:59 -0700 (PDT) MIME-Version: 1.0 From: Ville Ilvonen Date: Tue, 16 Aug 2022 18:50:48 +0300 Message-ID: Subject: HW identification and configuration on Spectrum To: discuss@spectrum-os.org Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: FNAYLYK5AYTWZYFZTXNN5AWEBDCBF2DZ X-Message-ID-Hash: FNAYLYK5AYTWZYFZTXNN5AWEBDCBF2DZ X-MailFrom: ville.ilvonen@unikie.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-discuss.spectrum-os.org-0; header-match-discuss.spectrum-os.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.5 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, Now that we've been developing Spectrum ARM (aarch64) support with iMX8 boards, I'd like to get back to Spectrum HW configuration design. On x86 the generic image with kernel supporting most devices as modules can make sense. On ARM, the vendor specific BSP HW quirks are more common. As of now, the spectrum fork for aarch64 just adds another config after rpi configs and replaces the default config to use that to build. With small changes this could be handled like rpi configs. In addition, cloud-hypervisor accepts kernel only in EFI format for aarch64[1]. Anyway, this would allow us to build an aarch64 Spectrum installer - even make it with a more generic kernel. That takes us to ARM vendor/device specific HW quirks which would need to be handled anyway. I'll intentionally leave device specific kernel hardening and disabling kernel module loading for security reasons for now. As of now the vendor/device specifics are not supported unless one builds device specific Spectrum image with all configs build-time and skips installer altogether. The other option that I see. We discussed earlier nix-hardware and device specific modules. That would bring nixos configuration.nix and installation supporting scripts to Spectrum, though. Those could be called from the Spectrum installer but it would change the installer logic from writing an image to dynamically configuring the device during install based on user selections. Any thoughts which would be the preferred way? Maybe some other way? In the end, HW specifics are needed also on x86 as we saw with NUCs and different Lenovo laptops in the spring. I'm not convinced one image to rule them all is realistic or secure. Finally, this is by no means blocking the hardened iMX8 based Spectrum development but will keep that work in Spectrum fork until there's an agreed path to implement this. Integrating this sooner and making it more generic would make Spectrum more useful for a wider audience. Best regards, -Ville [1] https://github.com/tiiuae/spectrum/pull/3#issuecomment-1211834302