On Fri, Jan 13, 2017 at 04:36:48PM +0800, Herbert Xu wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >
> > I think we have some inline functions that do asm volatile ("call
> > ..."), and I don't see any credible way of forcing alignment short of
> > generating an entire
On Thu, Jan 12, 2017 at 11:07:09PM -0600, Josh Poimboeuf wrote:
>
> Disabling frame pointers didn't seem to help, but I finally got it to
> misalign with a different test case. I think it had been aligning the
> array, so instead I made it push a register.
Right. If you start manipulating the s
On Thu, Jan 12, 2017 at 08:37:18PM -0800, Linus Torvalds wrote:
>
> So then the compiler actually needs to start adding useless instructions
> just to keep the stack 16-byte aligned.
Which it does. Of course most of the time no extra instructions
are required because there are stack variables, so
On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
>
> What I mean is: what guarantees that the stack is properly aligned for
> the subroutine call? gcc promises to set up a stack frame, but does
> it promise that rsp will be properly aligned to call a C function?
Yes, as long as y
On Thu, Jan 12, 2017 at 01:40:54PM -0800, Linus Torvalds wrote:
>
> The 8-byte alignment mainly makes sense when the basic call sequence
> just adds 8 bytes, and you have functions without frames (that still
> call other functions).
The question is does it really make sense to save those 8 bytes
On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>
> I think we have some inline functions that do asm volatile ("call
> ..."), and I don't see any credible way of forcing alignment short of
> generating an entirely new stack frame and aligning that. Ick. This
A straight asm call
On Thu, Jan 12, 2017 at 08:37:18PM -0800, Linus Torvalds wrote:
> On Jan 12, 2017 8:28 PM, "Josh Poimboeuf" wrote:
>
>
> The stack frame was always 16-byte aligned regardless of whether the
> buf array size was even or odd.
>
>
> Including with -fomit-frame-pointer?
>
> With frame pointers, s
On Thu, Jan 12, 2017 at 07:23:18PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf
> >> wrote:
> >> > On Thu, Jan 12, 2017 at 12:08:07
On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
>> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus
On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> >> wrote:
> >> > On Thu, Jan 12, 2017 at 6:02 AM,
On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
>> wrote:
>> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
>> > wrote:
>> >>
>> >> Just to clarify, I think you're a
On Thu, Jan 12, 2017 at 12:55 PM, Josh Poimboeuf wrote:
>
> - Who's going to run sparse all the time to catch unauthorized users of
> __aligned__(16)?
Well, considering that we apparently only have a small handful of
existing users without anybody having ever run any tool at all, I
don't think
On Thu, Jan 12, 2017 at 02:15:11PM -0600, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> > On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> > wrote:
> > > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
> > > wrote:
> > >>
> > >> Just to clarify, I t
On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> wrote:
> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
> >>
> >> Just to clarify, I think you're asking if, for versions of gcc which
> >> don't support -mpreferred-sta
On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
wrote:
> On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
>>
>> Just to clarify, I think you're asking if, for versions of gcc which
>> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
>> functions to ensure their stacks
On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
>
> Just to clarify, I think you're asking if, for versions of gcc which
> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
> functions to ensure their stacks are 16-byte aligned.
>
> It's certainly possible, but I don't s
On Thu, Jan 12, 2017 at 11:06:50PM +0800, Herbert Xu wrote:
> On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
> >
> > For the entry code, could we just replace all calls with CALL_ALIGNED?
> > That might be less intrusive than trying to adjust all the pt_regs
> > accesses.
> >
> >
On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
> > On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
> > wrote:
> > > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> > >>
> > >> I'm pretty sure we have
On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
> wrote:
> > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> >>
> >> I'm pretty sure we have random asm code that may not maintain a
> >> 16-byte stack alignment when i
On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
>
> For the entry code, could we just replace all calls with CALL_ALIGNED?
> That might be less intrusive than trying to adjust all the pt_regs
> accesses.
>
> Then to ensure that nobody ever uses 'call' directly:
>
> '#define cal
On Thu, Jan 12, 2017 at 08:46:01AM +0100, Ingo Molnar wrote:
>
> * Herbert Xu wrote:
>
> > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> > >
> > > I'm pretty sure we have random asm code that may not maintain a
> > > 16-byte stack alignment when it calls other code (including
On Wed, Jan 11, 2017 at 10:21:07PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote:
> > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu
> > wrote:
> >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
> >>>
> >>> That said, I do think that the "
* Herbert Xu wrote:
> > But if we can't do this with automatic verification, then I'm not sure
> > I want to do it at all. The asm is already more precarious than I'd
> > like, and having a code path that is misaligned is asking for obscure
> > bugs down the road.
>
> I understand the need for
On Thu, Jan 12, 2017 at 08:01:51AM +, Ard Biesheuvel wrote:
>
> [From memory] the arm64 ELF psABI mandates a 16 byte stack alignment
> at function entry, and 8 byte alignment at all other times. This means
> compiled code will typically preserve 16 byte alignment, and
> __aligned(16) on a stac
On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
>
> The problem is that we have nasties like TRACE_IRQS_OFF. Performance
I don't understand. What's the issue with TRACE_IRQS_OFF? It should
be treated as any other function call. That is, enter it with an
aligned stack, and the T
On 12 January 2017 at 06:12, Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>>
>> Apologies for introducing this breakage. It seemed like an obvious and
>> simple cleanup, so I didn't even bother to mention it in the commit
>> log, but if the kernel does not gu
On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
wrote:
> On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
>>
>> I'm pretty sure we have random asm code that may not maintain a
>> 16-byte stack alignment when it calls other code (including, in some
>> cases, calling C code).
>>
>> So I'
* Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> >
> > I'm pretty sure we have random asm code that may not maintain a
> > 16-byte stack alignment when it calls other code (including, in some
> > cases, calling C code).
> >
> > So I'm not at all convinced
* Andy Lutomirski wrote:
> I find it rather annoying that gcc before 4.8 malfunctions when it
> sees __aligned__(16) on x86_64 kernels. Sigh.
Ran into this when writing silly FPU in-kernel testcases a couple of months
ago...
Thanks,
Ingo
--
To unsubscribe from this list: send the li
On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
>
> I'm pretty sure we have random asm code that may not maintain a
> 16-byte stack alignment when it calls other code (including, in some
> cases, calling C code).
>
> So I'm not at all convinced that this is a good idea. We shouldn'
On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu
> wrote:
>> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>>
>>> That said, I do think that the "don't assume stack alignment, do it by
>>> hand" may be the safer thing. Beca
On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>
> Apologies for introducing this breakage. It seemed like an obvious and
> simple cleanup, so I didn't even bother to mention it in the commit
> log, but if the kernel does not guarantee 16 byte alignment, I guess
> we should revert
On Wed, Jan 11, 2017 at 12:09 AM, Herbert Xu
wrote:
> On Wed, Jan 11, 2017 at 08:06:54AM +, Ard Biesheuvel wrote:
>>
>> Couldn't we update the __aligned(x) macro to emit 32 if arch == x86
>> and x == 16? All other cases should work just fine afaict
>
> Not everyone uses that macro. You'd also
On Wed, Jan 11, 2017 at 08:06:54AM +, Ard Biesheuvel wrote:
>
> Couldn't we update the __aligned(x) macro to emit 32 if arch == x86
> and x == 16? All other cases should work just fine afaict
Not everyone uses that macro. You'd also need to add some checks
to stop people from using the gcc __
On 11 January 2017 at 06:53, Linus Torvalds
wrote:
>
>
> On Jan 10, 2017 8:36 PM, "Herbert Xu" wrote:
>
>
> Sure we can ban the use of attribute aligned on stacks. But
> what about indirect uses through structures?
>
>
> It should be pretty trivial to add a sparse warning for that, though.
>
Co
On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>>
>> That said, I do think that the "don't assume stack alignment, do it by
>> hand" may be the safer thing. Because who knows what the random rules
>> will be on other architectur
On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
>
> That said, I do think that the "don't assume stack alignment, do it by
> hand" may be the safer thing. Because who knows what the random rules
> will be on other architectures.
Sure we can ban the use of attribute aligned on stack
On Tue, Jan 10, 2017 at 7:30 PM, Linus Torvalds
wrote:
>
> If you really want more stack alignment, you have to generate that
> alignment yourself by hand (and have a bigger buffer that you do that
> alignment inside).
Side note: gcc can (and does) actually generate forced alignment using
"and" i
On Tue, Jan 10, 2017 at 7:11 PM, Herbert Xu wrote:
>
> Well the only other alternative I see is to ban compilers which
> enforce 16-byte stack alignment, such as gcc 4.7.2.
No, you don't have to ban the compiler - it's just a "generate overly
stupid code that just uses extra instructions to like
On Tue, Jan 10, 2017 at 11:22:15AM -0800, Andy Lutomirski wrote:
>
> > Actually, the breakage is introduced by the patch Herbert refers to
> >
> > https://patchwork.kernel.org/patch/9468391/
> >
> > where the state is replaced by a simple
> >
> > u32 state[16] __aligned(CHACHA20_STATE_ALIGN);
> >
>
On Tue, Jan 10, 2017 at 03:25:47PM -0800, Andy Lutomirski wrote:
>
> > If it does what it says on the tin, it should fix the issue, but after
> > adding the attribute, I get the exact same object output, so there's
> > something dodgy going on here.
>
> Ugh, that's annoying. Maybe it needs noinli
On Tue, Jan 10, 2017 at 11:00:31AM -0800, Andy Lutomirski wrote:
>
> Here's what I think is really going on. This is partially from
> memory, so I could be off base. The kernel is up against
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383, which means that,
> on some GCC versions (like the
On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>
> Apologies for introducing this breakage. It seemed like an obvious and
> simple cleanup, so I didn't even bother to mention it in the commit
> log, but if the kernel does not guarantee 16 byte alignment, I guess
> we should revert
On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu
> wrote:
> >
> > BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
> > stack alignment as attempted by the Makefile:
>
> I'm pretty sure we have random asm code that may n
On Tue, Jan 10, 2017 at 12:00 PM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:22, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
wrote:
>
On 10 January 2017 at 19:22, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
> wrote:
>> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>>> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
>>> wrote:
On 10 January 2017 at 14:33, Herbert Xu
wrote:
>
On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 14:33, Herbert Xu wrote:
>> I recently applied the patch
>>
>> https://patchwork.kernel.org/patch/9468391/
>>
>> and ended up with a boot crash when it tried to run the x86 chacha20
>> code. It turned out that
On Tue, Jan 10, 2017 at 11:16 AM, Ard Biesheuvel
wrote:
> On 10 January 2017 at 19:00, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
>> wrote:
>>> On 10 January 2017 at 14:33, Herbert Xu wrote:
I recently applied the patch
https://patchwork.ker
On 10 January 2017 at 19:00, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 9:30 AM, Ard Biesheuvel
> wrote:
>> On 10 January 2017 at 14:33, Herbert Xu wrote:
>>> I recently applied the patch
>>>
>>> https://patchwork.kernel.org/patch/9468391/
>>>
>>> and ended up with a boot crash whe
On 10 January 2017 at 14:33, Herbert Xu wrote:
> I recently applied the patch
>
> https://patchwork.kernel.org/patch/9468391/
>
> and ended up with a boot crash when it tried to run the x86 chacha20
> code. It turned out that the patch changed a manually aligned
> stack buffer to one that
On Tue, Jan 10, 2017 at 9:05 AM, Linus Torvalds
wrote:
> On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu
> wrote:
>>
>> BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
>> stack alignment as attempted by the Makefile:
>
> I'm pretty sure we have random asm code that may not maintain
On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu wrote:
>
> BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte
> stack alignment as attempted by the Makefile:
I'm pretty sure we have random asm code that may not maintain a
16-byte stack alignment when it calls other code (including, in s
On Tue, Jan 10, 2017 at 10:33:40PM +0800, Herbert Xu wrote:
> I recently applied the patch
>
> https://patchwork.kernel.org/patch/9468391/
>
> and ended up with a boot crash when it tried to run the x86 chacha20
> code. It turned out that the patch changed a manually aligned
> stack buffer
I recently applied the patch
https://patchwork.kernel.org/patch/9468391/
and ended up with a boot crash when it tried to run the x86 chacha20
code. It turned out that the patch changed a manually aligned
stack buffer to one that is aligned by gcc. What was happening was
that gcc can sta
54 matches
Mail list logo
