[PATCH] Build libebgenv.so shared library

[Christian Storm]

From: Christian Storm <christi...@siemens.com>

Adapt the build system to build a shared library
libebgenv-${EBG_VERSION}.so symlinked to by a
libebgenv.so in addition to the static libebgenv.a.

This shared library may be used by external software
such as SWUpdate [1] wanting to modify EFI Boot Guard's
environment without having to statically link against
libebgenv.a, following the pattern of libubootenv [2].

Note that the bg_setenv utility deliberately remains
statically linked against libebgenv.a. for easy
inclusion in initramfs or rescue media and to not
break existing deployments. Alike, libebgenv.a is
still installed via make install (though distrbutions
may decide to not package it).
This may be deprecated and removed in future versions.

[1] https://github.com/sbabic/swupdate
[2] https://github.com/sbabic/libubootenv

Signed-off-by: Christian Storm <christi...@siemens.com>
---
.gitignore | 4 ++++
Makefile.am | 9 +++++++++
configure.ac | 3 +++
3 files changed, 16 insertions(+)

diff --git a/.gitignore b/.gitignore
index 6433560..c1f0088 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,6 +23,7 @@
*.so
*.so.*
*.dylib
+*.lai

# EFI
*.efi
@@ -70,6 +71,7 @@ Makefile.in
/config.status
/config.sub
/configure
+/configure~
/configure.scan
/depcomp
/install-sh
@@ -79,3 +81,5 @@ Makefile.in
/tools/tests/Makefile
.deps/
version.h
+m4/
+libtool
diff --git a/Makefile.am b/Makefile.am
index 12dcb19..7c18227 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -92,6 +92,14 @@ libebgenv_a_CFLAGS = \
pkginclude_HEADERS = \
include/ebgenv.h

+#
+# Shared libraries
+#
+LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)
+lib_LTLIBRARIES = libebgenv.la
+libebgenv_la_SOURCES = $(libebgenv_a_SOURCES)
+libebgenv_la_LDFLAGS = -release $(LIBEBGENV_SO_VERSION).0
+
#
# bg_setenv binary
#
@@ -113,6 +121,7 @@ bg_setenv_DEPENDENCIES = \
install-exec-hook:
$(LN_S) -f bg_setenv$(EXEEXT) \
$(DESTDIR)$(bindir)/bg_printenv$(EXEEXT)
+ $(RM) $(DESTDIR)$(libdir)/$(lib_LTLIBRARIES)

#
# EFI compilation
diff --git a/configure.ac b/configure.ac
index d7a7451..6b46349 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,6 +22,8 @@ AC_INIT([efibootguard],
[efibootguard],
[])

+LT_INIT
+
AC_CONFIG_SRCDIR([bootguard.c])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])
@@ -47,6 +49,7 @@ AC_PROG_GCC_TRADITIONAL
AC_PROG_MKDIR_P
AC_PROG_RANLIB
AC_PROG_LN_S
+AC_PROG_EGREP

