-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSP and the Solo5 ABI (was Multiple definition error of __stack_chk_fail ...) #335
Comments
Fundamentally, this is a layering issue.
Unless you have a better idea, my only suggestion at this time would be to patch your copy of musl so that it does not define this symbol. |
Could that be checked on the unikernel build side? For example, includeos doesn't allow a user-defined |
No it doesn't. If you land in |
They might have a usecase where they have a cloud server, and you configure it to restart itself when something bad happens however, before that happens, it needs to log something and send a few messages. IncludeOS does that now, because when we panic we can run a few safe lines of code |
The Solo5
I repeat, there is nothing safe you can do if you land in |
The way I understand it this is not a question of IncludeOS vs. Solo5, it's Solo5 vs. a major implementation of libc. We're just trying to link against both libraries. As you're putting it @mato
Is it a goal for Solo5 to provide more of this runtime in the future or is going to be just this one function? This will be important when we decide if it's feasible for us to maintain our own patches to libc to be able to run on solo5. |
For example, one could argue that |
@alfred-bratterud:
That's a good question, thanks for asking. For the benefit of others not necessarily familiar with the details, first I want to step back a bit and explain why What are the Solo5 API and ABI, exactly?To ensure we're on the same page regarding terminology, here are my definitions of these two terms, as seen by a libOS that wants to support Solo5:
Note for completeness: The binary file format of the unikernel (i.e. the artefact resulting from linking Solo5 with a libOS) is generally the same as/based on that used by the Solo5 ABI, with slight target-specific variations (e.g. a multiboot header for virtio, a shared object for Genode vs a static executable for others). What does Stack Smashing Protection have to do with it?SSP modifies the calling convention used by the ABI at the compiler level. In order for the Solo5 ABI as defined above to actually work in the presence of an SSP-enabled compiler, both the libOS (caller) and bindings (callee) have to agree on the calling convention used across the ABI boundary, including the implementation details of SSP (which, as I found out the hard way while implementing #294, are not actually specified anywhere!). This implies that both What about supporting more of the C runtime?To answer your original question, consistent with the goal of Solo5 being as minimalist as possible yet still useful for getting real work done with unikernels, I don't plan on adding any more of the "C runtime" to the Solo5 ABI unless it's absolutely necessary. In an ideal world, Solo5 would not have to provide Why doesn't Solo5 support mmap / malloc?(This is a different topic, but since you asked)
Security always involves some set of tradeoffs. Solo5 aims for portability of unikernels across a large set of different targets, while preserving as much isolation of the unikernel from its host as possible. Not allowing control over the guest's virtual memory space is a conscious design decision, which among other things significantly improves the isolation properties of an spt-targetted unikernel. For example, there have been exploits against the Linux kernel which only need access to If we implement PIE/ASLR at some stage (see #304), then at least the location of the entire memory region provided to the unikernel for use as its "heap stack" will be randomized, which should address some of your concern. |
as further reference on |
I think it's problematic that the solo5 hvt is now directly incompatible with libc; e.g. both musl, glibc and bsd libc (which iirc you're patching post build with an objcopy). I might need some further education as to your reasoning for this; e.g. I see you're mentioning missing standardisation for calling conventions wrt. SSP, but I don't see how linking against solo5 hvt should be different from linking to any other prebuilt library? The usual procedure is to link against libc / libc equivalent for getting e.g. Cheers. |
@alfred-bratterud Sorry, I spent half a day writing the above text, I'm surprised that it's not clear. Quoting the important part:
So, the core issue is:
If you want the details, read up on these references cribbed from #293:
Alternatively, build a copy of Solo5 master and read through As to what can be done about this: I thought of various workarounds like not exporting The only other option that I can see is re-designing the ABI and defining our own, non-standard, calling convention for all the solo5 functions. That might work, and might actually have other interesting advantages, but it's a lot of work to get right across all the supported targets, tenders and CPU architectures. |
When I am trying to run a test on InlcudeOS with solo5, I see the following error
IncludeOS uses
musl
as a C library and the above function is a part of the library. After discussing with IncludeOS as to what could be done to address this, we think the simplest solution is to make solo5's__stack_chk_fail
weak so that musl's definition is prioritised. If you guys are ok with this, I will go ahead and make the changeThe text was updated successfully, but these errors were encountered: