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.