Error: hammer ABI contains Genode-internal symbol '__bss_start'

[Guido Witmond]

On 01/10/19 11:21, Christian Helmuth wrote:

 > The abi_symbols tool is just a handy utility to generate a list of
 > potential ABI symbols, which must be manually amended/checked.

The release notes for 17.02 mentioned a manual process but did not offer 
any insight in what needs to be done.

> On Thu, Jan 10, 2019 at 11:04:49AM +0100, Norman Feske wrote:
>> I wonder, should we consider adding a black list of known Genode symbols
>> to the abi_symbols tool? This would make the tool a bit more convenient.

Since both tools go together, I think it would help a lot to filter out 
the 'forbidden' symbols in abi_symbols. I see two benefits:
1: it saves mental effort and menial labour that could be automated;
2: it prevents questions like mine :-)

>> On the other hand, it may foster the (wrong) expectation that the output
>> of the tool *is* an ABI as is. 

Now, that's good to write in the documentation.

>> In practice, the manual curing step is important.
>> E.g., symbols of library-internal interfaces should be
>> removed. This step needs a human brain.

This consideration was left out too. And the 'e.g.' suggests there are 
other considerations too. Now I'm curious to those.

 > Therefore, the human-brain intervention during the ABI
 > creation should be at least emphasized if not enforced.

Please don't enforce, I have another consideration:

As application programmer, I look up the API in the documentation, 
examples, header files and source files (in that order). If I would call 
internal interfaces, I risk breakage when the library gets updated.

Give that, the ABI file does not seem to provide much intellectual value 
to me, I see it as a way to speed up compilation.

What is the effect on security when I leave internal symbols in the ABI? 
Would a process - that is linked to my library - be severely easier to 
subvert by an attacker who exploits a buffer overflow?

If not, I propose to filter the blacklist in abi_symbols (and check in 
check_abi) and call that the 'official' ABI. It may not be the cleanest 
approach but it saves mental effort (== time and money) in porting 
libraries. Please make it easy for programmers, not harder.

If it has not been build, I'll add the blacklist filter to abi_symbols 
and submit a merge request for it.

>> Given Guido's question, we should definitely enhance the documentation
>> about using the abi_symbols tool. Since Guido referred to the porting
>> guide, would that document be a suitable place?

I think a document to complement the porting guide would make sense.

> You're right, adding extended documentation of the tool usage to the
> guide supports the goal mentioned above, but currently I'm somewhat
> occupied by other labors to improve the documentation myself. Maybe
> Guido could contribute some words based on his practical experiences?

If I get my depot package to work I'll blog about it, especially if the 
documentation is not there yet. Now that you have Genodians, it saves me 
the hassle to setup something myself. :-)

PS. About genodians.org. To make it easy, I'd put it behind a Caddy 
webserver proxy (running on linux). Caddy provides automatic Let's 
Encrypt certificates.

Cheers, Guido.