Re: segment fault
Please move this discussion to the gcc-help mailing list where it belongs. I'll reply on that list instead. On Tue, 28 Apr 2020 at 07:07, luo alvin wrote: > > Thank you very much for replying me. I also think it not bug,because I test > this code in the lower version(lower than 8.3.1-3) of gcc,all cause segment > fault. The funny thing is that if you run this code higher than gcc > version(8.3.1-4)(actually I only test code in the version 8.3.1-4),the result > is fine(doesn’t lead to segment fault).furthermore, I found that the value of > sizeof(std::string) is different between gcc versions. Value in version > 8.3.1-3 is 8 ,and 32 in version 8.3.1-4. > > 发送自 Windows 10 版邮件应用 > > > > 发件人: Jonathan Wakely > 发送时间: 2020年4月28日 13:56 > 收件人: luo alvin > 抄送: gcc@gcc.gnu.org > 主题: Re: segment fault > > > > On Tue, 28 Apr 2020 at 02:26, luo alvin via Gcc wrote: > > > > Dear gnu: > >Here is code: > > Please do not report bugs to this mailing list. Bug reports belong in > our Bugzilla database, see https://gcc.gnu.org/bugs/ > > But this is not a bug anyway, your code has undefined behaviour. You > cannot use memset on non-trivial objects. Using memset like that > overwrites the contents of the std::string with invalid data. > >
Questions about -fanalyzer implementation
Hi, Does the analysis framework available in GCC 10 is an instance of an IFDS or an IDE framework? The Analyzer Internals [0] refers to the IFDS paper [1], but I am not sure if this is only to provide a reference to the definition of exploded supergraph. Also, if I want to implement my own IPA-LTO typestate analysis [2], what classes would I need to implement in order to take advantage of this framework? I see that I need to implement a * `state_machine` class (if it is IFDS, are nodes in the state machine part of the domain of the transfer functions? I imagine something like (variable, state) being the domain of the transfer functions.) * `on_stmt` function. Are these the transfer functions? (I can see that you are calling on_transition with variable, current state, next state or similarly). * where's the meet operator? I see functions on_transition and on_edge, but it is not clear where the meet operator is defined. [0] https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals [1] https://dl.acm.org/doi/10.1145/199448.199462 [2] Yes, I read the documentation and see that there are still bugs regarding the analysis framework working during LTO and it is C only.
aarch64 C++ ABI analysis
Hi!
The same testcase as has been used for powerpc64le-linux can be
used for aarch64-linux too:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a, b, c, d; };
struct D : public Z { float a, b, c, d; };
struct E : public U { float a, b, c, d; };
struct F { [[no_unique_address]] X x; float a, b, c, d; };
struct G { [[no_unique_address]] Y y; float a, b, c, d; };
struct H { [[no_unique_address]] Z z; float a, b, c, d; };
struct I { [[no_unique_address]] U u; float a, b, c, d; };
struct J { float a, b; [[no_unique_address]] X x; float c, d; };
struct K { float a, b; [[no_unique_address]] Y y; float c, d; };
struct L { float a, b; [[no_unique_address]] Z z; float c, d; };
struct M { float a, b; [[no_unique_address]] U u; float c, d; };
#define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s (s);
return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
Here, G++ 9 -std=c++17 passes just A in s0-s3 and the rest elsewhere,
G++ 9 -std=c++17 and current trunk -std=c++14 & -std=c++17 passes
A, B, C in s0-s3 and the rest elsewhere, and
clang++ from today passes A, B, C, F, G, J, K in s0-s3 and the rest
elsewhere.
So, if we want to follow and handle [[no_unique_address]] empty fields
like C++17 empty bases, we need similar patch to what I've posted for
powerc64le-linux, subject to any changes in how we want to check for
those fields.
Haven't checked ARM 32-bit, I don't even know what exact options are needed
for that.
Jakub
Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
Hello, I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has had nothing but tumbleweeds in months, and it is continuing to cause problems for Xen. During the Spectre embargo period, it was specifically identified that kernels would need to be able to compile one single binary, which was retpoline safe on older hardware, and able to use CET on newer hardware. thunk-extern was deliberately constructed (along with -mindirect-branch-register) such that the thunk could be turned into something which wasn't a ROP gadget when hardware was less broken. Both Linux and Xen use this, with the ability to substitute the exact thunk in use to be suitable for the CPU booted on. (In particular, AMD recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) A consequence of GCC rejecting this combination is that Linux has unilaterally disabled -fcf-protection # ensure -fcf-protection is disabled when using retpoline as it is # incompatible with -mindirect-branch=thunk-extern ifdef CONFIG_RETPOLINE KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) endif and a change similar to this is being proposed for Xen. However, doing this will leave distros with the choice between disabling retpoline or not using CET, which is not in the best security interest of the user. Please can the original change be partially reverted? thunk-extern means "I'm providing the thunks, and I'll take care of ensuring that they are appropriate", and that includes not being a ROP gadget when CET is active. Thanks, ~Andrew
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On 28/04/2020 14:00, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > wrote: >> Hello, >> >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has >> had nothing but tumbleweeds in months, and it is continuing to cause >> problems for Xen. >> >> During the Spectre embargo period, it was specifically identified that >> kernels would need to be able to compile one single binary, which was >> retpoline safe on older hardware, and able to use CET on newer hardware. >> >> thunk-extern was deliberately constructed (along with >> -mindirect-branch-register) such that the thunk could be turned into >> something which wasn't a ROP gadget when hardware was less broken. Both >> Linux and Xen use this, with the ability to substitute the exact thunk >> in use to be suitable for the CPU booted on. (In particular, AMD >> recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) >> >> >> A consequence of GCC rejecting this combination is that Linux has >> unilaterally disabled -fcf-protection >> >> # ensure -fcf-protection is disabled when using retpoline as it is >> # incompatible with -mindirect-branch=thunk-extern >> ifdef CONFIG_RETPOLINE >> KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) >> endif >> >> and a change similar to this is being proposed for Xen. However, doing >> this will leave distros with the choice between disabling retpoline or >> not using CET, which is not in the best security interest of the user. >> >> Please can the original change be partially reverted? thunk-extern >> means "I'm providing the thunks, and I'll take care of ensuring that >> they are appropriate", and that includes not being a ROP gadget when CET >> is active. >> > Please DO disable -fcf-protection in the kernel build. We are enabling > CET for the user space first. The kernel CET will be the next. > > I am enclosing a proposal to make -fcf-protection compatible with retpoline. > It targets user space. It can be made compatible with kernel. Its fine to focus on userspace first, but the kernel is far more simple. Looking at that presentation, the only thing missing for kernel is the notrack thunks, in the unlikely case that such code would be tolerated (Frankly, I don't expect Xen or Linux to run with notrack enabled, as there is no legacy code to be concerned with). What is going to happen about unbreaking this combination of options? How will we know when kernel mode is supported (not that I can see anything further required from the toolchain)? I really hope you're not suggesting that we'll need to use something separate such as -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. ~Andrew
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper wrote: > > On 28/04/2020 14:00, H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > > wrote: > >> Hello, > >> > >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has > >> had nothing but tumbleweeds in months, and it is continuing to cause > >> problems for Xen. > >> > >> During the Spectre embargo period, it was specifically identified that > >> kernels would need to be able to compile one single binary, which was > >> retpoline safe on older hardware, and able to use CET on newer hardware. > >> > >> thunk-extern was deliberately constructed (along with > >> -mindirect-branch-register) such that the thunk could be turned into > >> something which wasn't a ROP gadget when hardware was less broken. Both > >> Linux and Xen use this, with the ability to substitute the exact thunk > >> in use to be suitable for the CPU booted on. (In particular, AMD > >> recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) > >> > >> > >> A consequence of GCC rejecting this combination is that Linux has > >> unilaterally disabled -fcf-protection > >> > >> # ensure -fcf-protection is disabled when using retpoline as it is > >> # incompatible with -mindirect-branch=thunk-extern > >> ifdef CONFIG_RETPOLINE > >> KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) > >> endif > >> > >> and a change similar to this is being proposed for Xen. However, doing > >> this will leave distros with the choice between disabling retpoline or > >> not using CET, which is not in the best security interest of the user. > >> > >> Please can the original change be partially reverted? thunk-extern > >> means "I'm providing the thunks, and I'll take care of ensuring that > >> they are appropriate", and that includes not being a ROP gadget when CET > >> is active. > >> > > Please DO disable -fcf-protection in the kernel build. We are enabling > > CET for the user space first. The kernel CET will be the next. > > > > I am enclosing a proposal to make -fcf-protection compatible with retpoline. > > It targets user space. It can be made compatible with kernel. > > Its fine to focus on userspace first, but the kernel is far more simple. > > Looking at that presentation, the only thing missing for kernel is the > notrack thunks, in the unlikely case that such code would be tolerated > (Frankly, I don't expect Xen or Linux to run with notrack enabled, as > there is no legacy code to be concerned with). > > What is going to happen about unbreaking this combination of options? > How will we know when kernel mode is supported (not that I can see > anything further required from the toolchain)? I really hope you're not My proposal requires assembler, linker and compiler changes. > suggesting that we'll need to use something separate such as > -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. -mcmodel=kernel should be sufficient. If -mcmodel=kernel -fcf-protection -mindirect-branch=thunk-extern works, your toolchain has implemented my proposal. -- H.J.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On 28.04.2020 17:00, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper > wrote: >> >> On 28/04/2020 14:00, H.J. Lu wrote: >>> On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper >>> wrote: Hello, I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has had nothing but tumbleweeds in months, and it is continuing to cause problems for Xen. During the Spectre embargo period, it was specifically identified that kernels would need to be able to compile one single binary, which was retpoline safe on older hardware, and able to use CET on newer hardware. thunk-extern was deliberately constructed (along with -mindirect-branch-register) such that the thunk could be turned into something which wasn't a ROP gadget when hardware was less broken. Both Linux and Xen use this, with the ability to substitute the exact thunk in use to be suitable for the CPU booted on. (In particular, AMD recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) A consequence of GCC rejecting this combination is that Linux has unilaterally disabled -fcf-protection # ensure -fcf-protection is disabled when using retpoline as it is # incompatible with -mindirect-branch=thunk-extern ifdef CONFIG_RETPOLINE KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) endif and a change similar to this is being proposed for Xen. However, doing this will leave distros with the choice between disabling retpoline or not using CET, which is not in the best security interest of the user. Please can the original change be partially reverted? thunk-extern means "I'm providing the thunks, and I'll take care of ensuring that they are appropriate", and that includes not being a ROP gadget when CET is active. >>> Please DO disable -fcf-protection in the kernel build. We are enabling >>> CET for the user space first. The kernel CET will be the next. >>> >>> I am enclosing a proposal to make -fcf-protection compatible with retpoline. >>> It targets user space. It can be made compatible with kernel. >> >> Its fine to focus on userspace first, but the kernel is far more simple. >> >> Looking at that presentation, the only thing missing for kernel is the >> notrack thunks, in the unlikely case that such code would be tolerated >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as >> there is no legacy code to be concerned with). >> >> What is going to happen about unbreaking this combination of options? >> How will we know when kernel mode is supported (not that I can see >> anything further required from the toolchain)? I really hope you're not > > My proposal requires assembler, linker and compiler changes. > >> suggesting that we'll need to use something separate such as >> -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. > > -mcmodel=kernel should be sufficient. If > > -mcmodel=kernel -fcf-protection -mindirect-branch=thunk-extern > > works, your toolchain has implemented my proposal. But please note that Xen doesn't get built with -mcmodel=kernel, so the two remaining options ought to work together also without this one. Jan
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On Tue, Apr 28, 2020 at 8:06 AM Jan Beulich wrote: > > On 28.04.2020 17:00, H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper > > wrote: > >> > >> On 28/04/2020 14:00, H.J. Lu wrote: > >>> On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > >>> wrote: > Hello, > > I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has > had nothing but tumbleweeds in months, and it is continuing to cause > problems for Xen. > > During the Spectre embargo period, it was specifically identified that > kernels would need to be able to compile one single binary, which was > retpoline safe on older hardware, and able to use CET on newer hardware. > > thunk-extern was deliberately constructed (along with > -mindirect-branch-register) such that the thunk could be turned into > something which wasn't a ROP gadget when hardware was less broken. Both > Linux and Xen use this, with the ability to substitute the exact thunk > in use to be suitable for the CPU booted on. (In particular, AMD > recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) > > > A consequence of GCC rejecting this combination is that Linux has > unilaterally disabled -fcf-protection > > # ensure -fcf-protection is disabled when using retpoline as it is > # incompatible with -mindirect-branch=thunk-extern > ifdef CONFIG_RETPOLINE > KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) > endif > > and a change similar to this is being proposed for Xen. However, doing > this will leave distros with the choice between disabling retpoline or > not using CET, which is not in the best security interest of the user. > > Please can the original change be partially reverted? thunk-extern > means "I'm providing the thunks, and I'll take care of ensuring that > they are appropriate", and that includes not being a ROP gadget when CET > is active. > > >>> Please DO disable -fcf-protection in the kernel build. We are enabling > >>> CET for the user space first. The kernel CET will be the next. > >>> > >>> I am enclosing a proposal to make -fcf-protection compatible with > >>> retpoline. > >>> It targets user space. It can be made compatible with kernel. > >> > >> Its fine to focus on userspace first, but the kernel is far more simple. > >> > >> Looking at that presentation, the only thing missing for kernel is the > >> notrack thunks, in the unlikely case that such code would be tolerated > >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as > >> there is no legacy code to be concerned with). > >> > >> What is going to happen about unbreaking this combination of options? > >> How will we know when kernel mode is supported (not that I can see > >> anything further required from the toolchain)? I really hope you're not > > > > My proposal requires assembler, linker and compiler changes. > > > >> suggesting that we'll need to use something separate such as > >> -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. > > > > -mcmodel=kernel should be sufficient. If > > > > -mcmodel=kernel -fcf-protection -mindirect-branch=thunk-extern > > > > works, your toolchain has implemented my proposal. > > But please note that Xen doesn't get built with -mcmodel=kernel, so > the two remaining options ought to work together also without this > one. Then -fcf-protection -mindirect-branch=thunk-extern for Xen. -- H.J.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On 28/04/2020 16:09, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 8:06 AM Jan Beulich wrote: >> On 28.04.2020 17:00, H.J. Lu wrote: >>> On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper >>> wrote: On 28/04/2020 14:00, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > wrote: >> Hello, >> >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has >> had nothing but tumbleweeds in months, and it is continuing to cause >> problems for Xen. >> >> During the Spectre embargo period, it was specifically identified that >> kernels would need to be able to compile one single binary, which was >> retpoline safe on older hardware, and able to use CET on newer hardware. >> >> thunk-extern was deliberately constructed (along with >> -mindirect-branch-register) such that the thunk could be turned into >> something which wasn't a ROP gadget when hardware was less broken. Both >> Linux and Xen use this, with the ability to substitute the exact thunk >> in use to be suitable for the CPU booted on. (In particular, AMD >> recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) >> >> >> A consequence of GCC rejecting this combination is that Linux has >> unilaterally disabled -fcf-protection >> >> # ensure -fcf-protection is disabled when using retpoline as it is >> # incompatible with -mindirect-branch=thunk-extern >> ifdef CONFIG_RETPOLINE >> KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) >> endif >> >> and a change similar to this is being proposed for Xen. However, doing >> this will leave distros with the choice between disabling retpoline or >> not using CET, which is not in the best security interest of the user. >> >> Please can the original change be partially reverted? thunk-extern >> means "I'm providing the thunks, and I'll take care of ensuring that >> they are appropriate", and that includes not being a ROP gadget when CET >> is active. >> > Please DO disable -fcf-protection in the kernel build. We are enabling > CET for the user space first. The kernel CET will be the next. > > I am enclosing a proposal to make -fcf-protection compatible with > retpoline. > It targets user space. It can be made compatible with kernel. Its fine to focus on userspace first, but the kernel is far more simple. Looking at that presentation, the only thing missing for kernel is the notrack thunks, in the unlikely case that such code would be tolerated (Frankly, I don't expect Xen or Linux to run with notrack enabled, as there is no legacy code to be concerned with). What is going to happen about unbreaking this combination of options? How will we know when kernel mode is supported (not that I can see anything further required from the toolchain)? I really hope you're not >>> My proposal requires assembler, linker and compiler changes. >>> suggesting that we'll need to use something separate such as -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. >>> -mcmodel=kernel should be sufficient. If >>> >>> -mcmodel=kernel -fcf-protection -mindirect-branch=thunk-extern >>> >>> works, your toolchain has implemented my proposal. >> But please note that Xen doesn't get built with -mcmodel=kernel, so >> the two remaining options ought to work together also without this >> one. > Then > > -fcf-protection -mindirect-branch=thunk-extern That's all I was asking for. I understand and completely accept that -fcf-protection and most -mindirect-branch options are incompatible, and rejecting those are reasonable. But by building with thunk-extern, I (the kernel) am taking responsibility for providing suitable thunks. ~Andrew P.S. It is not just Xen. Microkernels don't tend to use -mcmodel=kernel either.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: > Its fine to focus on userspace first, but the kernel is far more simple. > > Looking at that presentation, the only thing missing for kernel is the > notrack thunks, in the unlikely case that such code would be tolerated > (Frankly, I don't expect Xen or Linux to run with notrack enabled, as > there is no legacy code to be concerned with). Uhhh.. ftrace and kretprobes play dodgy games with the return stack, doesn't that make the CET thing slightly more interesting?
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
> On Apr 28, 2020, at 9:14 AM, Peter Zijlstra wrote: > > On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: >> Its fine to focus on userspace first, but the kernel is far more simple. >> >> Looking at that presentation, the only thing missing for kernel is the >> notrack thunks, in the unlikely case that such code would be tolerated >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as >> there is no legacy code to be concerned with). > > Uhhh.. ftrace and kretprobes play dodgy games with the > return stack, doesn't that make the CET thing slightly more interesting? It’s definitely interesting. But there isn’t legacy code involved — we can recompile and fix the world :)
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On Tue, Apr 28, 2020 at 9:33 AM Andy Lutomirski wrote: > > > > > > On Apr 28, 2020, at 9:14 AM, Peter Zijlstra wrote: > > > > On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: > >> Its fine to focus on userspace first, but the kernel is far more simple. > >> > >> Looking at that presentation, the only thing missing for kernel is the > >> notrack thunks, in the unlikely case that such code would be tolerated > >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as > >> there is no legacy code to be concerned with). > > > > Uhhh.. ftrace and kretprobes play dodgy games with the > > return stack, doesn't that make the CET thing slightly more interesting? > > It’s definitely interesting. But there isn’t legacy code involved — we can > recompile and fix the world :) All codes which manually change return address on stack must be updated to also adjust shadow stack. -- H.J.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On 28 April 2020 17:14:49 BST, Peter Zijlstra wrote: >On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: >> Its fine to focus on userspace first, but the kernel is far more >simple. >> >> Looking at that presentation, the only thing missing for kernel is >the >> notrack thunks, in the unlikely case that such code would be >tolerated >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as >> there is no legacy code to be concerned with). > >Uhhh.. ftrace and kretprobes play dodgy games with the >return stack, doesn't that make the CET thing slightly more >interesting? Sure, there is work to do to enable CET. But Andy's point is that we deliberately fixed up retpoline to be register-based *specifically* for the purpose of being CET-compatible, so it's somewhat daft for GCC to be claiming they are incompatible. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
On Tue, Apr 28, 2020 at 10:24 AM David Woodhouse wrote: > > > > On 28 April 2020 17:14:49 BST, Peter Zijlstra wrote: > >On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: > >> Its fine to focus on userspace first, but the kernel is far more > >simple. > >> > >> Looking at that presentation, the only thing missing for kernel is > >the > >> notrack thunks, in the unlikely case that such code would be > >tolerated > >> (Frankly, I don't expect Xen or Linux to run with notrack enabled, as > >> there is no legacy code to be concerned with). > > > >Uhhh.. ftrace and kretprobes play dodgy games with the > >return stack, doesn't that make the CET thing slightly more > >interesting? > > Sure, there is work to do to enable CET. But Andy's point is that we > deliberately fixed up retpoline to be register-based *specifically* for the > purpose of being CET-compatible, so it's somewhat daft for GCC to be claiming > they are incompatible. > GCC needs to be told that external thunk is CET compatible. -- H.J.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
> On Apr 28, 2020, at 10:44 AM, H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 10:24 AM David Woodhouse wrote: >> >> >> >>> On 28 April 2020 17:14:49 BST, Peter Zijlstra wrote: >>> On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: Its fine to focus on userspace first, but the kernel is far more >>> simple. Looking at that presentation, the only thing missing for kernel is >>> the notrack thunks, in the unlikely case that such code would be >>> tolerated (Frankly, I don't expect Xen or Linux to run with notrack enabled, as there is no legacy code to be concerned with). >>> >>> Uhhh.. ftrace and kretprobes play dodgy games with the >>> return stack, doesn't that make the CET thing slightly more >>> interesting? >> >> Sure, there is work to do to enable CET. But Andy's point is that we >> deliberately fixed up retpoline to be register-based *specifically* for the >> purpose of being CET-compatible, so it's somewhat daft for GCC to be >> claiming they are incompatible. >> > > GCC needs to be told that external thunk is CET compatible. If I write: void foo(void); ... foo(); And I compile this with CET enabled, GCC is perfectly willing to assume that foo is CET-compatible. If I compile with stack alignment set unusually high, GCC is fine with assuming that foo will preserve the high alignment. If I compile with unusually low alignment, GCC is fine with assuming that foo will not crash as a result. If I use -mregparm, gcc will happily use it. So why is GCC unwilling to trust that, if I explicitly ask it to call an asm helper that I supply, that I supplied a valid helper? What’s special about CRT? Do we need -fi-know-what-im-doing? Do you have any actual reason to believe that there is even a single user of thunk-extent that might mess up? > > -- > H.J.
Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern
* H. J. Lu via Gcc: > On Tue, Apr 28, 2020 at 10:24 AM David Woodhouse wrote: >> Sure, there is work to do to enable CET. But Andy's point is that >> we deliberately fixed up retpoline to be register-based >> *specifically* for the purpose of being CET-compatible, so it's >> somewhat daft for GCC to be claiming they are incompatible. > > GCC needs to be told that external thunk is CET compatible. Why? Won't the GNU property markup enable consistency checks? So that the CET compatibility check can be deferred to the linking stage?
