netdev - Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

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]

Date:   Sat, 20 Jan 2018 19:11:22 +0800
From:   Vincent Chen <deanbo422@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
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>,
        Rick Chen <rickchen36@...il.com>,
        Rick Chen <rick@...estech.com>,
        Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

2018-01-18 19:08 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
> On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu <green.hu@...il.com> wrote:
>> From: Rick Chen <rickchen36@...il.com>
>>
>> VDSO needs real-time cycle count to ensure the time accuracy.
>> Unlike others, nds32 architecture does not define clock source,
>> hence VDSO needs atcpit100 offering real-time cycle count
>> to derive the correct time.
>>
>> Signed-off-by: Vincent Chen <vincentc@...estech.com>
>> Signed-off-by: Rick Chen <rickchen36@...il.com>
>> Signed-off-by: Greentime Hu <green.hu@...il.com>
>
> I'm a bit puzzled by this patch, can you explain how the vdso actually
> manages to access the clock hardware? It looks like you make the
> physical address and the register offset available to user space, but
> how does it end up accessing it?
>
>       Arnd

Dear Arnd:

Accessing clock hardware in vdso can be divided to 2 step.

1. Setup an additional memory mapping for clock hardware in user space
when establishing
    vdso-needed memory mapping

        In arch_setup_additional_pages(), kernel establishes memory
mapping for vdso's text and vdata page
    in user space. In order to make clock hardware be accessible in
user space, we try to establish an
    additional memory mapping for clock hardware here based on clock
information from driver. This page is
    located between vdata page and vdso text page. For safety, this
region for clock accessing is read-only.

2. Accessing clock hardware in vdso

        After step 1, clock hardware is accessible in user space
through memory-mapped IO. However, it is not
   enough to access a specific register. Therefore, we store register
offset information in vdata page to make it
   visible in user space.  Now, vdso can derive the address of counter
register by summation of __get_timerpage()
   and counter register offset where __get_timerpage() is used to
derive the virtual address of memory-mapped
   clock.


Vincent