Error: LD: symbol not found: '__data_start'

[Norman Feske]

Hello Alexander,

> in short, if I set it inside my target.mk file to bulid application, like this:
> TARGET = test-go
> SRC_GO = main.go
> 
> LIBS = base libc libm libatomic libbacktrace libffi libgo libgo_support stdcxx
> 
> LD_SCRIPT_DYN = $(PRG_DIR)/my_genode_dyn.ld
> 
> CC_CXX_WARN_STRICT =
> 
> then it completely ignored, because prg.mk which do include target.mk in the very beginning, 
> and later include global.mk which contain the following (which override it):
> #
> # Linker script for dynamically linked programs
> #
> LD_SCRIPT_DYN = $(BASE_DIR)/src/ld/genode_dyn.ld

I'm very sorry that I overlooked that hard assignment. In commit [1] (on
the staging branch), I changed it to a ?= assignment to make the
variable customizable. Can you give it a try?

[1]
https://github.com/genodelabs/genode/commit/5429c11ca8ad87465ebb017165764e7767e0a338

> And, I am not completely agree with your argument about modification of standard ld script.
> I understand your general approach of minimisation of changes and related support.
> Anyway, in short,
> - this modification is a part of standard gcc code/binutils, not related to golang (it just use it)
> - it does not take any resources like memory (just compilation alias)
> - it does not require any support afterward
> - it does not violate any security/etc approaches of genode and lower level OSes

Global symbols of any kind are highly discouraged throughout Genode (see
[2]) because they invite global side effects, which defeat the
assessment of the correctness of programs. Symbol aliases are worse
because they make the tracing of global side effects even more obscure.
However hard I try, I cannot think of any legitimate use of a symbol
that aliases the parent_cap symbol (at the beginning of the data
segment). I can only think of illegitimate uses and the added risk of
unintended information leakage.

[2]
https://genodians.org/nfeske/2019-01-22-conscious-c++#Banning_hidden_state_and_hidden_side_effects

In fact, when I look at our linker script, I have the strong urge to
*remove* several dubious symbols that stick out like sore thumbs. Adding
more global symbols goes frontal against our grain.

The "part of standard" does not apply. The principles behind Genode are
not at all aligned with what is commonly referred to as standard
(POSIX). Mistakes should not be repeated, whether they are standard or not.

> - if I move complete ld script for golang to world (may be I can just
> define only necessary name in add-on script?), then it will be
> necessary to support it (if main genode ld script will somehow
> evolve…).
The burden of maintenance and responsibility always rests on someone's
shoulders. When you ask us for adding global symbols to the default
linker script on behalf of your single use case, you are actually asking
us to take over responsibility and the commitment to carry forward (not
break) this "feature" in the future. This may make your life more
convenient while shifting the burden to us. In the worst case - should
the feature turn out as a security disaster sometime later - we'd be
responsible, not you. If a third party (e.g., for security evaluation)
asks us for an explanation behind the content of the linker script, we
must be able to give clear answers. Each addition is a liability. Hence,
we are not eager to accept additional weight on our shoulders whenever
we can avoid it.

In contrast, if you keep the customization of the linker script local to
your program, Genode at large stays clear of any consequences.

Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth