netdev - Re: [PATCH v6 07/36] nds32: Exception handling

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]

Date:   Wed, 24 Jan 2018 12:09:02 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Vincent Chen <deanbo422@...il.com>
Cc:     Greentime Hu <green.hu@...il.com>,
        Greentime <greentime@...estech.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Networking <netdev@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-serial@...r.kernel.org,
        Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>, Greg KH <greg@...ah.com>,
        Guo Ren <ren_guo@...ky.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        David Miller <davem@...emloft.net>,
        Jonas Bonn <jonas@...thpole.se>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        Stafford Horne <shorne@...il.com>,
        Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v6 07/36] nds32: Exception handling

On Wed, Jan 24, 2018 at 11:53 AM, Vincent Chen <deanbo422@...il.com> wrote:
> 2018-01-18 18:14 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@...il.com> wrote:
>>> From: Greentime Hu <greentime@...estech.com>
>>>
>>> This patch includes the exception/interrupt entries, pt_reg structure and
>>> related accessors.
>>>
>>> Signed-off-by: Vincent Chen <vincentc@...estech.com>
>>> Signed-off-by: Greentime Hu <greentime@...estech.com>
>>
>> Here it would be good to have a more detailed explanation about the alignment
>> trap handling. I remember discussing it with you before, but don't remember
>> the exact outcome. In particular you should explain here why you need to
>> handle alignment traps in the first place, and what the expected defaults
>> are (e.g. always disabled unless a user requests it, or always enabled) and
>> what kind of code runs into the traps (e.g. buggy kernel code, correct
>> kernel code, buggy user space code etc).
>>
>>        Arnd
>
>
> Dear Arnd:
>
> I am plans to add the following description in the git commit's comment
>
> Andes processors cannot load/store information which is not naturally aligned
> on the bus, i.e., loading a 4 byte data whose start address must be divisible
> by 4. If unaligned data accessing is happened, data unaligned exception will be
> triggered and user will get SIGSEGV or kernel oops according to the unaligned
> address. In order to make user able to load/store data from an unaligned
> address, software load /store emulation is implemented in
> arch/nds32/mm/alignment.c to handle data unaligned exception.
>
> Unaligned accessing handling is disable by default because of it is not
> a normal case. User can follow the steps below to enable this feature.
>
> A. Compile time:
>     1. Enable kernel config CONFIG_ALIGNMENT_TRAP
> B. Run time:
>     1. Enter /proc/sys/nds32/unaligned_acess folder
>     2.
>         a. Write ‘1’ to file enable_mode to enable unaligned accessing handling
>             for user space
>         b. Write ‘2’ to file enable_mode to enable unaligned accessing handling
>             for kernel space
>         c. Write ‘3’ to file enable_mode to enable unaligned accessing handling
>             for user and kernel space
>         d. Write '0' to file enable_mode to disable all unaligned
> accessing handling
>     3.
>         a. Write ‘1’ to file debug to show which unaligned address is addressed
>         b. Write ‘0’ to file debug to disable all information
>
> However, unaligned accessing handler can’t work on following conditions.
> A. The corresponding mode for unaligned address is not enabled.
> B. This unaligned address is not accessible such as protection violation.
> On these conditions, the default behaviors for data unaligned
> exception still happen.

Ok. I still wonder about the kernel part of this though: is it a good idea
for user space to configure whether the kernel does unaligned
accesses? I would think that the kernel should just be fixed in such
a case.

     Arnd