Re: [systemd-devel] FW: Requesting commercial support if applicable for systemd-cryptenroll --pkcs11-token-uri

[Yogesh Tokas]

Dear Lennart,

This response below gets derived automatically by the email engine. I have not 
posted it.

I really appreciate the feedback below, let us try the below what you suggested 
and get back here with results.

I apologise on behalf of our mailing engine. I shall report it to our IT.

BR,
Yogesh

Sent from my iPhone

> On 19. Jan 2023, at 22:10, Lennart Poettering  wrote:
>
> gOn Do, 19.01.23 12:45, Yogesh Tokas (yogesh.to...@utimaco.com) wrote:
>
>> systemd-cryptenroll 
>> --pkcs11-token-uri="pkcs11:model=CryptoServer;manufacturer=Utimaco%20IS%20GmbH;serial=SI003001_;token=LUKS;id=%45;object=LUKSCert;type=cert"
>>  /dev/sdc1
>>
>> This command gives us no clue, our logs and systemd logs won't show
>> anything promising to debug further. Since, pkcs11-token is one of
>> the options supported by systemd I am sure it is possible to
>> integrate, however, there might be some changes required in our p11
>> library. We are looking for some guidance and if this requires us to
>> agree on some cost, I am happy to work on that.
>
> Have you turned on debug logging? Invoke the tool with
> SYSTEMD_LOG_LEVEL=debug env var set. Paste the output on some
> pastebin.
>
>> This communication is confidential. If you are not the intended
>> recipient, any use, interference with, disclosure or copying of this
>> material is unauthorised and prohibited. Please inform us
>> immediately and destroy the email.
>
> Sorry, but maybe you should not write to public mailing list if things
> are that confidential. And these mailing lists are archived publicly
> and indexed by google.
>
> Please stop putting such threatening text in your mails if you post on
> a public forum asking people for help. Thank you.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>



Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach, Martin Stamm

This communication is confidential. If you are not the intended recipient, any 
use, interference with, disclosure or copying of this material is unauthorised 
and prohibited. Please inform us immediately and destroy the email.

Re: [systemd-devel] FW: Requesting commercial support if applicable for systemd-cryptenroll --pkcs11-token-uri

[Lennart Poettering]

gOn Do, 19.01.23 12:45, Yogesh Tokas (yogesh.to...@utimaco.com) wrote:

> systemd-cryptenroll 
> --pkcs11-token-uri="pkcs11:model=CryptoServer;manufacturer=Utimaco%20IS%20GmbH;serial=SI003001_;token=LUKS;id=%45;object=LUKSCert;type=cert"
>  /dev/sdc1
>
> This command gives us no clue, our logs and systemd logs won't show
> anything promising to debug further. Since, pkcs11-token is one of
> the options supported by systemd I am sure it is possible to
> integrate, however, there might be some changes required in our p11
> library. We are looking for some guidance and if this requires us to
> agree on some cost, I am happy to work on that.

Have you turned on debug logging? Invoke the tool with
SYSTEMD_LOG_LEVEL=debug env var set. Paste the output on some
pastebin.

> This communication is confidential. If you are not the intended
> recipient, any use, interference with, disclosure or copying of this
> material is unauthorised and prohibited. Please inform us
> immediately and destroy the email.

Sorry, but maybe you should not write to public mailing list if things
are that confidential. And these mailing lists are archived publicly
and indexed by google.

Please stop putting such threatening text in your mails if you post on
a public forum asking people for help. Thank you.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error

[Barry]

> On 19 Jan 2023, at 19:19, Roberts, William C  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: Roberts, William C
>> Sent: Thursday, January 19, 2023 10:45 AM
>> To: Lennart Poettering 
>> Cc: systemd-devel@lists.freedesktop.org
>> Subject: RE: [systemd-devel] mkosi Unable to locate embedded .linux section:
>> Load Error
>> 
>> 
>> 
>>> -Original Message-
>>> From: Lennart Poettering 
>>> Sent: Thursday, January 19, 2023 3:30 AM
>>> To: Roberts, William C 
>>> Cc: systemd-devel@lists.freedesktop.org
>>> Subject: Re: [systemd-devel] mkosi Unable to locate embedded .linux section:
>>> Load Error
>>> 
>>> On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com)
>> wrote:
>>> 
 I am on current main branch:
 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't
 install pcrphase-related units without gnu-efi
 
 And I cannot get the mkosi qemu to work, mkosi boot does work. It
 looks like it's not finding the relevant section to boot from the image:
 Unable to locate embedded .linux section: Load Error Failed to
 execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish))
 (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error
>>> 
>>> (Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and
>>> there was a chance this would result in overlapping PE sections which
>>> might be the issue here. but that's just a guess. please try current
>>> mkosi git, and see if that works)
>>> 
>>> (I guess most mkosi upstreams use fedora, not ubuntu, so this might be
>>> less
>>> tested)
>> 
>> On mkosi commit 6332528, it used bootctl --root which seems to not be
>> available On my Ubuntu 20.04 system (bootctl --version yields system 245) .
>> I'll set up a Fedora machine and test there.
> 
> Could anyone recommend a version of Fedora to test on, Ie should I pick 32, 
> 34, 37, etc?

Use 37 its current and you can get  support.
Note fedora release only have support for a year, so 32 and 34 have been EOL 
for a while.

Barry

> 

Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error

[Roberts, William C]

> -Original Message-
> From: Roberts, William C
> Sent: Thursday, January 19, 2023 10:45 AM
> To: Lennart Poettering 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: RE: [systemd-devel] mkosi Unable to locate embedded .linux section:
> Load Error
> 
> 
> 
> > -Original Message-
> > From: Lennart Poettering 
> > Sent: Thursday, January 19, 2023 3:30 AM
> > To: Roberts, William C 
> > Cc: systemd-devel@lists.freedesktop.org
> > Subject: Re: [systemd-devel] mkosi Unable to locate embedded .linux section:
> > Load Error
> >
> > On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com)
> wrote:
> >
> > > I am on current main branch:
> > > 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't
> > > install pcrphase-related units without gnu-efi
> > >
> > > And I cannot get the mkosi qemu to work, mkosi boot does work. It
> > > looks like it's not finding the relevant section to boot from the image:
> > > Unable to locate embedded .linux section: Load Error Failed to
> > > execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish))
> > > (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error
> >
> > (Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and
> > there was a chance this would result in overlapping PE sections which
> > might be the issue here. but that's just a guess. please try current
> > mkosi git, and see if that works)
> >
> > (I guess most mkosi upstreams use fedora, not ubuntu, so this might be
> > less
> > tested)
> 
> On mkosi commit 6332528, it used bootctl --root which seems to not be
> available On my Ubuntu 20.04 system (bootctl --version yields system 245) .
> I'll set up a Fedora machine and test there.

Could anyone recommend a version of Fedora to test on, Ie should I pick 32, 34, 
37, etc?

Re: [systemd-devel] networkd: Link local static IP address behind NAT

[Andrei Borzenkov]

On 18.01.2023 17:12, Thomas Burghout wrote:

On 18.01.20233 04:06, Andrei Borzenkov wrote:

On 17.01.2023 18:28, Thomas Burghout wrote:

  inet 169.254.146.171/16 brd 169.254.255.255 scope link eth0


Is it output from the correct system? Because address is different. I do
not see how "ping -I 169.254.1.2" can work with this.


That is unfortunate, I copied the wrong notes indeed. Apologies. The
following output should completely describe the configuration of the
system:


$ cat /usr/lib/systemd/network/10-lan.network
[Match]
Name=eth0

[Network]
Address=169.254.1.2/16
DNS=169.254.1.1
Gateway=169.254.1.1
$ ip route
default via 169.254.1.1 dev eth0
169.254.0.0/16 dev eth0 scope link  src 169.254.1.2
$ ip address
1: lo:  mtu 65536 qdisc noqueue qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq qlen 1000
 link/ether e2:26:9e:11:ae:da brd ff:ff:ff:ff:ff:ff
 inet 169.254.1.2/16 brd 169.254.255.255 scope link eth0
valid_lft forever preferred_lft forever
 inet6 fe80::e026:9eff:fe11:aeda/64 scope link
valid_lft forever preferred_lft forever
3: usb0:  mtu 1500 qdisc noop qlen 1000
 link/ether b6:c8:ab:ac:44:7f brd ff:ff:ff:ff:ff:ff
4: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
 link/sit 0.0.0.0 brd 0.0.0.0
$ ip route get 8.8.8.8
8.8.8.8 via 169.254.1.1 dev eth0
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
$ ping -I 169.254.1.2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 169.254.1.2: 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=12.576 ms
64 bytes from 8.8.8.8: seq=1 ttl=116 time=8.341 ms
64 bytes from 8.8.8.8: seq=2 ttl=116 time=9.124 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 8.341/10.013/12.576 ms


The commands I included for "interactive" were also wrong. The
following commands produce a working configuration:


ip address flush dev eth0
ip route flush dev eth0
ip address add 169.254.1.2/16 brd + dev eth0


This adds address with global scope.


ip route add 169.254.1.1 dev eth0
ip route add default via 169.254.1.1 dev eth0


Most notably, ip route now includes the following line as well:
169.254.1.1 dev eth0 scope link



This is red herring. What happens - kernel needs to set source address 
when you did not specify any. Because route to 8.8.8.8 has global scope 
and the only available address has link scope, this address is ignored 
and so no packet can be sent.


When you explicitly set source address with -I option kernel simply is 
using it.


If you do

ip address add 169.254.1.2/16 brd + dev eth0 scope link

you will observe exactly the same behavior.


Adding an extra [Route] section with this address does not fix the
networkd configuration file.


Of course not. But using

[Address]
Address=169.254.1.2/16
Scope=global

does, although I am not sure about possible implications.

Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error

[Roberts, William C]

> -Original Message-
> From: Lennart Poettering 
> Sent: Thursday, January 19, 2023 3:30 AM
> To: Roberts, William C 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] mkosi Unable to locate embedded .linux section:
> Load Error
> 
> On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com) wrote:
> 
> > I am on current main branch:
> > 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't
> > install pcrphase-related units without gnu-efi
> >
> > And I cannot get the mkosi qemu to work, mkosi boot does work. It
> > looks like it's not finding the relevant section to boot from the image:
> > Unable to locate embedded .linux section: Load Error Failed to execute
> > Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish))
> > (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error
> 
> (Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and there 
> was a
> chance this would result in overlapping PE sections which might be the issue
> here. but that's just a guess. please try current mkosi git, and see if that 
> works)
> 
> (I guess most mkosi upstreams use fedora, not ubuntu, so this might be less
> tested)

On mkosi commit 6332528, it used bootctl --root which seems to not be available
On my Ubuntu 20.04 system (bootctl --version yields system 245) .
I'll set up a Fedora machine and test there.

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Re: [systemd-devel] systemd-stable and Debian's systemd release strategy

[Simon McVittie]

On Wed, 18 Jan 2023 at 16:57:05 +0100, Michael Biebl wrote:
> backports: mostly me lacking time

Also, a note for those who might be less familiar with Debian: the
backports policy is that Debian 11 backports (bullseye-backports)
should always be in sync with the version that would be in Debian 12
(bookworm) if we released Debian 12 today, and similar for other pairs
of Debian versions. We don't backport different upstream versions unless
there are exceptional circumstances.

If Debian 12 was released today, it would contain systemd 252.4-1,
therefore when someone has time to update bullseye-backports, the only
correct thing to update it with would be a backport of that version, as
252.4-1~bpo11+1 (or a backport of whatever newer version has gone into
bookworm by then, if any). There will not be any more 251.x versions
in Debian now that we have picked up 252.x.

The only versions that get special treatment (and will either pick up
releases from systemd-stable or backported bug fixes, depending what
the maintainers are able to justify to the release managers) are the
versions that were current at the time of each Debian stable release
freeze, meaning 247.x for Debian 11, and most likely 252.x for Debian 12.

smcv
(not a Debian systemd maintainer, but I do maintain other packages
that get updated in stable releases)

Re: [systemd-devel] networkd: Link local static IP address behind NAT

[Mike Gilbert]

On Wed, Jan 18, 2023 at 9:12 AM Thomas Burghout
 wrote:
>
> On 18.01.20233 04:06, Andrei Borzenkov wrote:
> > On 17.01.2023 18:28, Thomas Burghout wrote:
> > >  inet 169.254.146.171/16 brd 169.254.255.255 scope link eth0
> >
> > Is it output from the correct system? Because address is different. I do
> > not see how "ping -I 169.254.1.2" can work with this.
>
> That is unfortunate, I copied the wrong notes indeed. Apologies. The
> following output should completely describe the configuration of the
> system:
>
>
> $ cat /usr/lib/systemd/network/10-lan.network
> [Match]
> Name=eth0
>
> [Network]
> Address=169.254.1.2/16
> DNS=169.254.1.1
> Gateway=169.254.1.1

Maybe move Address=169.254.1.2/16 to an Address section with
Scope=global. For example:

[Address]
Address=169.254.1.2/16
Scope=global

[systemd-devel] FW: Requesting commercial support if applicable for systemd-cryptenroll --pkcs11-token-uri

[Yogesh Tokas]

Hello Experts,

I am Yogesh Kumar Tokas, Product Manager at Utimaco. Utimaco is leading the 
data protection market through a vast and integrated portfolio. One such 
product family is our "Hardware Security Modules". I am contacting you 
regarding our GP HSM offering which we are trying to integrate using 
systemd-cryptenroll to perform complete disk encryption on Linux.

After following the sequence of steps, we come to the following command.

systemd-cryptenroll 
--pkcs11-token-uri="pkcs11:model=CryptoServer;manufacturer=Utimaco%20IS%20GmbH;serial=SI003001_;token=LUKS;id=%45;object=LUKSCert;type=cert"
 /dev/sdc1

This command gives us no clue, our logs and systemd logs won't show anything 
promising to debug further. Since, pkcs11-token is one of the options supported 
by systemd I am sure it is possible to integrate, however, there might be some 
changes required in our p11 library. We are looking for some guidance and if 
this requires us to agree on some cost, I am happy to work on that.

It will be helpful if we can organize a call to understand the issue better. 
Please let me know if that's possible.

We look forward to hearing from you. Thanks a lot in advance!!

BR,

Yogesh Kumar Tokas
Product Management - Ecosystem Integration
Utimaco IS GmbH
Email: yogesh.to...@utimaco.com
Mob.: +49 173 2807995

[cid:image001.jpg@01D92C09.50C62130]

Visit Utimaco.com and our YouTube 
channel

Try our free HSM Simulator




Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen - Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach, Martin Stamm

This communication is confidential. If you are not the intended recipient, any 
use, interference with, disclosure or copying of this material is unauthorised 
and prohibited. Please inform us immediately and destroy the email.

[systemd-devel] Schizophrenic systemd-resolved

[Sietse van Zanen]

What should be used for DNS? DECNET or Token ring maybe?

Jan 19 10:50:23  systemd-resolved[977]: Using degraded feature set UDP instead 
of TCP for DNS server ::c0:f7ff:fe31:b205.
Jan 19 10:52:21  systemd-resolved[977]: Using degraded feature set TCP instead 
of UDP for DNS server ::c0:f7ff:fe31:b205

-Sietse

Re: [systemd-devel] systemd-stable and Debian's systemd release strategy

[tok]

Michael, thank you for taking the time to explain, this is helpful and 
puts things into perspective!


Appreciate the effort of all maintainers.

Regards, tok


On 18.01.23 16:57, Michael Biebl wrote:

Quite simple:
stable releases: Debian policy is rather strict regarding stable
uploads and some of the changes that landed in systemd-stable are not
really considered suitable for a stable upload to Debian. That's why
we only cherry-pick select fixes.
If the Debian policy was more lax in that regard, uploading
system-stable releases would be an option (and initially I had planned
to do that, but backed away seeing that the diff between 247.3 and
237.13 was rather large)

backports: mostly me lacking time. I didn't get around to do a bpo
upload of v252. One significant issue was the split of
systemd-resolved into a separate package. We discussed that internally
if it would be too disruptive for a bpo upload or not and whether this
should be rolled back for a bpo upload, which would mean additional
work.
We mostly agreed after internal discussion to upload the changes as-is
to bpo and I've been looking into this recently but ran into issues
with autopkgtest failing for v252 which needs further investigation.
Some of the issues I could fix, some might need more work.

Am Mi., 18. Jan. 2023 um 10:52 Uhr schrieb tok :


Apologies, was not subscribed previously but would also seek the input
of systemd-devel on the matter below.

Regards, tok


On 18.01.23 10:05, tok wrote:

Hi,

This is not meant as blame but I sincerely would like to understand the 
mechanisms/approach and apparent complexities behind it: I was wondering if 
anyone could shed some light on Debian's strategy of releasing systemd packages?

Commendably, the systemd project maintains a dedicated repository 
(systemd-stable) for stable branches with backported patches available to all 
distros, but apparently the Debian project is not leveraging this to its 
advantage:

Current version in Debian stable:
247.3-7+deb11u1 (March 2022)
Latest version of this major release in systemd-stable:
247.13 (Dec 2022, 10 minor versions ahead)

Current version in Debian backports:
251.3-1~bpo11+1 (Aug 2022)
Latest version of this major release in systemd-stable:
251.10 (Dec 2022, 7 minor versions ahead)


What is the reason for this gap? I understand package maintaining is a 
challenging task, especially for something complex like systemd. But would the 
systemd-stable repo not provide already a lot of groundwork (as in: backporting 
bugfixes) for this, to reduce the effort?

Thanks for insights, regards,
tok

Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error

[Lennart Poettering]

On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com) wrote:

> I am on current main branch:
> 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't install 
> pcrphase-related units without gnu-efi
>
> And I cannot get the mkosi qemu to work, mkosi boot does work. It looks like 
> it's not finding the relevant section to boot
> from the image:
> Unable to locate embedded .linux section: Load Error
> Failed to execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish)) 
> (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error

(Note, older mkosi didn#t use the "ukify" infra to generate UKIs, and
there was a chance this would result in overlapping PE sections which
might be the issue here. but that's just a guess. please try current
mkosi git, and see if that works)

(I guess most mkosi upstreams use fedora, not ubuntu, so this might
be less tested)

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] mkosi Unable to locate embedded .linux section: Load Error

[Lennart Poettering]

On Di, 17.01.23 20:09, Roberts, William C (william.c.robe...@intel.com) wrote:

> I am on current main branch:
> 0eb635ef4bc1 (HEAD -> main, origin/main, origin/HEAD) units: don't install 
> pcrphase-related units without gnu-efi
>
> And I cannot get the mkosi qemu to work, mkosi boot does work. It looks like 
> it's not finding the relevant section to boot
> from the image:
> Unable to locate embedded .linux section: Load Error
> Failed to execute Ubuntu 22.04 LTS (22.04 (Jammy Jellyfish))
> (\EFI\Linux\mkosi-ubuntu-5.15.0-58-generic.efi): Load Error

Hmm "Load Error" in qemu ovmf? that's weird. this should just work.

Is this the latest mkosi from git? It's a fairly quickly moving
project. Any chance you can test that?

Lennart

--
Lennart Poettering, Berlin