AC_ARG_WITH([gnuefi-sys-dir],
AS_HELP_STRING([--with-gnuefi-sys-dir=DIRECTORY],
--
2.33.0

[Christian Storm]

Hi Jan,

> Adapt the build system to build a shared library
> libebgenv-${EBG_VERSION}.so symlinked to by a
> libebgenv.so in addition to the static libebgenv.a.
>
> This shared library may be used by external software
> such as SWUpdate [1] wanting to modify EFI Boot Guard's
> environment without having to statically link against
> libebgenv.a, following the pattern of libubootenv [2].
>
> Note that the bg_setenv utility deliberately remains
> statically linked against libebgenv.a. for easy
> inclusion in initramfs or rescue media and to not
> break existing deployments. Alike, libebgenv.a is
> still installed via make install (though distrbutions
> may decide to not package it).
> This may be deprecated and removed in future versions.
>
> [1] https://github.com/sbabic/swupdate
> [2] https://github.com/sbabic/libubootenv
>
> Signed-off-by: Christian Storm <christi...@siemens.com>

Any thoughts on this one? In particular regarding the (remaining)
static linking and deprecation of libebgenv.a?


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Jan Kiszka]

On 23.08.21 16:57, Christian Storm wrote:
> From: Christian Storm <christi...@siemens.com>
>
> Adapt the build system to build a shared library
> libebgenv-${EBG_VERSION}.so symlinked to by a
> libebgenv.so in addition to the static libebgenv.a.
>
> This shared library may be used by external software
> such as SWUpdate [1] wanting to modify EFI Boot Guard's
> environment without having to statically link against
> libebgenv.a, following the pattern of libubootenv [2].
>
> Note that the bg_setenv utility deliberately remains
> statically linked against libebgenv.a. for easy
> inclusion in initramfs or rescue media and to not
> break existing deployments. Alike, libebgenv.a is
> still installed via make install (though distrbutions

distributions

Why that? We have m4/arch.m4 in git.

> +libtool
> diff --git a/Makefile.am b/Makefile.am
> index 12dcb19..7c18227 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -92,6 +92,14 @@ libebgenv_a_CFLAGS = \
> pkginclude_HEADERS = \
> include/ebgenv.h
>
> +#
> +# Shared libraries
> +#
> +LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)

Do we want to couple the lib version that tightly to the releases?

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[Christian Storm]

Hi Jan,

> > Adapt the build system to build a shared library
> > libebgenv-${EBG_VERSION}.so symlinked to by a
> > libebgenv.so in addition to the static libebgenv.a.
> >
> > This shared library may be used by external software
> > such as SWUpdate [1] wanting to modify EFI Boot Guard's
> > environment without having to statically link against
> > libebgenv.a, following the pattern of libubootenv [2].
> >
> > Note that the bg_setenv utility deliberately remains
> > statically linked against libebgenv.a. for easy
> > inclusion in initramfs or rescue media and to not
> > break existing deployments. Alike, libebgenv.a is
> > still installed via make install (though distrbutions
>
> distributions

Fixed locally for V2.

Yes, this was too broad. We additionally get
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4
auto-generated by this change.
I'll exclude them specifically for a V2 as in
m4/libtool.m4
m4/lt*

> > +libtool
> > diff --git a/Makefile.am b/Makefile.am
> > index 12dcb19..7c18227 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -92,6 +92,14 @@ libebgenv_a_CFLAGS = \
> > pkginclude_HEADERS = \
> > include/ebgenv.h
> >
> > +#
> > +# Shared libraries
> > +#
> > +LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)
>
> Do we want to couple the lib version that tightly to the releases?

Well, there's the take on library versioning by autotools
https://www.sourceware.org/autobook/autobook/autobook_61.html
but their semantics seems not to be too widely adopted.

The downside of using the version in the shared library names, quoting
above link:
"[...] and you don't mind forcing your users to relink all of the
applications which use one of your Libtool libraries every time you
make a release, then libtool provides the '-release' flag to encode
the project version number in the name of the library [...]"
is usually handled by distributions that exactly do this: repackage
all dependencies and roll out the update to users ― except for
self-built packages that you have to take care for locally....

Another option would be to bump the version on breaking changes only,
manually, and thus decoupling from the "real" version.

Either way, one has to solve the problem of either relinking dependent
applications on version bumps (and installing the updated EFI bootloader
part) or allowing to have multiple versions of the shared library
installed. In the latter case, one must ensure compatibility to the EFI
bootloader part also touching BGENV.DAT so not to use an outdated shared
library to access it.


So... what are we going to do? :)

[Jan Kiszka]

The compatibility to bgenv.dat revisions is the task of the lib, in the
future, see the other thread.

But it's likely safer to avoid the manual version bump, thus forgetting
an update when changing the lib APIs.

[Christian Storm]

Hi Jan,

> [...]

> >>> +#
> >>> +# Shared libraries
> >>> +#
> >>> +LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)
> >>
> >> Do we want to couple the lib version that tightly to the releases?
> >
> > Well, there's the take on library versioning by autotools

> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sourceware.org%2Fautobook%2Fautobook%2Fautobook_61.html&amp;data=04%7C01%7Cf12e6810-e622-4957-a0c8-c67ff4e321b6%40ad011.siemens.com%7C08351ec4ecb04268282c08d967b695f3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654856164997542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hdRsokE7Iaz80fAejGQ96EXjbvi8Rj7srjfHbsHj67w%3D&amp;reserved=0

> > but their semantics seems not to be too widely adopted.
> >
> > The downside of using the version in the shared library names, quoting
> > above link:
> > "[...] and you don't mind forcing your users to relink all of the
> > applications which use one of your Libtool libraries every time you
> > make a release, then libtool provides the '-release' flag to encode
> > the project version number in the name of the library [...]"
> > is usually handled by distributions that exactly do this: repackage
> > all dependencies and roll out the update to users ― except for
> > self-built packages that you have to take care for locally....
> >
> > Another option would be to bump the version on breaking changes only,
> > manually, and thus decoupling from the "real" version.
> >
> > Either way, one has to solve the problem of either relinking dependent
> > applications on version bumps (and installing the updated EFI bootloader
> > part) or allowing to have multiple versions of the shared library
> > installed. In the latter case, one must ensure compatibility to the EFI
> > bootloader part also touching BGENV.DAT so not to use an outdated shared
> > library to access it.
> >
> >
> > So... what are we going to do? :)
> >
>
> The compatibility to bgenv.dat revisions is the task of the lib, in the
> future, see the other thread.

Exactly. In case of multiple lib versions it doesn't help to use a lib
that refuses to touch EBGENV.DAT because it's outdated, so you have to
update its dependent packages to use the new lib version anyway...

> But it's likely safer to avoid the manual version bump, thus forgetting
> an update when changing the lib APIs.

Agreed. So we keep the tight name-coupling of the shared library to EFI
Boot Guard's version then. I'll send a V2...

[Christian Storm]

From: Christian Storm <christi...@siemens.com>

Adapt the build system to build a shared library
libebgenv-${EBG_VERSION}.so symlinked to by a
libebgenv.so in addition to the static libebgenv.a.

This shared library may be used by external software
such as SWUpdate [1] wanting to modify EFI Boot Guard's
environment without having to statically link against
libebgenv.a, following the pattern of libubootenv [2].

Note that the bg_setenv utility deliberately remains
statically linked against libebgenv.a. for easy
inclusion in initramfs or rescue media and to not
break existing deployments. Alike, libebgenv.a is

still installed via make install (though distributions

may decide to not package it).
This may be deprecated and removed in future versions.

[1] https://github.com/sbabic/swupdate
[2] https://github.com/sbabic/libubootenv

Signed-off-by: Christian Storm <christi...@siemens.com>
---

.gitignore | 5 +++++

Makefile.am | 9 +++++++++
configure.ac | 3 +++

3 files changed, 17 insertions(+)

diff --git a/.gitignore b/.gitignore
index 6433560..c8cb496 100644

--- a/.gitignore
+++ b/.gitignore
@@ -23,6 +23,7 @@
*.so
*.so.*
*.dylib
+*.lai

# EFI
*.efi
@@ -70,6 +71,7 @@ Makefile.in
/config.status
/config.sub
/configure
+/configure~
/configure.scan
/depcomp
/install-sh

@@ -78,4 +80,7 @@ Makefile.in
/Makefile
/tools/tests/Makefile
.deps/
+m4/libtool.m4
+m4/lt*
version.h

+libtool
diff --git a/Makefile.am b/Makefile.am

