About -fasan-shadow-offset option
Dear gcc: I am developing a address sanitiser tools for u-boot. Basically refers compile options from kernel side. But there is a problem that I must set -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will use 0x10 as default value for shadow offset and caused boot failed because this value is too large. The problem is uboot do not have a fixed memory layout as kernel. Basically it will relocate to end of DDR size and running at that memory space. Usually memory map for uboot is virt=phys and there are lots of drivers do not do address translate for dma based on this mapping. But ddr size are different on each platform. So it's hard to handle shadow offset at this scenario. My point is that can gcc add an option like -fasan-shadow-symbol=, here is a global variable and implementors can configure it's value based on platforms ddr size/malloc buffer size during initialize stage and this variable can be used for shadow address calculation during runtime. This may be more fitable compared than a fixed value during compile stage. And is there any other options to help my problem? Waiting for your response asap. Thanks. Thanks! B.R. tao.z...@amlogic.com Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
[RISC-V] [SIG-toolchain] Meeting will be canceled (Nov 17, 2022)
Hi all, Tomorrow's meeting will be canceled, since there was few new topics to discuss. The next RISC-V GNU Toolchain meeting will be held on Dec 1. Please let me know if you have any topics want to discuss in the next meeting. Best Regards, Jiawei
Re: How can Autoconf help with the transition to stricter compilation defaults?
Hi,
On Tue, 15 Nov 2022, Paul Eggert wrote:
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would be
> found by Clang erroring out because 'char foo(void);' is the wrong
> prototype? Is it plausible that any such security flaw exists?
>
> On the contrary, it's more likely that Clang's erroring out here would
> *introduce* a security flaw, because it would cause 'configure' to
> incorrectly infer that an important security-relevant function is
> missing and that a flawed substitute needs to be used.
>
> Let's focus on real problems rather than worrying about imaginary ones.
I sympathize, and I would think a compiler emitting an error (not a
warning) in the situation at hand (in absence of -Werror) is overly
pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
ac_fn_c_check_func really does only a link test to check for symbol
existence, and the perceived problem is that the call statement in main()
invokes UB. So, let's avoid the call then while retaining the access to
the symbol? Like:
-
char foobar(void);
int main(void) {
return &foobar != 0;
}
-
No call involved: no reason for compiler to complain. The prototype decl
itself will still be "wrong", but compilers complaining about that (in
absence of a pre-existing different prototype, which is avoided by
autoconf) seem unlikely.
Obviously this program will also say "foobar exists" if it's a data
symbol, but that's the same with the variant using the call on most
platforms (after all it's not run).
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
Ciao,
Michael.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:
> I sympathize, and I would think a compiler emitting an error (not a
> warning) in the situation at hand (in absence of -Werror) is overly
> pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
> ac_fn_c_check_func really does only a link test to check for symbol
> existence, and the perceived problem is that the call statement in main()
> invokes UB. So, let's avoid the call then while retaining the access to
> the symbol? Like:
>
> -
> char foobar(void);
> int main(void) {
> return &foobar != 0;
> }
> -
>
> No call involved: no reason for compiler to complain. The prototype decl
> itself will still be "wrong", but compilers complaining about that (in
> absence of a pre-existing different prototype, which is avoided by
> autoconf) seem unlikely.
>
> Obviously this program will also say "foobar exists" if it's a data
> symbol, but that's the same with the variant using the call on most
> platforms (after all it's not run).
>
> The idea is so obvious that I'm probably missing something, why autoconf
> can't use that idiom instead. But perhaps the (historic?) reasons why it
> couldn't be used are gone now?
Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
and thus no symbol reference remains in the resulting assembly.
Alexander
Re: How can Autoconf help with the transition to stricter compilation defaults?
Hey,
On Wed, 16 Nov 2022, Alexander Monakov wrote:
> > The idea is so obvious that I'm probably missing something, why autoconf
> > can't use that idiom instead. But perhaps the (historic?) reasons why it
> > couldn't be used are gone now?
>
> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.
Err, right, *head-->table*.
Playing with volatile should help:
char foobar(void);
char (* volatile ptr)(void);
int main(void) {
ptr = foobar;
return ptr != 0;
}
Ciao,
Michael.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>
> Hey,
>
> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>
> > > The idea is so obvious that I'm probably missing something, why autoconf
> > > can't use that idiom instead. But perhaps the (historic?) reasons why it
> > > couldn't be used are gone now?
> >
> > Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> > and thus no symbol reference remains in the resulting assembly.
>
> Err, right, *head-->table*.
> Playing with volatile should help:
>
> char foobar(void);
> char (* volatile ptr)(void);
> int main(void) {
> ptr = foobar;
> return ptr != 0;
> }
using printf for foobar this works even with GCC 2.95.2 and with trunk
and -Wall diagnoses
t.c:1:6: warning: conflicting types for built-in function 'printf';
expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
1 | char printf(void);
| ^~
t.c:1:1: note: 'printf' is declared in header ''
+++ |+#include
1 | char printf(void);
so without -Werror this should be fine.
Richard.
>
>
> Ciao,
> Michael.
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 16 Nov 2022, at 15:27, Richard Biener wrote:
>
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>>
>> Hey,
>>
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>>
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
>>>
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>>
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>>
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
>
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
>
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
> | ^~
> t.c:1:1: note: 'printf' is declared in header ''
> +++ |+#include
>1 | char printf(void);
>
> so without -Werror this should be fine.
>
Unrelated but I was a bit tempted to ask for throwing in
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.
> Richard.
signature.asc
Description: Message signed with OpenPGP
Re: How can Autoconf help with the transition to stricter compilation defaults?
Hello, On Wed, 16 Nov 2022, Sam James wrote: > Unrelated but I was a bit tempted to ask for throwing in > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > it, but I suppose we don't want the world to burn too much, :-) It's IMHO a bug in the standard that it misses "if any of its associated headers are included" in the item for reservation of external linkage identifiers; it has that for all other items about reserved identifiers in the Library clause. If that restriction were added you couldn't justify erroring on the example at hand (because it doesn't include e.g. and then printf wouldn't be reserved). A warning is of course always okay and reasonable. As is, you could justify erroring out, but I too think that would be overzealous. Ciao, Michael.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, 16 Nov 2022 at 15:59, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Sam James wrote:
>
> > Unrelated but I was a bit tempted to ask for throwing in
> > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > it, but I suppose we don't want the world to burn too much,
>
> :-) It's IMHO a bug in the standard that it misses "if any of its
> associated headers are included" in the item for reservation of external
> linkage identifiers; it has that for all other items about reserved
> identifiers in the Library clause. If that restriction were added you
> couldn't justify erroring on the example at hand (because it doesn't
> include e.g. and then printf wouldn't be reserved). A warning
> is of course always okay and reasonable. As is, you could justify
> erroring out, but I too think that would be overzealous.
I think that's very intentional and not a defect in the standard.
If one TU was allowed to define:
void printf() { }
and have that compiled into the program, then that would cause
unexpected behaviour for every other TU which includes and
calls printf. They would get the non-standard rogue printf.
Re: How can Autoconf help with the transition to stricter compilation defaults?
Hello,
On Wed, 16 Nov 2022, Jonathan Wakely wrote:
> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-) It's IMHO a bug in the standard that it misses "if any of its
> > associated headers are included" in the item for reservation of external
> > linkage identifiers; it has that for all other items about reserved
> > identifiers in the Library clause. If that restriction were added you
> > couldn't justify erroring on the example at hand (because it doesn't
> > include e.g. and then printf wouldn't be reserved). A warning
> > is of course always okay and reasonable. As is, you could justify
> > erroring out, but I too think that would be overzealous.
>
>
> I think that's very intentional and not a defect in the standard.
>
> If one TU was allowed to define:
>
> void printf() { }
>
> and have that compiled into the program, then that would cause
> unexpected behaviour for every other TU which includes and
> calls printf. They would get the non-standard rogue printf.
True. But suppose the restriction would be added. I could argue that
then your problem program (in some other TU) _does_ include the header,
hence the identifier would have been reserved and so the above definition
would have been wrong. I.e. I think adding the restriction wouldn't allow
the problematic situation either.
I'm aware that the argument would then invoke all the usual problems of
what constitutes a full program, and if that includes the library even
when not including headers and so on. And in any case currently the
standard does say they're reserved so it's idle speculation anyway :)
Ciao,
Michael.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, 16 Nov 2022 at 16:34, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Jonathan Wakely wrote:
>
> > > > Unrelated but I was a bit tempted to ask for throwing in
> > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > > it, but I suppose we don't want the world to burn too much,
> > >
> > > :-) It's IMHO a bug in the standard that it misses "if any of its
> > > associated headers are included" in the item for reservation of external
> > > linkage identifiers; it has that for all other items about reserved
> > > identifiers in the Library clause. If that restriction were added you
> > > couldn't justify erroring on the example at hand (because it doesn't
> > > include e.g. and then printf wouldn't be reserved). A warning
> > > is of course always okay and reasonable. As is, you could justify
> > > erroring out, but I too think that would be overzealous.
> >
> >
> > I think that's very intentional and not a defect in the standard.
> >
> > If one TU was allowed to define:
> >
> > void printf() { }
> >
> > and have that compiled into the program, then that would cause
> > unexpected behaviour for every other TU which includes and
> > calls printf. They would get the non-standard rogue printf.
>
> True. But suppose the restriction would be added. I could argue that
> then your problem program (in some other TU) _does_ include the header,
> hence the identifier would have been reserved and so the above definition
> would have been wrong. I.e. I think adding the restriction wouldn't allow
> the problematic situation either.
>
> I'm aware that the argument would then invoke all the usual problems of
> what constitutes a full program, and if that includes the library even
> when not including headers and so on. And in any case currently the
> standard does say they're reserved so it's idle speculation anyway :)
Since we're idly speculating anyway ...
I'd always assumed the "if any of its associated headers is included"
meant in the current TU, but it doesn't actually say that. Which does
suggest that I can't use the identifier "assert" anywhere in a program
if any TU in the program includes . Huh.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On 2022-11-16 06:26, Michael Matz wrote:
char foobar(void);
int main(void) {
return &foobar != 0;
}
That still has undefined behavior according to draft C23, which says
behavior is undefined when foobar is (say) 'memset_explicit' because the
declaration 'char memset_explicit(void);' disagrees with draft C23's
declaration of 'memset_explicit'. It doesn't matter whether there's a
call to 'memset_explicit'. See draft C23 §6.2.7, which says "All
declarations that refer to the same object or function shall have
compatible type; otherwise, the behavior is undefined."
If Clang's threatened pickiness were of some real use elsewhere, it
might be justifiable for default Clang to break Autoconf. But so far we
haven't seen real-world uses that would justify this pickiness for
Autoconf's use of 'char memset_explicit(void);'.
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, Nov 16, 2022 at 1:18 PM Paul Eggert wrote: > ... > If Clang's threatened pickiness were of some real use elsewhere, it > might be justifiable for default Clang to break Autoconf. But so far we > haven't seen real-world uses that would justify this pickiness for > Autoconf's use of 'char memset_explicit(void);'. This line of arguments is not persuasive. It is full of logical fallacies. Maybe the Autoconf folks should argue something along the lines of, "this is the _only_ way to do it because <...>." Jeff
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char memset_explicit(void);'.
I don't have time this week to really get into this argument but I want to
point out that I'm generally in agreement with Rich Felker's argument (in
https://ewontfix.com/13/) that AC_CHECK_FUNC *should not* just probe for
linkability of a symbol, because:
- Not including the appropriate headers means that the probe bypasses
compile-time symbol renaming and therefore probes for *the wrong symbol*,
potentially causing both false detection and false non-detection (to tie it to
another subthread, notice that one of the things -D_TIME_BITS=64 triggers (from
glibc's headers) is enable dozens of __REDIRECT annotations in time.h)
- Only probing the symbol, and not its type signature, means for instance that
if the program expects GNU strerror_r but the system provides POSIX strerror_r,
or vice versa, Autoconf's check will succeed but the program will fail to
compile (in more subtle cases it might be miscompiled instead)
(N.B. I *don't* agree with the assertion at the bottom of that page that
"taking explicit action to prevent linking against [symbols intended to be
exposed for binary compatibility only], involves hacks that are even worse and
more fragile than what configure is doing" -- yes, it sucks that the toolchain
support for ELF symbol versioning is still mostly absent, 20 years after the
concept was introduced, but `asm(".symver __strtod_l_compat,
strtod_l@SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and
robust on all the platforms where it works at all.)
zw
Bbbkkmnmnkkkkkkkkkkkkkb j
Sent from my iPhone
