| Message ID | 20171120091520.86128-1-borntraeger@de.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | pc-bios/s390-ccw: build s390 bios with -fno-zero-initialized-in-bss | expand |
On 11/20/2017 10:15 AM, Christian Borntraeger wrote: > The QEMU ELF loader does not initialize the bss segment. This has > triggered several bugs in the past, e.g. see commit 5d739a4787a5 > ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize > css"). > > Instead of fixing these things one-by-one we can build the BIOS > with -fno-zero-initialized-in-bss. This will move the zero variables > also into the data segment, which is then part of a LOAD section. Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) Alex
On 20.11.2017 10:15, Christian Borntraeger wrote: > The QEMU ELF loader does not initialize the bss segment. This has > triggered several bugs in the past, e.g. see commit 5d739a4787a5 > ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize > css"). > > Instead of fixing these things one-by-one we can build the BIOS > with -fno-zero-initialized-in-bss. This will move the zero variables > also into the data segment, which is then part of a LOAD section. It fixes the problem only for variables that are explicitely intialized to 0 along with their declaration - it does not fix the problem for uninitialized variables. Thomas
On 11/20/2017 10:19 AM, Alexander Graf wrote: > On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >> The QEMU ELF loader does not initialize the bss segment. This has >> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >> css"). >> >> Instead of fixing these things one-by-one we can build the BIOS >> with -fno-zero-initialized-in-bss. This will move the zero variables >> also into the data segment, which is then part of a LOAD section. > > Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) Yes the proper fix is to initialize bss in the bios itself. I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it.
On 11/20/2017 10:27 AM, Christian Borntraeger wrote: > > On 11/20/2017 10:19 AM, Alexander Graf wrote: >> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>> The QEMU ELF loader does not initialize the bss segment. This has >>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>> css"). >>> >>> Instead of fixing these things one-by-one we can build the BIOS >>> with -fno-zero-initialized-in-bss. This will move the zero variables >>> also into the data segment, which is then part of a LOAD section. >> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) > Yes the proper fix is to initialize bss in the bios itself. > I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). Alex
On 11/20/2017 10:29 AM, Alexander Graf wrote: > On 11/20/2017 10:27 AM, Christian Borntraeger wrote: >> >> On 11/20/2017 10:19 AM, Alexander Graf wrote: >>> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>>> The QEMU ELF loader does not initialize the bss segment. This has >>>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>>> css"). >>>> >>>> Instead of fixing these things one-by-one we can build the BIOS >>>> with -fno-zero-initialized-in-bss. This will move the zero variables >>>> also into the data segment, which is then part of a LOAD section. >>> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) >> Yes the proper fix is to initialize bss in the bios itself. >> I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. > > > Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). Yes, I know but then we have to change the build process to use a linker script.(we rely on the default linker script right now).
On 11/20/2017 11:02 AM, Christian Borntraeger wrote: > > On 11/20/2017 10:29 AM, Alexander Graf wrote: >> On 11/20/2017 10:27 AM, Christian Borntraeger wrote: >>> On 11/20/2017 10:19 AM, Alexander Graf wrote: >>>> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>>>> The QEMU ELF loader does not initialize the bss segment. This has >>>>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>>>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>>>> css"). >>>>> >>>>> Instead of fixing these things one-by-one we can build the BIOS >>>>> with -fno-zero-initialized-in-bss. This will move the zero variables >>>>> also into the data segment, which is then part of a LOAD section. >>>> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) >>> Yes the proper fix is to initialize bss in the bios itself. >>> I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. >> >> Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). > Yes, I know but then we have to change the build process to use a linker script.(we rely on the default > linker script right now). I'm not sure how common generic linker scripts are, but in our default script we have existing markers for bss and end. You can look at the default linker script using gcc <c file> -Wl,-verbose. This simple source worked for me: #include <stdio.h> extern char __bss_start[]; extern char _end[]; int main(void) { printf("BSS size: %lx\n", (long)_end - (long)__bss_start); return 0; } Alex
On 11/20/2017 11:16 AM, Alexander Graf wrote: > On 11/20/2017 11:02 AM, Christian Borntraeger wrote: >> >> On 11/20/2017 10:29 AM, Alexander Graf wrote: >>> On 11/20/2017 10:27 AM, Christian Borntraeger wrote: >>>> On 11/20/2017 10:19 AM, Alexander Graf wrote: >>>>> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>>>>> The QEMU ELF loader does not initialize the bss segment. This has >>>>>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>>>>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>>>>> css"). >>>>>> >>>>>> Instead of fixing these things one-by-one we can build the BIOS >>>>>> with -fno-zero-initialized-in-bss. This will move the zero variables >>>>>> also into the data segment, which is then part of a LOAD section. >>>>> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) >>>> Yes the proper fix is to initialize bss in the bios itself. >>>> I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. >>> >>> Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). >> Yes, I know but then we have to change the build process to use a linker script.(we rely on the default >> linker script right now). > > > I'm not sure how common generic linker scripts are, but in our default script we have existing markers for bss and end. You can look at the default linker script using gcc <c file> -Wl,-verbose. This simple source worked for me: Are we sure that the range between __bss_start and _end does not include other elements (besides bss)? > > > #include <stdio.h> > > extern char __bss_start[]; > extern char _end[]; > > int main(void) > { > printf("BSS size: %lx\n", (long)_end - (long)__bss_start); > return 0; > } > > > > Alex > >
On 11/20/2017 11:19 AM, Christian Borntraeger wrote: > > On 11/20/2017 11:16 AM, Alexander Graf wrote: >> On 11/20/2017 11:02 AM, Christian Borntraeger wrote: >>> On 11/20/2017 10:29 AM, Alexander Graf wrote: >>>> On 11/20/2017 10:27 AM, Christian Borntraeger wrote: >>>>> On 11/20/2017 10:19 AM, Alexander Graf wrote: >>>>>> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>>>>>> The QEMU ELF loader does not initialize the bss segment. This has >>>>>>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>>>>>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>>>>>> css"). >>>>>>> >>>>>>> Instead of fixing these things one-by-one we can build the BIOS >>>>>>> with -fno-zero-initialized-in-bss. This will move the zero variables >>>>>>> also into the data segment, which is then part of a LOAD section. >>>>>> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) >>>>> Yes the proper fix is to initialize bss in the bios itself. >>>>> I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. >>>> Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). >>> Yes, I know but then we have to change the build process to use a linker script.(we rely on the default >>> linker script right now). >> >> I'm not sure how common generic linker scripts are, but in our default script we have existing markers for bss and end. You can look at the default linker script using gcc <c file> -Wl,-verbose. This simple source worked for me: > Are we sure that the range between __bss_start and _end does not include other elements (besides bss)? It seems to be the intended semantic for the linker script I see as default, but I'm not an expert here :). Can you check with Uli? Alex
On 11/20/2017 11:24 AM, Alexander Graf wrote: > On 11/20/2017 11:19 AM, Christian Borntraeger wrote: >> >> On 11/20/2017 11:16 AM, Alexander Graf wrote: >>> On 11/20/2017 11:02 AM, Christian Borntraeger wrote: >>>> On 11/20/2017 10:29 AM, Alexander Graf wrote: >>>>> On 11/20/2017 10:27 AM, Christian Borntraeger wrote: >>>>>> On 11/20/2017 10:19 AM, Alexander Graf wrote: >>>>>>> On 11/20/2017 10:15 AM, Christian Borntraeger wrote: >>>>>>>> The QEMU ELF loader does not initialize the bss segment. This has >>>>>>>> triggered several bugs in the past, e.g. see commit 5d739a4787a5 >>>>>>>> ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize >>>>>>>> css"). >>>>>>>> >>>>>>>> Instead of fixing these things one-by-one we can build the BIOS >>>>>>>> with -fno-zero-initialized-in-bss. This will move the zero variables >>>>>>>> also into the data segment, which is then part of a LOAD section. >>>>>>> Doesn't this bloat the firmware? Why don't we just manually clear bss in the firmware itself? It's what all other firmwares do :) >>>>>> Yes the proper fix is to initialize bss in the bios itself. >>>>>> I was trying to come up with something for 2.11, but since the patch does not solve the original issues, lets drop it. >>>>> Initializing bss is quite simple. You can probably even do it from C. Just set two variables before and after .bss in the linker script and memset(0) from start to end :). >>>> Yes, I know but then we have to change the build process to use a linker script.(we rely on the default >>>> linker script right now). >>> >>> I'm not sure how common generic linker scripts are, but in our default script we have existing markers for bss and end. You can look at the default linker script using gcc <c file> -Wl,-verbose. This simple source worked for me: >> Are we sure that the range between __bss_start and _end does not include other elements (besides bss)? > > It seems to be the intended semantic for the linker script I see as default, but I'm not an expert here :). Can you check with Uli? I will. But the "I am not sure" is exactly the reason why I prefer Thomas "band-aid" for 2.11. Doing the bss zeroing is certainly my preferred long term solution (and it was my first comment to Thomas' patch)
On 11/20/2017 11:19 AM, Christian Borntraeger wrote: > Are we sure that the range between __bss_start and _end does not include > other elements (besides bss)? Yes, we are sure. r~
diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile index 6d0c2ee..2687590 100644 --- a/pc-bios/s390-ccw/Makefile +++ b/pc-bios/s390-ccw/Makefile @@ -12,7 +12,7 @@ $(call set-vpath, $(SRC_PATH)/pc-bios/s390-ccw) OBJECTS = start.o main.o bootmap.o sclp.o virtio.o virtio-scsi.o virtio-blkdev.o QEMU_CFLAGS := $(filter -W%, $(QEMU_CFLAGS)) QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks -msoft-float -QEMU_CFLAGS += -march=z900 -fPIE -fno-strict-aliasing +QEMU_CFLAGS += -march=z900 -fPIE -fno-strict-aliasing -fno-zero-initialized-in-bss QEMU_CFLAGS += $(call cc-option, $(QEMU_CFLAGS), -fno-stack-protector) LDFLAGS += -Wl,-pie -nostdlib
The QEMU ELF loader does not initialize the bss segment. This has triggered several bugs in the past, e.g. see commit 5d739a4787a5 ("s390-ccw.img: Fix sporadic errors with ccw boot image - initialize css"). Instead of fixing these things one-by-one we can build the BIOS with -fno-zero-initialized-in-bss. This will move the zero variables also into the data segment, which is then part of a LOAD section. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- pc-bios/s390-ccw/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)