lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mhng-5a2b0379-88e4-43be-8d47-1f019aed05e0@palmer-ri-x1c9a>
Date:   Tue, 29 Nov 2022 19:00:31 -0800 (PST)
From:   Palmer Dabbelt <palmer@...osinc.com>
To:     Khem Raj <raj.khem@...il.com>
CC:     jszhang@...nel.org, guoren@...nel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:     Re: [PATCH 1/2] RISC-V: Align the shadow stack

On Tue, 29 Nov 2022 18:56:48 PST (-0800), Khem Raj wrote:
> On Tue, Nov 29, 2022 at 6:50 PM Palmer Dabbelt <palmer@...osinc.com> wrote:
>>
>> On Tue, 29 Nov 2022 18:47:55 PST (-0800), Khem Raj wrote:
>> > Hi Palmer
>> >
>> > On Tue, Nov 29, 2022 at 6:36 PM Palmer Dabbelt <palmer@...osinc.com> wrote:
>> >>
>> >> The standard RISC-V ABIs all require 16-byte stack alignment.  We're
>> >> only calling that one function on the shadow stack so I doubt it'd
>> >> result in a real issue, but might as well keep this lined up.
>> >
>> > Is 16-byte alignment required on rv32 as well ?
>>
>> For the standard ABIs that's the case, it's so the Q extension can spill
>> without aligning the stack.  There's also at least a proposed embedded
>> ABI that has just XLEN (32-bit on rv32) alignment, as the bigger stack
>> alignment has an impact on some use cases.
>
> Thanks, so in this case 16byte will be valid for both rv64/rv32 here.

Yes, though the long-alignment wouldn't break anything because we don't 
have Q support and we're just calling that one function -- it's not like 
the compiler is actively checking for 16-byte alignment or anything, 
it's just assuming it.

Still best to keep things to the spec where we can, though.

>> >> Fixes: 31da94c25aea ("riscv: add VMAP_STACK overflow detection")
>> >> Signed-off-by: Palmer Dabbelt <palmer@...osinc.com>
>> >> ---
>> >>  arch/riscv/kernel/traps.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
>> >> index be54ccea8c47..acdfcacd7e57 100644
>> >> --- a/arch/riscv/kernel/traps.c
>> >> +++ b/arch/riscv/kernel/traps.c
>> >> @@ -206,7 +206,7 @@ static DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)],
>> >>   * shadow stack, handled_ kernel_ stack_ overflow(in kernel/entry.S) is used
>> >>   * to get per-cpu overflow stack(get_overflow_stack).
>> >>   */
>> >> -long shadow_stack[SHADOW_OVERFLOW_STACK_SIZE/sizeof(long)];
>> >> +long shadow_stack[SHADOW_OVERFLOW_STACK_SIZE/sizeof(long)] __aligned(16);
>> >>  asmlinkage unsigned long get_overflow_stack(void)
>> >>  {
>> >>         return (unsigned long)this_cpu_ptr(overflow_stack) +
>> >> --
>> >> 2.38.1
>> >>
>> >>
>> >> _______________________________________________
>> >> linux-riscv mailing list
>> >> linux-riscv@...ts.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