-
Notifications
You must be signed in to change notification settings - Fork 138
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
Fix .bss initialization #551
Conversation
Thanks for your report and pull request. I agree this is should be done (and adapted to hvt/spt at least). @palainp any remarks on this? |
I'm sorry for that issue and I also agree that it should be fixed. With Ocaml 5+ a PT_TLS section is now mandatory in the linker script with lld and I suppose that setting only With Xen the zeroization of Line 42 in 0eb8cb8
Re-reading the elf loader, it seems to add the memsize of every Line 282 in 7d5b70f
I added phdr[ph_i].p_filesz == 0 || because if there is no __thread variable the .tdata section is empty (now it's at least 1 page do it's not needed anymore) and the following lines cause a failure.
|
I tried running |
Could it be possible to load PT_LOAD and PT_TLS in muen? |
I see, thanks for the information.
Yes. I will look into it. The TLS test can probably be made to run without changes to Solo5. |
Since there seems to be agreement, that the fix for the .bss loading is also necessary for the other bindings, I will update this PR with the necessary changes. |
Make .bss part of a PT_LOAD segment again so it is properly initialized to zero.
dadaf7e
to
4e13b07
Compare
Thanks! |
I did not change those linker scripts (and also |
I could get the TLS test to pass with only minor changes on the Muen side. Thanks @palainp for the discussion. |
I'm also in favor of having coherent scripts when it isn't mandatory to put differences. So apply a similar change for the remaining scripts should be better to my opinion. Thank you @Kensan for your time. Do you think we also need to update the elf reader in hvt and spt tenders in the same way you changes muen (whatever you've done)? I'm still a bit puzzled now loading bss but not tbss :) |
My understanding is, that tbss (along with tdata and the tcb) is allocated on the heap for each thread, thus there is no need to have the section processed by the ELF loader. For Muen I had to do minor adjustments to correctly process sections that have a filesize of 0 but a virtual size > 0. Regarding the ELF loader of HVT/SPT tenders: what was the reason that the zero size check was added? Is it still required? Line 249 in b9b2888
|
Yes you're right, blanking Concerning Line 129 in b9b2888
.tdata could be empty and still PT_LOADed, failling one assertion later, but I can't remember where :(
|
* Be able to build `spt`, `virtio`, `muen` and `xen` targets on OpenBSD (@adamsteen, Solo5/solo5#544). This change does not allow us to "run" these targets on OpenBSD * Fix linker scripts with TLS (Thread Local Storage) sections (@palainp, @hannesm, @dinosaure, Solo5/solo5#542) * Export TLS symbols (@palainp, @hannesm, @dinosaure, Solo5/solo5#546) **breaking change** due to Solo5/solo5#542 & Solo5/solo5#546, tenders must be **upgraded**. Indeed, solo5.0.7.* tenders will not be able to load correctly unikernels compiled with solo5.0.8.0. The internal ABI version for `solo5-hvt`/`solo5-spt` was upgraded accordingly. This version implements Thread Local Storage. The user can initialise a TLS block with `solo5_tls_init` on a pointer to `solo5_tls_size()` free bytes. Then, the user is able to set the `tp` (Thread Pointer) pointer via `solo5_set_tls_base(solo5_tls_tp_offset(tls_block))`. More details are available into `solo5.h`. Note: this change does not allow a Solo5 unikernel to use multiple cores! It only provides an API required by OCaml 5 / pthread to launch, at most, one thread. * Fix tests reported by NixOS (@greydot, @ehmry, Solo5/solo5#547) * Split out the `time.c` implementation between Muen and HVT (@dinosaure, @Kensan, Solo5/solo5#552) * User hypercall instead of TSC-based clock when the user asks for the wall-clock (@dinosaure, @reynir, Solo5/solo5#549, Solo5/solo5#550) Note: only hvt & virtio are updated to avoid a clock drift on the wall-clock. Indeed, when the unikernel is suspended, the wall-clock is not updated. Muen & Xen still use a TSC-based wall-clock. The spt target was already in sync with the host's wall-clock. * Improve the muen clock (@Kensan, Solo5/solo5#553) * Fix the `.bss` section according to Solo5/solo5#542 & Solo5/solo5#546. The `.bss` section is tagged with `PT_LOAD`. Tenders are available to load this section properly. (@Kensan, @dinosaure, Solo5/solo5#551, Solo5/solo5#554) * Fix the cross-compilation of Solo5 for `aarch64` (@dinosaure, @palainp, @hannes, Solo5/solo5#555)
(@adamsteen, Solo5/solo5#544). This change does not allow us to "run" these targets on OpenBSD * Fix linker scripts with TLS (Thread Local Storage) sections (@palainp, @hannesm, @dinosaure, Solo5/solo5#542) * Export TLS symbols (@palainp, @hannesm, @dinosaure, Solo5/solo5#546) **breaking change** due to Solo5/solo5#542 & Solo5/solo5#546, tenders must be **upgraded**. Indeed, solo5.0.7.* tenders will not be able to load correctly unikernels compiled with solo5.0.8.0. The internal ABI version for `solo5-hvt`/`solo5-spt` was upgraded accordingly. This version implements Thread Local Storage. The user can initialise a TLS block with `solo5_tls_init` on a pointer to `solo5_tls_size()` free bytes. Then, the user is able to set the `tp` (Thread Pointer) pointer via `solo5_set_tls_base(solo5_tls_tp_offset(tls_block))`. More details are available into `solo5.h`. Note: this change does not allow a Solo5 unikernel to use multiple cores! It only provides an API required by OCaml 5 / pthread to launch, at most, one thread. * Fix tests reported by NixOS (@greydot, @ehmry, Solo5/solo5#547) * Split out the `time.c` implementation between Muen and HVT (@dinosaure, @Kensan, Solo5/solo5#552) * User hypercall instead of TSC-based clock when the user asks for the wall-clock (@dinosaure, @reynir, Solo5/solo5#549, Solo5/solo5#550) Note: only hvt & virtio are updated to avoid a clock drift on the wall-clock. Indeed, when the unikernel is suspended, the wall-clock is not updated. Muen & Xen still use a TSC-based wall-clock. The spt target was already in sync with the host's wall-clock. * Improve the muen clock (@Kensan, Solo5/solo5#553) * Fix the `.bss` section according to Solo5/solo5#542 & Solo5/solo5#546. The `.bss` section is tagged with `PT_LOAD`. Tenders are available to load this section properly. (@Kensan, @dinosaure, Solo5/solo5#551, Solo5/solo5#554) * Fix the cross-compilation of Solo5 for `aarch64` (@dinosaure, @palainp, @hannes, Solo5/solo5#555)
* Be able to build `spt`, `virtio`, `muen` and `xen` targets on OpenBSD (@adamsteen, Solo5/solo5#544). This change does not allow us to "run" these targets on OpenBSD * Fix linker scripts with TLS (Thread Local Storage) sections (@palainp, @hannesm, @dinosaure, Solo5/solo5#542) * Export TLS symbols (@palainp, @hannesm, @dinosaure, Solo5/solo5#546) **breaking change** due to Solo5/solo5#542 & Solo5/solo5#546, tenders must be **upgraded**. Indeed, solo5.0.7.* tenders will not be able to load correctly unikernels compiled with solo5.0.8.0. The internal ABI version for `solo5-hvt`/`solo5-spt` was upgraded accordingly. This version implements Thread Local Storage. The user can initialise a TLS block with `solo5_tls_init` on a pointer to `solo5_tls_size()` free bytes. Then, the user is able to set the `tp` (Thread Pointer) pointer via `solo5_set_tls_base(solo5_tls_tp_offset(tls_block))`. More details are available into `solo5.h`. Note: this change does not allow a Solo5 unikernel to use multiple cores! It only provides an API required by OCaml 5 / pthread to launch, at most, one thread. * Fix tests reported by NixOS (@greydot, @ehmry, Solo5/solo5#547) * Split out the `time.c` implementation between Muen and HVT (@dinosaure, @Kensan, Solo5/solo5#552) * User hypercall instead of TSC-based clock when the user asks for the wall-clock (@dinosaure, @reynir, Solo5/solo5#549, Solo5/solo5#550) Note: only hvt & virtio are updated to avoid a clock drift on the wall-clock. Indeed, when the unikernel is suspended, the wall-clock is not updated. Muen & Xen still use a TSC-based wall-clock. The spt target was already in sync with the host's wall-clock. * Improve the muen clock (@Kensan, Solo5/solo5#553) * Fix the `.bss` section according to Solo5/solo5#542 & Solo5/solo5#546. The `.bss` section is tagged with `PT_LOAD`. Tenders are available to load this section properly. (@Kensan, @dinosaure, Solo5/solo5#551, Solo5/solo5#554) * Fix the cross-compilation of Solo5 for `aarch64` (@dinosaure, @palainp, @hannesm, Solo5/solo5#555) * Increase the Muen ABI (2 to 3) due to TLS changes (@Kensan, ocaml#557) * Support lifecycle management for Muen (@Kensan, ocaml#557) The user is able to configure automatic restarting of unikernels that invokes `solo5_ext()` * Fix the `test_fpu` test & ensure the alignment of variables (@Kensan, ocaml#557)
With the changes to the linker scripts in #546, the ELF segment containing the bss section is no longer of type PT_LOAD. This means it is not being processed by the Muen script and thus no longer initialized to zero. Explicitly set it to PT_LOAD in the linker script again to restore the original behavior. This was discovered when running Muen test unikernels on hardware, where memory is actually uninitialized and not zeroized as is done on most hypervisors.
Note that the same behavior goes for the common tender ELF loader, see
solo5/tenders/common/elf.c
Lines 249 to 250 in 7d5b70f