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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d5e3f95-77ce-cd26-9020-3c1a8a65e799@canonical.com>
Date:   Wed, 8 Sep 2021 09:01:23 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Keith Packard <keithpac@...zon.com>, linux-kernel@...r.kernel.org
Cc:     Abbott Liu <liuwenliang@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Christoph Lameter <cl@...ux.com>,
        Dennis Zhou <dennis@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Jens Axboe <axboe@...nel.dk>, Joe Perches <joe@...ches.com>,
        Kees Cook <keescook@...omium.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
        Manivannan Sadhasivam <mani@...nel.org>,
        Marc Zyngier <maz@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Mike Rapoport <rppt@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nick Desaulniers <ndesaulniers@...ogle.com>,
        Nicolas Pitre <nico@...xnic.net>,
        Russell King <linux@...linux.org.uk>,
        Tejun Heo <tj@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Valentin Schneider <valentin.schneider@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "Wolfram Sang (Renesas)" <wsa+renesas@...g-engineering.com>,
        YiFei Zhu <yifeifz2@...inois.edu>
Subject: Re: [PATCH 0/7] ARM: support THREAD_INFO_IN_TASK (v3)

On 08/09/2021 00:00, Keith Packard wrote:
> Placing thread_info in the kernel stack leaves it vulnerable to stack
> overflow attacks. This short series addresses that by using the
> existing THREAD_INFO_IN_TASK infrastructure.
> 
> This is the third version of this series, in this version the changes
> are restricted to hardware which provides the TPIDRPRW register. This
> register is repurposed from holding the per_cpu_offset value to
> holding the 'current' value as that allows fetching this value
> atomically so that it can be used in a preemptable context.
> 
> The series is broken into seven pieces:
> 
>  1) Change the secondary_start_kernel API to receive the cpu
>     number. This avoids needing to be able to find this value independently in
>     future patches.
> 
>  2) Change the secondary_start_kernel API to also receive the 'task'
>     value. Passing the value to this function also avoids needing to
>     be able to discover it independently.
> 
>  3) A cleanup which avoids assuming that THREAD_INFO_IN_TASK is not set.
> 
>  4) A hack, borrowed from the powerpc arch, which allows locating the 'cpu'
>     field in either thread_info or task_struct, without requiring linux/sched.h
>     to be included in asm/smp.h
> 
>  5) Disable the optimization storing per_cpu_offset in TPIDRPRW. This leaves
>     the register free to hold 'current' instead.
> 
>  6) Use TPIDRPRW for 'current'. This is enabled for either CPU_V6K or CPU_V7,
>     but not if CPU_V6 is also enabled.
> 
>  7) Enable THREAD_INFO_IN_TASK whenever TPIDRPRW is used to hold 'current'.

Hi,

Thanks for your patches. This seems to be a v3 but the patches are not
marked with it. Use "-v3" in format-patch to get it right.

The email here also lacks diffstat which is useful, for example to check
whether any maintainer's relevant files are touched here. You can get it
with "--cover-letter".

In total the command should look like:
    git format-patch --cover-letter -v3 -7 HEAD

Of course you can use any other tools to achieve the same result but as
of now - result is not the same.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