Re: [PATCH] x86: pad assembly functions with INT3
On May 14, 2018 11:54:05 PM PDT, Ingo Molnarwrote: > >* h...@zytor.com wrote: > >> > I guess it won't try to speculatively execute the 'pad' >instructions - but you >> > can never really tell! >> > >> >David >> >> The CPU doesn't speculate down past an unconditional control >transfer. Doing so >> would be idiotic. > >I think, when it comes to speculative execution, our general >expectation that CPUs >don't do idiotic things got somewhat weakened in the past year or so >... > >Thanks, > > Ingo Sort-of-kind-of... the things that have cropped up were reasonable consequences of designing under a set of assumptions which turned out to be incorrect. Speculating through an unconditional control transfer did not make sense under those assumptions either. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] x86: pad assembly functions with INT3
On May 14, 2018 11:54:05 PM PDT, Ingo Molnar wrote: > >* h...@zytor.com wrote: > >> > I guess it won't try to speculatively execute the 'pad' >instructions - but you >> > can never really tell! >> > >> >David >> >> The CPU doesn't speculate down past an unconditional control >transfer. Doing so >> would be idiotic. > >I think, when it comes to speculative execution, our general >expectation that CPUs >don't do idiotic things got somewhat weakened in the past year or so >... > >Thanks, > > Ingo Sort-of-kind-of... the things that have cropped up were reasonable consequences of designing under a set of assumptions which turned out to be incorrect. Speculating through an unconditional control transfer did not make sense under those assumptions either. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] x86: pad assembly functions with INT3
* h...@zytor.comwrote: > > I guess it won't try to speculatively execute the 'pad' instructions - but > > you > > can never really tell! > > > > David > > The CPU doesn't speculate down past an unconditional control transfer. Doing > so > would be idiotic. I think, when it comes to speculative execution, our general expectation that CPUs don't do idiotic things got somewhat weakened in the past year or so ... Thanks, Ingo
Re: [PATCH] x86: pad assembly functions with INT3
* h...@zytor.com wrote: > > I guess it won't try to speculatively execute the 'pad' instructions - but > > you > > can never really tell! > > > > David > > The CPU doesn't speculate down past an unconditional control transfer. Doing > so > would be idiotic. I think, when it comes to speculative execution, our general expectation that CPUs don't do idiotic things got somewhat weakened in the past year or so ... Thanks, Ingo
RE: [PATCH] x86: pad assembly functions with INT3
On May 14, 2018 2:04:38 AM PDT, David Laightwrote: >From: H. Peter Anvin >> Sent: 11 May 2018 19:54 >> >> On 05/10/18 09:39, David Laight wrote: >> > From: Alexey Dobriyan >> >> Sent: 07 May 2018 22:38 >> >> >> >> Use INT3 instead of NOP. All that padding between functions is >> >> an illegal area, no legitimate code should jump into it. >> >> >> >> I've checked x86_64 allyesconfig disassembly, all changes looks >sane: >> >> INT3 is only used after RET or unconditional JMP. >> > >> > I thought there was a performance penalty (on at least some cpu) >> > depending on the number of and the actual instructions used for >padding. >> > >> > I believe that is why gcc generates a small number of very long >'nop' >> > instructions when padding code. >> > >> >> There is a performance penalty for using NOP instructions *in the >> fallthrough case.* In the case where the padding is never supposed >to >> be executed, which is what we're talking about here, it is >irrelevant. > >Not completely irrelevant, the instructions stream gets fetched and >decoded >beyond the jmp/ret at the end of the function. >At some point the cpu will decode the jmp/ret and fetch/decode from the >target address. >I guess it won't try to speculatively execute the 'pad' instructions >- but you can never really tell! > > David The CPU doesn't speculate down past an unconditional control transfer. Doing so would be idiotic. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
RE: [PATCH] x86: pad assembly functions with INT3
On May 14, 2018 2:04:38 AM PDT, David Laight wrote: >From: H. Peter Anvin >> Sent: 11 May 2018 19:54 >> >> On 05/10/18 09:39, David Laight wrote: >> > From: Alexey Dobriyan >> >> Sent: 07 May 2018 22:38 >> >> >> >> Use INT3 instead of NOP. All that padding between functions is >> >> an illegal area, no legitimate code should jump into it. >> >> >> >> I've checked x86_64 allyesconfig disassembly, all changes looks >sane: >> >> INT3 is only used after RET or unconditional JMP. >> > >> > I thought there was a performance penalty (on at least some cpu) >> > depending on the number of and the actual instructions used for >padding. >> > >> > I believe that is why gcc generates a small number of very long >'nop' >> > instructions when padding code. >> > >> >> There is a performance penalty for using NOP instructions *in the >> fallthrough case.* In the case where the padding is never supposed >to >> be executed, which is what we're talking about here, it is >irrelevant. > >Not completely irrelevant, the instructions stream gets fetched and >decoded >beyond the jmp/ret at the end of the function. >At some point the cpu will decode the jmp/ret and fetch/decode from the >target address. >I guess it won't try to speculatively execute the 'pad' instructions >- but you can never really tell! > > David The CPU doesn't speculate down past an unconditional control transfer. Doing so would be idiotic. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
RE: [PATCH] x86: pad assembly functions with INT3
From: H. Peter Anvin > Sent: 11 May 2018 19:54 > > On 05/10/18 09:39, David Laight wrote: > > From: Alexey Dobriyan > >> Sent: 07 May 2018 22:38 > >> > >> Use INT3 instead of NOP. All that padding between functions is > >> an illegal area, no legitimate code should jump into it. > >> > >> I've checked x86_64 allyesconfig disassembly, all changes looks sane: > >> INT3 is only used after RET or unconditional JMP. > > > > I thought there was a performance penalty (on at least some cpu) > > depending on the number of and the actual instructions used for padding. > > > > I believe that is why gcc generates a small number of very long 'nop' > > instructions when padding code. > > > > There is a performance penalty for using NOP instructions *in the > fallthrough case.* In the case where the padding is never supposed to > be executed, which is what we're talking about here, it is irrelevant. Not completely irrelevant, the instructions stream gets fetched and decoded beyond the jmp/ret at the end of the function. At some point the cpu will decode the jmp/ret and fetch/decode from the target address. I guess it won't try to speculatively execute the 'pad' instructions - but you can never really tell! David
RE: [PATCH] x86: pad assembly functions with INT3
From: H. Peter Anvin > Sent: 11 May 2018 19:54 > > On 05/10/18 09:39, David Laight wrote: > > From: Alexey Dobriyan > >> Sent: 07 May 2018 22:38 > >> > >> Use INT3 instead of NOP. All that padding between functions is > >> an illegal area, no legitimate code should jump into it. > >> > >> I've checked x86_64 allyesconfig disassembly, all changes looks sane: > >> INT3 is only used after RET or unconditional JMP. > > > > I thought there was a performance penalty (on at least some cpu) > > depending on the number of and the actual instructions used for padding. > > > > I believe that is why gcc generates a small number of very long 'nop' > > instructions when padding code. > > > > There is a performance penalty for using NOP instructions *in the > fallthrough case.* In the case where the padding is never supposed to > be executed, which is what we're talking about here, it is irrelevant. Not completely irrelevant, the instructions stream gets fetched and decoded beyond the jmp/ret at the end of the function. At some point the cpu will decode the jmp/ret and fetch/decode from the target address. I guess it won't try to speculatively execute the 'pad' instructions - but you can never really tell! David
Re: [PATCH] x86: pad assembly functions with INT3
On 05/10/18 09:39, David Laight wrote: > From: Alexey Dobriyan >> Sent: 07 May 2018 22:38 >> >> Use INT3 instead of NOP. All that padding between functions is >> an illegal area, no legitimate code should jump into it. >> >> I've checked x86_64 allyesconfig disassembly, all changes looks sane: >> INT3 is only used after RET or unconditional JMP. > > I thought there was a performance penalty (on at least some cpu) > depending on the number of and the actual instructions used for padding. > > I believe that is why gcc generates a small number of very long 'nop' > instructions when padding code. > There is a performance penalty for using NOP instructions *in the fallthrough case.* In the case where the padding is never supposed to be executed, which is what we're talking about here, it is irrelevant. I thought I had filed a gcc enhancement request, but I can't find it now, so I just filed this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85751 -hpa
Re: [PATCH] x86: pad assembly functions with INT3
On 05/10/18 09:39, David Laight wrote: > From: Alexey Dobriyan >> Sent: 07 May 2018 22:38 >> >> Use INT3 instead of NOP. All that padding between functions is >> an illegal area, no legitimate code should jump into it. >> >> I've checked x86_64 allyesconfig disassembly, all changes looks sane: >> INT3 is only used after RET or unconditional JMP. > > I thought there was a performance penalty (on at least some cpu) > depending on the number of and the actual instructions used for padding. > > I believe that is why gcc generates a small number of very long 'nop' > instructions when padding code. > There is a performance penalty for using NOP instructions *in the fallthrough case.* In the case where the padding is never supposed to be executed, which is what we're talking about here, it is irrelevant. I thought I had filed a gcc enhancement request, but I can't find it now, so I just filed this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85751 -hpa
RE: [PATCH] x86: pad assembly functions with INT3
From: Alexey Dobriyan > Sent: 07 May 2018 22:38 > > Use INT3 instead of NOP. All that padding between functions is > an illegal area, no legitimate code should jump into it. > > I've checked x86_64 allyesconfig disassembly, all changes looks sane: > INT3 is only used after RET or unconditional JMP. I thought there was a performance penalty (on at least some cpu) depending on the number of and the actual instructions used for padding. I believe that is why gcc generates a small number of very long 'nop' instructions when padding code. David
RE: [PATCH] x86: pad assembly functions with INT3
From: Alexey Dobriyan > Sent: 07 May 2018 22:38 > > Use INT3 instead of NOP. All that padding between functions is > an illegal area, no legitimate code should jump into it. > > I've checked x86_64 allyesconfig disassembly, all changes looks sane: > INT3 is only used after RET or unconditional JMP. I thought there was a performance penalty (on at least some cpu) depending on the number of and the actual instructions used for padding. I believe that is why gcc generates a small number of very long 'nop' instructions when padding code. David
Re: [PATCH] x86: pad assembly functions with INT3
On 05/09/18 09:55, Alexey Dobriyan wrote: > On Mon, May 07, 2018 at 02:41:14PM -0700, h...@zytor.com wrote: >>> -#define __ALIGN.p2align 4, 0x90 >>> +#define __ALIGN.p2align 4, 0xCC >> >> Acked-by: H. Peter Anvin> > Thanks! > > If someone knows how to control _compiler_ inter-function padding, > please tell. > I think I have a gcc feature enhancement request for that. It can't be done without gcc's knowledge of when a fallthrough is happening (I presume you took that into account in your patch set.) -hpa
Re: [PATCH] x86: pad assembly functions with INT3
On 05/09/18 09:55, Alexey Dobriyan wrote: > On Mon, May 07, 2018 at 02:41:14PM -0700, h...@zytor.com wrote: >>> -#define __ALIGN.p2align 4, 0x90 >>> +#define __ALIGN.p2align 4, 0xCC >> >> Acked-by: H. Peter Anvin > > Thanks! > > If someone knows how to control _compiler_ inter-function padding, > please tell. > I think I have a gcc feature enhancement request for that. It can't be done without gcc's knowledge of when a fallthrough is happening (I presume you took that into account in your patch set.) -hpa
Re: [PATCH] x86: pad assembly functions with INT3
On Mon, May 07, 2018 at 02:41:14PM -0700, h...@zytor.com wrote: > >-#define __ALIGN .p2align 4, 0x90 > >+#define __ALIGN .p2align 4, 0xCC > > Acked-by: H. Peter AnvinThanks! If someone knows how to control _compiler_ inter-function padding, please tell.
Re: [PATCH] x86: pad assembly functions with INT3
On Mon, May 07, 2018 at 02:41:14PM -0700, h...@zytor.com wrote: > >-#define __ALIGN .p2align 4, 0x90 > >+#define __ALIGN .p2align 4, 0xCC > > Acked-by: H. Peter Anvin Thanks! If someone knows how to control _compiler_ inter-function padding, please tell.
Re: [PATCH] x86: pad assembly functions with INT3
On May 7, 2018 2:37:55 PM PDT, Alexey Dobriyanwrote: >Use INT3 instead of NOP. All that padding between functions is >an illegal area, no legitimate code should jump into it. > >I've checked x86_64 allyesconfig disassembly, all changes looks sane: >INT3 is only used after RET or unconditional JMP. > >Signed-off-by: Alexey Dobriyan >--- > > arch/x86/include/asm/linkage.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >--- a/arch/x86/include/asm/linkage.h >+++ b/arch/x86/include/asm/linkage.h >@@ -18,7 +18,7 @@ > name: > > #if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16) >-#define __ALIGN .p2align 4, 0x90 >+#define __ALIGN .p2align 4, 0xCC > #define __ALIGN_STR __stringify(__ALIGN) > #endif > Acked-by: H. Peter Anvin -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] x86: pad assembly functions with INT3
On May 7, 2018 2:37:55 PM PDT, Alexey Dobriyan wrote: >Use INT3 instead of NOP. All that padding between functions is >an illegal area, no legitimate code should jump into it. > >I've checked x86_64 allyesconfig disassembly, all changes looks sane: >INT3 is only used after RET or unconditional JMP. > >Signed-off-by: Alexey Dobriyan >--- > > arch/x86/include/asm/linkage.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >--- a/arch/x86/include/asm/linkage.h >+++ b/arch/x86/include/asm/linkage.h >@@ -18,7 +18,7 @@ > name: > > #if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16) >-#define __ALIGN .p2align 4, 0x90 >+#define __ALIGN .p2align 4, 0xCC > #define __ALIGN_STR __stringify(__ALIGN) > #endif > Acked-by: H. Peter Anvin -- Sent from my Android device with K-9 Mail. Please excuse my brevity.