index ee142d1..9a171fc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -90,6 +90,14 @@ libebgenv_a_CFLAGS = \
pkginclude_HEADERS = \
include/ebgenv.h

+#
+# Shared libraries
+#
+LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)

+lib_LTLIBRARIES = libebgenv.la
+libebgenv_la_SOURCES = $(libebgenv_a_SOURCES)
+libebgenv_la_LDFLAGS = -release $(LIBEBGENV_SO_VERSION).0
+
#
# bg_setenv binary
#

@@ -111,6 +119,7 @@ bg_setenv_DEPENDENCIES = \

install-exec-hook:
$(LN_S) -f bg_setenv$(EXEEXT) \
$(DESTDIR)$(bindir)/bg_printenv$(EXEEXT)
+ $(RM) $(DESTDIR)$(libdir)/$(lib_LTLIBRARIES)

#
# EFI compilation
diff --git a/configure.ac b/configure.ac

index fd75cb8..b332c6a 100644

--- a/configure.ac
+++ b/configure.ac
@@ -22,6 +22,8 @@ AC_INIT([efibootguard],
[efibootguard],
[])

+LT_INIT
+
AC_CONFIG_SRCDIR([bootguard.c])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])

@@ -49,6 +51,7 @@ AC_PROG_GCC_TRADITIONAL

AC_PROG_MKDIR_P
AC_PROG_RANLIB
AC_PROG_LN_S
+AC_PROG_EGREP

AC_ARG_WITH([gnuefi-sys-dir],
AS_HELP_STRING([--with-gnuefi-sys-dir=DIRECTORY],

--
2.33.0

[Jan Kiszka]

libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'

I suspect there is room for cleanup.

Furthermore:

configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
configure: error: cannot find install-sh, install.sh, or shtool in "."
"./.." "./../.."

i.e. configure is now broken.

[Jan Kiszka]

index 9a171fc..f000d73 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -93,7 +93,7 @@ pkginclude_HEADERS = \
#
# Shared libraries
#
-LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)
+LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' $(top_srcdir)/VERSION)
lib_LTLIBRARIES = libebgenv.la
libebgenv_la_SOURCES = $(libebgenv_a_SOURCES)
libebgenv_la_LDFLAGS = -release $(LIBEBGENV_SO_VERSION).0
diff --git a/configure.ac b/configure.ac
index b332c6a..6dcd386 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,14 +22,14 @@ AC_INIT([efibootguard],
[efibootguard],
[])

-LT_INIT
-

AC_CONFIG_SRCDIR([bootguard.c])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])

AC_CONFIG_AUX_DIR([build-aux])
AC_PREFIX_DEFAULT([/usr])

+LT_INIT
+
AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-dist-gzip dist-xz subdir-objects])
AM_SILENT_RULES([yes])

@@ -49,7 +49,6 @@ AM_PROG_CC_C_O
AC_PROG_GCC_TRADITIONAL

AC_PROG_MKDIR_P
-AC_PROG_RANLIB
AC_PROG_LN_S
AC_PROG_EGREP


How were you able to use your patch? Or was this untested? Please
double-check and send v3.

[Christian Storm]

Hi Jan,

I did a clean
git clone https://github.com/siemens/efibootguard.git
cd ./efibootguard
git switch next
<apply patch>
autoreconf -fi && ./configure --prefix=$PWD/dist && make
as documented in [1] and it works, so: No, it's not untested!

[1] https://github.com/siemens/efibootguard/blob/master/docs/COMPILE.md

LT_INIT needs to be after AC_INIT, which it is, and it works, see above.
If this works for you while the original patch doesn't, I put it here,
works for me as well.

> AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-dist-gzip dist-xz subdir-objects])
> AM_SILENT_RULES([yes])
>
> @@ -49,7 +49,6 @@ AM_PROG_CC_C_O
> AC_PROG_GCC_TRADITIONAL
>
> AC_PROG_MKDIR_P
> -AC_PROG_RANLIB
> AC_PROG_LN_S
> AC_PROG_EGREP
>
>
> How were you able to use your patch?

See above.

> Or was this untested?

No, see above.

[Christian Storm]

From: Christian Storm <christi...@siemens.com>

Adapt the build system to build a shared library
libebgenv-${EBG_VERSION}.so symlinked to by a
libebgenv.so in addition to the static libebgenv.a.

This shared library may be used by external software
such as SWUpdate [1] wanting to modify EFI Boot Guard's
environment without having to statically link against
libebgenv.a, following the pattern of libubootenv [2].

Note that the bg_setenv utility deliberately remains
statically linked against libebgenv.a. for easy
inclusion in initramfs or rescue media and to not
break existing deployments. Alike, libebgenv.a is
still installed via make install (though distributions
may decide to not package it).
This may be deprecated and removed in future versions.

[1] https://github.com/sbabic/swupdate
[2] https://github.com/sbabic/libubootenv

Signed-off-by: Christian Storm <christi...@siemens.com>
---
.gitignore | 5 +++++
Makefile.am | 9 +++++++++

configure.ac | 4 +++-
3 files changed, 17 insertions(+), 1 deletion(-)

index ee142d1..f000d73 100644

--- a/Makefile.am
+++ b/Makefile.am
@@ -90,6 +90,14 @@ libebgenv_a_CFLAGS = \
pkginclude_HEADERS = \
include/ebgenv.h

+#
+# Shared libraries
+#

+LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' $(top_srcdir)/VERSION)

+lib_LTLIBRARIES = libebgenv.la
+libebgenv_la_SOURCES = $(libebgenv_a_SOURCES)
+libebgenv_la_LDFLAGS = -release $(LIBEBGENV_SO_VERSION).0
+
#
# bg_setenv binary
#
@@ -111,6 +119,7 @@ bg_setenv_DEPENDENCIES = \
install-exec-hook:
$(LN_S) -f bg_setenv$(EXEEXT) \
$(DESTDIR)$(bindir)/bg_printenv$(EXEEXT)
+ $(RM) $(DESTDIR)$(libdir)/$(lib_LTLIBRARIES)

#
# EFI compilation
diff --git a/configure.ac b/configure.ac

index fd75cb8..6dcd386 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,6 +28,8 @@ AC_CONFIG_HEADERS([config.h])

AC_CONFIG_AUX_DIR([build-aux])
AC_PREFIX_DEFAULT([/usr])

+LT_INIT
+

AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-dist-gzip dist-xz subdir-objects])
AM_SILENT_RULES([yes])

@@ -47,8 +49,8 @@ AM_PROG_CC_C_O
AC_PROG_GCC_TRADITIONAL

AC_PROG_MKDIR_P
-AC_PROG_RANLIB
AC_PROG_LN_S

+AC_PROG_EGREP

AC_ARG_WITH([gnuefi-sys-dir],
AS_HELP_STRING([--with-gnuefi-sys-dir=DIRECTORY],

--
2.33.0

[Jan Kiszka]

LT_INIT needs AC_CONFIG_AUX_DIR to be set in order to find install-sh,
at least for the autoconf version I have here (2.69).

>
>> AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-dist-gzip dist-xz subdir-objects])
>> AM_SILENT_RULES([yes])
>>
>> @@ -49,7 +49,6 @@ AM_PROG_CC_C_O
>> AC_PROG_GCC_TRADITIONAL
>>
>> AC_PROG_MKDIR_P
>> -AC_PROG_RANLIB
>> AC_PROG_LN_S
>> AC_PROG_EGREP
>>
>>
>> How were you able to use your patch?
>
> See above.
>
>> Or was this untested?
>
> No, see above.
>

I suspect it was an autoconf version issue, you having a too recent one.

And then you only tested in-tree builds.

[Jan Kiszka]

Thanks, applied to next.