Am Samstag, 23. September 2023, 23:11:36 CEST schrieb cagsm:

On Sat, Sep 23, 2023 at 11:02 PM Stephan Hemeier wrote:

...

Am Samstag, 23. September 2023, 22:42:33 CEST schrieb cagsm:

...

Linux 5.14.21-150500.55.22-default # The kernel is retracted, so please delete this kernel Version.

why and where does this information come from? i have nowhere read about it?! is there any transparent information and good sources for whereabouts and happenings with opensuse for such stuff? is there a workflow for retraction of packages releases and patches and such? please tell me more about it. ty

Here: https://bugzilla.suse.com/show_bug.cgi?id=1215522 Also see: zypper se -s kernel-default | grep -i vR vR | kernel-default | Paket | 5.14.21-150500.55.22.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 vR | kernel-default-devel | Paket | 5.14.21-150500.55.22.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 vR | kernel-default-extra | Paket | 5.14.21-150500.55.22.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 vR | kernel-default-optional | Paket | 5.14.21-150500.55.22.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 The R in the first column means: .R is shown in the 2nd column if the item has been retracted (see patch in section Package Types) See man zypper

I have managed to still fetch the retracted (? where is this exactly documented and talked about? ....55.22 kernel-default and -devel and what not package so vboxconfig now kind of runs builds compiles or something but fails at the end? is the reason maybe that this physical hosting system is using uefi and secureboot both activated? ------- sudo /usr/sbin/vboxconfig Building kernel modules... Kernel modules built correctly. They will now be installed. insmod /lib/modules/5.14.21-150500.55.22-default/weak-updates/extra/vboxdrv.ko modprobe: ERROR: could not insert 'vboxnetflt': Key was rejected by service insmod /lib/modules/5.14.21-150500.55.22-default/weak-updates/extra/vboxdrv.ko modprobe: ERROR: could not insert 'vboxnetadp': Key was rejected by service Kernel modules are installed and loaded. ----------- how to run virtualbox on opensuse 15.5 with a uefi and secureboot activated system? ty.

On 2023-09-24 01:15, Larry Len Rainey wrote:

there is no need to run "sudo /usr/sbin/vboxconfig" - that is the Oracle way to install VirtualBox and is not the OpenSUSE way.

the VirtualBox install for the OpenSUSE host is:

sudo zypper in virtualbox virtualbox-kmp-default virtualbox-qt

all that should be automatic once you do "zypper in virtualbox" -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

On 2023-09-24 02:48, Stephan Hemeier wrote:

Am Sonntag, 24. September 2023, 00:05:08 CEST schrieb cagsm:

...

so vboxconfig now kind of runs builds compiles or something but fails at the end? is the reason maybe that this physical hosting system is using uefi and secureboot both activated?

As Larry pointed out, there is no need for recreating the Kernel Modules after Kernel Update. They will be recreated (maybe only cpoied) automatically into the new Kernel.

If they do not work, just open an Bugreport and Larry get notes on it.

The wiki is ou-of-sync

Stephan

When virtualbox-kmp-default is installed, the modules are installed directly to /lib/modules//extra where is the running kernel at that time. When the kernel is updated, the modules are copied to /lib/modules//weak-updates/extra where is the updated (new) kernel version.

On 2023-09-24 10:48, Stephan Hemeier wrote:

Am Sonntag, 24. September 2023, 00:05:08 CEST schrieb cagsm:

...

so vboxconfig now kind of runs builds compiles or something but fails at the end? is the reason maybe that this physical hosting system is using uefi and secureboot both activated?

As Larry pointed out, there is no need for recreating the Kernel Modules after Kernel Update. They will be recreated (maybe only cpoied) automatically into the new Kernel.

If they do not work, just open an Bugreport and Larry get notes on it.

The wiki is ou-of-sync

Somebody that knows should edit the wiki. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

Am Sonntag, 24. September 2023, 19:16:17 CEST schrieb cagsm:

this doesnt alter the facts that my machine here more like hints into the uefi and security keys (MOK as in mokutil comes to my mind?) direction as the problem it really tires me that i come around so many problems with opensuse in the OSS world that i have imaged to be problematic topics

why does virtualbox actually need some additional driver? module? in the linux kernel of the host itself? its all so odd and strange to me. ty The kernel vR | kernel-default | Paket | 5.14.21-150500.55.22.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15

is buggy, fingerprintreader, USB-Lan, USB is buggy. So delete the Kernel Version because the virtualbox-kmp-default is copied into the kernels directory and may be not working. For documentation of Virtualbox read here: https://www.virtualbox.org/manual/UserManual.html

On Sun, Sep 24, 2023 at 10:12 PM Larry Len Rainey wrote:

Following the virtualbox documentation is not the OpenSUSE way - If you want pure Oracle code - then follow it - but do not complain on the OpenSUSE support as we do not support the Oracle version - Just the OpenSUSE version.

i AM using the virtualbox package that yast installs frrom the normal leap 15.5 repos. i think i stated this in my very first post. too bad i am disappointing you

On Mon, Sep 25, 2023 at 4:23 PM cagsm wrote:

i removed all the virtualbox packages via yast2 softwaremanagement. i re added virtualbox stuff. it selected some stuff addtl automagically. some kernel kmp and some virtualbox qt or something.

first initial startup from kde menu of virtualbox shows one question regarding USB passthrough and security safety issue with that. this can not possibly be one/the reason as to not be able to run virtualbox guest?

i select no, dont use usb passthrough and dont open security hole issue. (selecting: disable).

it then executes some shell script that sets rules.d or something. then virtualbox gui appears my debian one guest attempt still being there. i try firing up that guest. it quickly shows error. red "X" that i need to execute /sbin/vboxconfig which isnt even correct as there is no such path and command there. on my 15.5 there is ONLY /usr/sbin/vboxconfig this is all just so wrong and buggy, isnt it? how can anyone disagree? ty

On Mon, Sep 25, 2023 at 4:57 PM Andrei Borzenkov wrote:

Is Secure Boot enabled? If yes, did you import certificates for VirtualBox modules?

uefi and secureboot of the physical host machine is enabled. i have written this in this thread before. import what certificates where to exactly? meanwhile I have kind of researched more into this mokutil stuff and "KMP" kernel module packages was a new term to me, and with the help of this i found some germanic website speaking about exactly this shortcoming of opensuse and the mix with SLEs/suse corp. and everything thats related and some older release notes of suse 15.3 and newer also speak about NVIDIA and KMPs and mokutil needing to enroll some? key into the MOK database to make nvidia KMP to work. tanslate google: https://curius.de/2022/05/virtualbox-in-opensuse-leap-mit-secure-boot/ leading also to dealings about NVIDIA KMP stuff.... https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.5/index.html

4 Drivers and Hardware # 4.1 Secure Boot: Third-Party Drivers Need to Be Properly Signed

and https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/index.html leading and speaking of kernel KMP stuff specially for virtualbox

4 Drivers and hardware Report Documentation Bug # 4.1 Secure Boot: SUSE Linux Enterprise kernel and openSUSE signed Kernel Module Packages Report Documentation Bug # The newly introduced openSUSE-signkey-cert package is required for openSUSE KMPs like virtualbox,

so i guess I need to mokutil some key as well? from that

.... openSUSE-signkey-cert package.....

That blog post up there wondering why opensuse team does not automagically enroll the key into MOK database, and thats also me wondering the same? i have like exactly one KMP naed file in /etc/uefi/certs/ ..... named: 1F673297-kmp.crt belonging apparently to certain RPM rpm -qf 1F673297-kmp.crt openSUSE-signkey-cert-20220613-lp155.3.5.x86_64 am I headed for the right direction? the question remaind why doesnt this MOK enrollment does not happen automatically actually for the user? this seems like serious technocalities just in order to run an opensource piece of software called virtualbox on a linux or on opensuse especially. ty

On Tue, Sep 26, 2023 at 8:57 AM Andrei Borzenkov wrote:

Show full output of mokutil --list-enrolled

there is only a single key in the mok database or what it is called, the corp key of suse linux enterprise secure boot

mokutil --list-enrolled | grep \\[key | wc -l 1

mokutil --list-enrolled [key 1] SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de Validity Not Before: Apr 18 14:33:41 2013 GMT Not After : Mar 14 14:33:41 2035 GMT .....

thank you for help.

On 2023-09-26 13:08, cagsm wrote:

semi offtopic question here additionally about mokutil and its database and this password one sets when adding? enrolling? settingup? another key into its database.

what is this password exactly about? is this a kind of one time challenge/password just to be asked once during next reboot to insert the additional key into the mok database? why? (maybe it can?) can it not be inserted directly into the MOK-database directly? is this some security measure? how? did enterprise suse corporate key become inserted into the MOK database? what was the password for that situation? can i just have or re use that password to begin with? i kind of like to know what reasoning there is behind a password protection and what architecture. can or must i keep track of this password (my password) for the future? or is it only like used once only (as i have thought about it above)

i dont yet understand the password concept of this MOK database stuff. i found some whateverxxxxexchange discussion about some debian or ubuntu folks also trying to virtualbox installation their stuff and having huge loads of problems with the MOK password about early boot initial keyboard layout settings and what not and even such claims as MOK password were only to be allowed for five characters max or stuff. this kind of hints for me that its rather a one time only challenge or something.

When during boot you get asked for a password to enroll a key, that is root's password. But it is not clear, it could be the BIOS password. The wording in the piece of software asking for it is not clear. The software appears to come from the BIOS, because it comes in plain ugly text during the BIOS boot. But in fact comes from openSUSE. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

On 2023-09-26 14:15, Larry Len Rainey wrote:

It is the root password of your OpenSUSE Linux - your BIOS needs permission to install it - kind of like what sudo does when in a terminal.

How come the BIOS knows the password of my operating system? Hint: it is not the bios.

If you install virtualbox via "sudo zypper virtualbox" it is signed with the OpenSUSE MOK. If you install it from Oracle VirtualBox - you have to sign it yourself and that is the key the BIOS is looking for to install virtualbox-kmp-default.

He installed the openSUSE rpm. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

* cagsm [09-26-23 09:36]:

On Tue, Sep 26, 2023 at 2:21 PM Carlos E. R. wrote:

...

He installed the openSUSE rpm.

thanks for the replies in this thread, its good to do some own research on the web actually ;) to withstand half truths und fully made up stuff or so. never the less thanks mostly everybody.

turns out the MOK password is just a one time used-once-only stuff to help handling interactively a highly security sensitive situation namely adding keys to the secure boot chain and trusted code signature keys and what not according to:

...

https://unix.stackexchange.com/questions/679695/security-boot-and-mok-passwo...

still wondering as I dont remember ever having seen that blue? MOK enrollment procedure and simple screen during bootup how did the suse corporate enterprise key become inserted into the MOK database, if MOK is always supposed to have this interactive step to make sure a real user on a physical machine is acknowledging these security sensitive steps? maybe there are other ways to add stuff to the MOK database programmatically automagically nevertheless?

...

https://en.opensuse.org/openSUSE:UEFI

article shows some path names (now already deprecated and moved slightly elsewhere speaking about the actual MOK stuff on disk etc as far as I have roughly researched

...

/usr/lib64/efi/

been moved to

...

/usr/share/efi/ and in there to ./x86_64/

having populated .der files and .efi files some shim and whatnot. maybe this isnt actually the place of the MOK database? not yet an expert ;P :>

before rebooting, follow below to make keys available in mok utility. the certs for the nvidia driver exist in /var/lib/nvidia-pubkeys/ mokutil --root-pw --import /var/lib/nvidia-pubkeys/<latest der file> my last: mokutil --root-pw --import /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G06-535.86.05-11.9-default.der when rebooting the blue "mok" screen will appear (I cannot remember exact options). select "inroll key(s)" iirc password requested will be root's as "--root-pw" specifies. a good explanation: https://unix.stackexchange.com/questions/535434/what-exactly-is-mok-in-linux... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On Tue, Sep 26, 2023 at 7:27 PM Andrei Borzenkov wrote:

This key is embedded into shim. Normally you do not need to explicitly enroll any key as long as your shim, kernel and additional kernel modules all come from the same vendor (in this case SUSE).

embedded in the shim? is this some superior security means in contrast to that MOK stuff? anyhow that mokutil listing keys only shows opensuse enterprise corporate linux secureboot key. but in

/lib/modules/5.14.21-150500.55.22-default/weak-updates/extra vboxdrv.ko -> /lib/modules/5.14.21-150500.55.7-default/extra/vboxdrv.ko

/lib/modules/5.14.21-150500.55.7-default/extra> rpm -qf vboxdrv.ko virtualbox-kmp-default-7.0.10_k5.14.21_150500.55.7-lp155.2.5.1.x86_64

but this virtualbox rpm is built / signed (?) by the opensuse folks and not by the suse enterprise linux folks rpm -qi virtualbox-kmp-default-7.0.10_k5.14.21_150500.55.7-lp155.2.5.1.x86_64 Name : virtualbox-kmp-default Version : 7.0.10_k5.14.21_150500.55.7 Release : lp155.2.5.1 Architecture: x86_64 Install Date: Mon 25 Sep 2023 04:19:17 PM CEST Group : System/Kernel Size : 2000994 License : GPL-2.0-or-later Signature : RSA/SHA512, Mon 24 Jul 2023 01:27:48 PM CEST, Key ID 35a2f86e29b700a4 Source RPM : virtualbox-kmp-7.0.10-lp155.2.5.1.src.rpm Build Date : Mon 24 Jul 2023 01:27:40 PM CEST Build Host : goat43 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE -------------- and the kernel itself and the shim and all basics essential boot stuff is built / signed (?) by the suse LLC (enterprise folks) i guess... Source Timestamp: 2023-08-08 22:15:01 +0000 GIT Revision: 9908c297db56e74e320d2a98ec399b588ec136ca GIT Branch: SLE15-SP5_EMBARGO Distribution: SUSE Linux Enterprise 15 Name : kernel-default Version : 5.14.21 Release : 150500.55.22.1 Architecture: x86_64 Install Date: Wed 20 Sep 2023 03:04:22 PM CEST Group : System/Kernel Size : 185348636 License : GPL-2.0-only Signature : RSA/SHA256, Fri 08 Sep 2023 11:24:32 AM CEST, Key ID 70af9e8139db7c82 Source RPM : kernel-default-5.14.21-150500.55.22.1.nosrc.rpm Build Date : Fri 08 Sep 2023 11:17:02 AM CEST Build Host : h01-ch5a Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC https://www.suse.com/ ----------- so i quickly guessed and deducted that I am having a secureboot uefi trouble running this funny virtualbox on linux making users lives so hard. so is this really a virtual box package bug in opensuse leap 15.5, is secureboot and uefi so exotic and rare that nobody actually runs virtualbox this way I attempted and nobody comes across these bugs? then again, that germanic blog post i found before also talked about exactly this stuff and the blog author was also wondering why this opensuse key never made it into the MOK (or whereto ever) to begin with on opensuse distros. i also strongly wonder, why doesnt the opensuse secure boot key get automagically MOKed into the opensuse users systems and installations? this makes no sense to give the opensuse users such a bad rap and hassle? anyone care for opensuse or are we opensuse usersbase only the easy laborers, betatesters and incubators for the enterprise suse customers and userbase? ty

On Wed, Sep 27, 2023 at 3:22 PM Andrei Borzenkov wrote:

...

embedded in the shim? is this some superior security means in contrast to that MOK stuff? I do not understand this question, I do not even understand if this is a question or rant.

no i only was trying to still undstand this situation. is everything at the end of the day a MOK and stored in this MOK database? because on my leap 15.5 machine as this thread shows, there is only that suse enterprise secureboot key stored there. i was only asking if the shim mechanism maybe is having additional keys embedded inside itself and stored elsewhere or so. this reminds me of UEFIs (bioses) that also have some kind of menu about root keys of microsoft for all this secureboot stuff and some allowing the user to select additional keys and enroll via uefi etc. i now wonder where actually this MOK database or this UEFI way to enroll all is stored at the end of the day. i never managed to look into this NVRAM and stuff if thats anything got to do with it. where are these stores to begin with as some? they need to be very early accessible etc. does this MOK stuff (vanilla opensuse 15.5 situation, for this virtualbox and leap 15.5) actually work the very same way with FDE (full disc encryption)? then the MOK database and these keys cant be stored on disk i guess and need to be stored outside of FDE? then again there is this fat? fat32? partition in the UEFI world that always needs to be accessible or something? so many confusing or complex things.

...

so is this really a virtual box package bug in opensuse leap 15.5, is

I do not have 15.5 right now, but on 15.4 openSUSE-signkey-cert is recommended by minimal base pattern. And openSUSE-signkey-cert enrolls its key when it is installed. It does require explicit user intervention during the next boot which is easy to miss or to misunderstand and ignore.

But yes, in general I believe this is the wrong way to do it. Each package that installs signed modules should at least recommend a package containing its signing key.

i wonder how can I sort out this situation now to arrive at the real actually intended situation of 15.5 (if there is any? that german blog also described the shortcomings early 2022 though). i have not yet memorized the situation with the keys for MOK, those .der files or crypto stuff, there are supposedly two files if the user creates keys of their own to enroll into MOK and one needs to go wherever and the other needs to go another place or something so I understood briefly so far. ty

On Wed, Sep 27, 2023 at 8:17 PM Andrei Borzenkov wrote:

Do you have openSUSE-signkey-cert package installed? What is the content of /etc/uefi/certs?

the package rpm is installed on this 15.5 and the kmp crt file is also there in /etc/uefi/certs/ 1F673297-kmp.crt

Just enroll /etc/uefi/certs/1F673297-kmp.crt mokutil --import /etc/uefi/certs/1F673297-kmp.crt and reboot.

i did enroll that key and a reboot brought up the blue MOK stuff and the key gotton displayed its details opensuse key, and then added and rebooted. the vboxdrv service is happily loading and running now on this 15.5

sudo dmesg -e | grep -i box [ +0.111111] vboxdrv: loading out-of-tree module taints kernel. [ +0.111111] vboxdrv: Found 16 processor cores/threads [ +0.111111] vboxdrv: TSC mode is Invariant, tentative frequency 1896435273 Hz [ +0.111111] vboxdrv: Successfully loaded version 7.0.10 r158379 (interface 0x00330004) [ +0.111111] VBoxNetFlt: Successfully started. [ +0.111111] VBoxNetAdp: Successfully started.

wondering what went wrong in the first place? ty all.

On Thu, Sep 28, 2023 at 8:52 AM Andrei Borzenkov wrote:

Most likely you simply did not pay attention. The MokManager screen is shown for a short time (I think 10 - 15 seconds) and it is easy to miss it.

can i un-enroll this opensuse secureboot key (remove) and uninstall virtualbox package and maybe even this openSUSE-signkey-cert package? but this had been installed back this summer, and i only started adding virtualbox package via yast when i started this thread. so the installation of virtualbox package should have MOK-enrolled the key from that signkey-cert package, right? and after a reboot, the blue MOK and it should have been there? i cant remember a blue MOK screen ever since i started this thread. but when removing the virtualbox packages, the opensuse secureboot key from MOK and starting all over should be the test of these procedures, right? ty

On 2023-09-27 14:41, cagsm wrote:

On Tue, Sep 26, 2023 at 7:27 PM Andrei Borzenkov wrote:

...

This key is embedded into shim. Normally you do not need to explicitly enroll any key as long as your shim, kernel and additional kernel modules all come from the same vendor (in this case SUSE).

embedded in the shim? is this some superior security means in contrast to that MOK stuff? anyhow that mokutil listing keys only shows opensuse enterprise corporate linux secureboot key.

Laicolasse:~ # ls -lh /boot/efi/EFI/opensuse_main/ total 3.2M -rwxr-xr-x 1 root root 833K Jul 20 18:58 MokManager.efi -rwxr-xr-x 1 root root 68 Jul 20 18:58 boot.csv -rwxr-xr-x 1 root root 173 Jul 20 18:58 grub.cfg -rwxr-xr-x 1 root root 1.3M Jul 20 18:58 grub.efi -rwxr-xr-x 1 root root 220K Jul 20 18:58 grubx64.efi -rwxr-xr-x 1 root root 932K Jul 20 18:58 shim.efi <======= Laicolasse:~ # The MOK database is inside the "BIOS" aka UEFI. You have to install openSUSE-signkey-cert Laicolasse:~ # rpm -q openSUSE-signkey-cert openSUSE-signkey-cert-20220613-lp155.3.5.x86_64 Laicolasse:~ # And on the next boot you should get a text prompt before the GRUB prompt, to accept the key. Notice that this prompt is very confusing. And if you say "no" by mistake it is no for ever. Laicolasse:~ # mokutil --list-enrolled | grep -i openSUSE Issuer: CN=Kernel OBS Project/emailAddress=Kernel@build.opensuse.org Subject: CN=Kernel OBS Project/emailAddress=Kernel@build.opensuse.org Issuer: CN=home:tiwai OBS Project/emailAddress=home:tiwai@build.opensuse.org Subject: CN=home:tiwai OBS Project/emailAddress=home:tiwai@build.opensuse.org Laicolasse:~ # -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))