SecureSockets Bounty

Hmm. version.h says that there is a function mbedtls_version_get_string() but there’s no entry point in libmbedtls/a to implement it, so I get an undefined reference. Similarly mbedtls_entropy_init() has no entry point. But there is an entry point for mbedtls_net_init(), which is satisfied, so I appear to be compiling and linking it correctly.

Sorry, need help again!

Thanks again to Theo, I’m further on now.

If only I could understand how to write makefiles…

Turns out I had failed to package some of the mbedtls libraries, now added to the build.

On the subject of writing makefiles, Tony Houghton’s old guide isn’t terrible. The only caveat being it’s aimed at Norcroft, which has decidedly non-standard flags if you plan to use it with another compiler (eg gcc).

Some other examples from other platforms are worth a look too. These mostly avoid GNU make-isms and Linux-isms, though it’s possible you’ll bump into the rough edges of the RISC OS environment, in particular dot and slash translation.

isn’t terrible.

For our French listeners, this means “not too bad”, not “impossibly bad”!

Pas “pas terrible!”.

Hmm. mbedtls_net_connect() seems to cause a segfault when given a valid address and port. Somewhat less encouraging than I had expected :-(

I’m working from a tutorial example at https://tls.mbed.org/kb/how-to/mbedtls-tutorial

I take it I should be able to run an ELF binary just by double-clicking it? The Next slot is set at 16000K on my BBxM.

And do I need to give gcc any flags to cause it to generate binary suitable for the BBxM’s CPU? I’m not giving it any, therefore using its default for CPU type. gcc is a version I downloaded not many weeks ago from riscos.info, and I simply deleted the previous installation before installing this one.

You can run an ELF binary by double clicking, assuming !SharedLibs is avaiable. Though it may be worth running it at the command line – it may give a backtrace, which would be instructive (you may need to compile with debug symbols to get function names).

Can you build your example code for mbedtls under Linux, to confirm it is working as expected?

I’m not clear on the state of GCC’s default flags, but I’d have thought it should output ARMv7 safe code so I wouldn’t expect that to be a problem.

I’m working from a tutorial example

It’s all a bit deep for me, I built the first example for a simple http request (no mbedtls involved) and it wouldn’t connect to localhost as a server, so I put in “riscos.info” and got the Embedded Linux Solutions page. (-:
But back to your problem, I have seen some ports crash initially just because $HOME was not set. Maybe you could check for env variables it is expecting to find.

so I put in “riscos.info” and got the Embedded Linux Solutions page. (-:

For virtual hosting, you need to specify the host in the request, like…

GET / HTTP/1.0
Host: riscos.fr

Many experiments later… I don’t get consistent results. Running UnixHome doesn’t appear to make any difference. The nearest I had to consistent behaviour is that when NetSurf was running, or when ResRec (yes, a very old app) is running, it would segfault – but, just to confound me, her I am typing this in NetSurf and I try again, and it runs.

I’ve initialised the variables following the method in the tutorial app, so I can’t see that I have any uninitialised variables.

So I’m lost, and somewhat disheartened.

Theo: I’d like to try cross-compiling under Linux, if that’s what you mean, but I haven’t had the courage to attempt to set up a cross-compilation system. I used to have the NetSurf one until the HDD died. Maybe if I can put together the courage and the energy (we’re decorating as fast as we can at the mo).

I am typing this in NetSurf and I try again, and it runs.

I think the lack of $HOME crashed that port everytime. It would probably take a (bad) routine that expects something and doesn’t check for it, and provide a default.
Theo possibly means move your source to linux to build a linux version.
Edit: should work unless asm has specified. I’ve found optimisation can behave differently, but gcc lets you know.
The source I downloaded looks like it could be manually configured for a native
RISC OS build, Keypoints would be deciding to build a shared lib or a static lib,
I dont think we can do both in one run, due to shared requiring the CFLAG -fPIC.
Building static everything would have least things to do. (-static)
I dont think we can do gcc -g3 but it just gets ignored I think.

Edit: I set up the libmbedtls (from debian sid) in the autobuilder, but found that thereis none of the usual autoconf stuff.
The config.h is reconfigured in a choice of three ways byy Perl, so it is something that can be done in Native RISC OS anyway.
The main advantage with the cross-compiler is the speed, but Native can compile and run tests so would be more complete.
Perl is also used to generate test files before compiling.

Something that I haven’t used before, It is possible to set system variables for GNUmake like

*set CC "gcc -static"

They have gone to a lot of trouble to keep it portable as possible, even to the point of only using the most basic Makefile functions.

I have a good explanation (in my code) for why it would behave inconsistently, due to a misunderstanding of the tutorial example. I need to run it lots more times to see whether that explains everything.

Has anyone looked at the mbedTLS source to see if it can be made into a shared library? Theo wrote up a good explanation for why libssl (I think) couldn’t be, which boils down to its use of lots of global variables. I think it needs all variables to be in contexts that are unique to one connection. Perhaps gcc can list globals when it builds the libraries; I don’t know.

Ultimately, if it can be made into a relocatable module, that would give us the most flexibility. AFAICS it’s pretty much the only reasonable way to use it from BASIC, for example.

Dave, if you can download mbedtls_2.7.0.orig.tar.gz from debian sources, and I will send you the the tests folder, It took some time to modify the names like test_suite_aes.cfb.c so it would all work with the suffix version of GCC in Native RISC OS land.
Lee Noar would be good at judging if there is a problem with a shared version, The source looks as clean as you will get for the possibility of module building.
Edit: have sent the tests.zip to your me.uk address

Global variables

/* For dlopen () */
#define RTLD_LAZY 1
#define RTLD_NOW 2
#define RTLD_GLOBAL 0×100

It is not clear wether you can configure it otherwise though.

There is a mention of some sort of localness in the SharedLibs ReadMe
The environment of the dynamic loader can be set on a per client basis by
setting a RISC OS system variable with a name based on that of the executable:

<program name>$LD$Env

Has anyone looked at the mbedTLS source to see if it can be made into a shared library?

I have built the mentioned source (configured by perl with baremetal) and the tests run when the build is done static, but every test crashes (near identically) when doing the shared libraries version. I have tested the libraries with objdump and readelf and they are clean of TEXTREL. modifying the selftest program by positioning ‘return 0;’ I can tell it crashes at the first use of a function in main(), so the backtrace only shows main(). The first function is memset(). Dont know what the problem is yet, The GCC examples built ok as shared.
Edit: The libraries were built correctly, The problem was I was building the executables with -fPIC. The system variable for CFLAGS was still around. Removing the .Silent variable from the makefiles is worthwhile so you get the actual gcc string displayed. Back to setting CC CFLAGS and LDFLAGS in the makefiles for me! The one system variable I /could/ use across the board and make doesn’t look for it, is the SHELL variable. there is one or two bash command lines that dash can handle if it is the shell.

My learning curve is a bit further advanced. I’ve just managed to send a GET to a web site using the mbedTLS library.

Whether this will do anyone any good, is another matter, of course.