| View previous topic :: View next topic |
| Author |
Message |
XiaoaiX
n00b
Joined: 30 May 2015
Posts: 30
|
 Posted: Sun Jun 12, 2022 2:22 am Post subject: a bug of gcc -O2 for mips64el-n32 on loongson 2f ? |
 |
|
I met this problem when upgrading to coreutils-8.32 on an mips64el-n32 system of Yeeloong netbook with loongon-2f mips cpu. It occurs when testing the "%n" parameter for sprintf compiled with "gcc -O2" when doing the ./configure. The c program is as follows ( I've modified the original test code in the configure process of the coreutils-8.32 a little but kept the same problem here)
| Code: |
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static char fmtstring[10];
static char buf[100];
int main ()
{
int count = -1;
/* Copy the format string. Some systems (glibc with _FORTIFY_SOURCE=2)
support %n in format strings in read-only memory but not in writable
memory. */
strcpy (fmtstring, "%d %n");
if (sprintf (buf, fmtstring, 123, &count, 33, 44, 55) < 0
|| strcmp (buf, "123 ") != 0
|| count != 4)
{
printf("wrong");
return 1;
}
printf("right");
return 0;
}
|
If compile without "-O2" optimization, there is no problem at runtime. But if with -O2, there will be a problem at runtime:
| Code: |
*** %n in writable segment detected ***
|
This happens both with gcc-11.3.0 and with 8.3.0.
Is this a bug of gcc? |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22717
|
| Posted: Sun Jun 12, 2022 2:57 am Post subject: |
|
|
| No. This is a bug in the C program that is attempting to use the unsafe modifier %n from writable memory, while fortification is enabled. %n can be used in certain exploits, so glibc includes some elaborate code to refuse to accept it in writable memory. |
|
| Back to top |
|
|
XiaoaiX
n00b
Joined: 30 May 2015
Posts: 30
|
| Posted: Sun Jun 12, 2022 3:28 am Post subject: |
|
|
| Hu wrote: | | No. This is a bug in the C program that is attempting to use the unsafe modifier %n from writable memory, while fortification is enabled. %n can be used in certain exploits, so glibc includes some elaborate code to refuse to accept it in writable memory. |
But compiled without "-O2", it can run successfully. Why only refuse to accept it only with "-O2" optimization?
On amd64 system, this program is also compiled and run without a problem both with and without "-O2". |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1982
|
| Posted: Sun Jun 12, 2022 7:55 am Post subject: |
|
|
| XiaoaiX wrote: | | Hu wrote: | | No. This is a bug in the C program that is attempting to use the unsafe modifier %n from writable memory, while fortification is enabled. %n can be used in certain exploits, so glibc includes some elaborate code to refuse to accept it in writable memory. |
But compiled without "-O2", it can run successfully. Why only refuse to accept it only with "-O2" optimization?
On amd64 system, this program is also compiled and run without a problem both with and without "-O2". |
1. Some optimisation is needed for FORTIFY_SOURCE.
2. Optimisation unlocks more introspection (and obviously optimisation) passes within the compiler through which it learns more about the code.
If the program is clearly doing something naughty, the options which make it work - or not - should not be read into. Compilers are free to ignore - or not ignore - undefined behaviour as they wish. They are not compliance checkers.
It sounds a bit to me like this test is supposed to fail anyway, right? What's the original problem you hit? |
|
| Back to top |
|
|
XiaoaiX
n00b
Joined: 30 May 2015
Posts: 30
|
| Posted: Sun Jun 12, 2022 9:33 am Post subject: |
|
|
| sam_ wrote: | | XiaoaiX wrote: | | Hu wrote: | | No. This is a bug in the C program that is attempting to use the unsafe modifier %n from writable memory, while fortification is enabled. %n can be used in certain exploits, so glibc includes some elaborate code to refuse to accept it in writable memory. |
But compiled without "-O2", it can run successfully. Why only refuse to accept it only with "-O2" optimization?
On amd64 system, this program is also compiled and run without a problem both with and without "-O2". |
1. Some optimisation is needed for FORTIFY_SOURCE.
2. Optimisation unlocks more introspection (and obviously optimisation) passes within the compiler through which it learns more about the code.
If the program is clearly doing something naughty, the options which make it work - or not - should not be read into. Compilers are free to ignore - or not ignore - undefined behaviour as they wish. They are not compliance checkers.
It sounds a bit to me like this test is supposed to fail anyway, right? What's the original problem you hit? |
Yes, the emerge hung up forever at the configure step while I am using "-O2" in the CFLAGS. The problem is caused by the test for the support of "%n" of sprintf. The configure would try to compile the test program like the one in my first post and run it and then it hung up forever.
I forgot to say that besides the error message in my original post, the program hung up forever in the runtime.
Do you mean that I need to add some more flags in CFLAGS to enable or disable FORTIFY_SOURCE? What CFLAGS should be added? Thanks. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22717
|
| Posted: Sun Jun 12, 2022 3:47 pm Post subject: |
|
|
%n is strongly discouraged in writable memory, to the point that glibc will abort the program for trying it. Therefore, I consider it a bug for any C program that links to glibc to use %n in writable memory. If this configure test is as you showed, then the test is broken.
Regardless of that, the test program should have compiled quickly and correctly. Running it would not be useful, but compilation should have finished. |
|
| Back to top |
|
|
XiaoaiX
n00b
Joined: 30 May 2015
Posts: 30
|
| Posted: Mon Jun 13, 2022 3:52 am Post subject: |
|
|
| Hu wrote: | %n is strongly discouraged in writable memory, to the point that glibc will abort the program for trying it. Therefore, I consider it a bug for any C program that links to glibc to use %n in writable memory. If this configure test is as you showed, then the test is broken.
Regardless of that, the test program should have compiled quickly and correctly. Running it would not be useful, but compilation should have finished. |
Yes, the compilation is successful but the program would never return at runtime. But the configure script was waiting for the return value of the program forever. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22717
|
| Posted: Mon Jun 13, 2022 2:45 pm Post subject: |
|
|
| That is a strange failure mode. However, I maintain that it is a bug for this program to use %n in writable memory, while linked to glibc, and while using source fortification, because we know that glibc reacts badly to that combination. The program ought not do all those things at once. When using glibc with fortification, it should not use a writable %n. The authors of the test even seem to expect that this will not work well, so it is strange that they would test for it. I would further argue that testing for it at configure time is wrong anyway, since the user might build on a glibc that permits it, then upgrade to one that does not. |
|
| Back to top |
|
|
XiaoaiX
n00b
Joined: 30 May 2015
Posts: 30
|
| Posted: Tue Jun 14, 2022 4:14 am Post subject: |
|
|
| Hu wrote: | | That is a strange failure mode. However, I maintain that it is a bug for this program to use %n in writable memory, while linked to glibc, and while using source fortification, because we know that glibc reacts badly to that combination. The program ought not do all those things at once. When using glibc with fortification, it should not use a writable %n. The authors of the test even seem to expect that this will not work well, so it is strange that they would test for it. I would further argue that testing for it at configure time is wrong anyway, since the user might build on a glibc that permits it, then upgrade to one that does not. |
Thanks. I understand your point. Maybe newer versions of the coreutils has no such problem. I will try later. If the problem is still there, I will come back. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
