|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [UNIKRAFT PATCH v2] include: Move sections.h to include/uk
Hi all, @MichalisI think, a problem that we still architecturally have is that we compile general purpose libs (like ukboot) once and link them multiple times for each selected platform. This implies that exposing platform-specific symbols to general purpose code is tricky. In general purpose code, you can only rely on symbols that every platform is providing. This is why I think that such specific symbols (like _dtb) should stay within the platform and should be (indirectly) exported (if at all needed) through a driver~ish or query API, something similar we have with the memory regions, uknetdev, and ukblkdev. The original idea was to make sure that general purpose applications stay portable across different platforms. Of course, this consideration does not include the case where you want to develop something just for a single platform, like a driver domain for Xen which would anyways not be portable to, lets say KVM. For now you would be forced to put such code as platform library which isn't nice, I agree. I think this needs a solution in general. Maybe the build system could behave differently and unlock additional defintions when we select only a single platform. @StefanRegarding moving sections.h to the generic `include/` folder, I still did not really understand the reason and it is unclear to me what should be the defined behavior in case of ASLR. In comparison, what does happen with PIE executables on Linux? To my understanding, the linker will resolve the symbols with the addresses in the image at compile time. Do you know if PIE executables make use of the dynamic linker for resolving? In such a case, this is a less problematic point. Alternatively, would the memory region query interface fit, too? The idea of this would to overcome the problem that some things may change at runtime (e.g., early platform boot code) compared to compile time. I think, we have two options:(1) In the case that the dynamic linker is normally taking care of solving such symbols for position-independent executables, I think it should be fine to place the header to `include/uk/plat/sections.h`. The idea would be to revisit it later when we introduce ASLR. In general we should make sure that we define only the symbols in there which all platforms linker scripts provide (like the ones for text, bss, etc). Platform-specific symbols should stay in the platform, like `_dtb`. (2) Do not expose section.h to general purpose code and use the memory region interface and maybe extend it with what you need. What do you think? Thanks, Simon On 28.10.20 15:26, Michalis Pappas wrote: Before exposing sections.h to applications, I would like to take the opportunity to discuss some architectural matters.Currently linker scripts and their associated symbol definitions are owned by platforms. At the same time, sections.h is under plat/common/, and contains some common symbol names that are more or less declared by all platforms. Platforms wishing to declare additional, and perhaps less common symbol names, have the option to either (1) pollute sections.h, or (2) add these symbols to a platform-specific header. In case (1) sections.h will eventually contain a superset of all section symbols declared by all platforms, which is dirty. In case (2) platforms lose the ability to export their additional symbols to applications, which is also a problem.One possible approach to work around this would be to make symbols.h platform-specific, and then allow platforms to export platform-specific headers under platform subdirectories in include/uk/plat/ (eg include/uk/plat/kvm/sections.h), or alternatively export the current sections.h through include/uk/ and export additional platform-specific headers through platform subdirectories in include/uk/plat/, as above.Thanks, Michalis On 28/10/2020 14:45, Stefan Teodorescu wrote:Hi everyone, Sorry for the confusion, this is my fault that I didn't clarify enough in the commit message and that I didn't update it in the meantime. I am using the sections.h header in the mem_layout.h header (which is also in include/uk) that I am writing now to describe the virtual memory areas (kernel, stack, heap etc.). At the moment, I think I was using the sections.h header in some arch code but this is not the case anymore. However, as Costin mentioned, we thought at the time that we could move this anyway, since it's not actually platform dependent. I'll send a v2 with an updated commit message. Thanks, StefanOn Wed, Oct 28, 2020 at 3:19 PM Costin Lupu <costin.lupu@xxxxxxxxx> wrote:Hi Simon, Regardless whether these changes are needed or not by arch code (I'll leave that for Ștefan to explain), the definitions in sections.h should stay under include/uk in order to be accessible from everywhere. Moreover, the definitions in it are related to neither arch or platform. Cheers, Costin On 10/28/20 3:14 PM, Simon Kuenzer wrote:Hey Stefan, hey Costin,what is the reason that arch code needs sections.h? I can't read it fromthe commit message. Architecture code should only be the parts that aretotally independent on the platform details. They are mostly helpers forarithmetics and CPU register definitions. I am concerned that architecture code may break when doing assumptions on symbol locations; imagine ASLR where locations are moved at runtime. The NX bit patch is upstream. Thanks, Simon On 26.10.20 17:14, stefanl.teodorescu@xxxxxxxxx wrote:
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |