linux-kernel - Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

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: <CADyBb7uqomC10mR4oMcUKrvYCbrOfLB6q1T6feMfiYA4cMnduA@mail.gmail.com>
Date:   Wed, 1 Feb 2017 02:43:02 +0800
From:   Fu Wei <fu.wei@...aro.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <marc.zyngier@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        Linaro ACPI Mailman List <linaro-acpi@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        rruigrok@...eaurora.org, "Abdulhamid, Harb" <harba@...eaurora.org>,
        Christopher Covington <cov@...eaurora.org>,
        Timur Tabi <timur@...eaurora.org>,
        G Gregory <graeme.gregory@...aro.org>,
        Al Stone <al.stone@...aro.org>, Jon Masters <jcm@...hat.com>,
        Wei Huang <wei@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
        Leo Duran <leo.duran@....com>,
        Wim Van Sebroeck <wim@...ana.be>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-watchdog@...r.kernel.org, Tomasz Nowicki <tn@...ihalf.com>,
        Christoffer Dall <christoffer.dall@...aro.org>,
        Julien Grall <julien.grall@....com>
Subject: Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework
 counter frequency detection.

Hi Mark,

On 31 January 2017 at 01:49, Mark Rutland <mark.rutland@....com> wrote:
> On Thu, Jan 26, 2017 at 01:49:03PM +0800, Fu Wei wrote:
>> On 26 January 2017 at 01:25, Mark Rutland <mark.rutland@....com> wrote:
>> > On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
>> >> On 25 January 2017 at 01:24, Mark Rutland <mark.rutland@....com> wrote:
>> >> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei@...aro.org wrote:
>> >> >> From: Fu Wei <fu.wei@...aro.org>
>
>> > For CNT{,EL0}BaseN.CNTFRQ, I am very concerned by the wording in the
>> > current ARMv8 ARM ARM. This does not match my understanding, nor does it
>> > match the description in the ARMv7 ARM. I believe this may be a
>> > documentation error, and I'm chasing that up internally.
>> >
>> > Either the currently logic in the driver which attempts to read
>> > CNT{,EL0}BaseN.CNTFRQ is flawed, or the description in the ARM ARM is
>> > erroneous.
>>
>> Yes, those description did confuse me. :-(
>>
>> But according to another document(ARMv8-A Foundation Platform User
>> Guide  ARM DUI0677K),
>> Table 3-2 ARMv8-A Foundation Platform memory map (continued)
>>
>> AP_REFCLK CNTBase0, Generic Timer 64KB   S
>> AP_REFCLK CNTBase1, Generic Timer 64KB   S/NS
>>
>> Dose it means the timer frame 0 can be accessed in SECURE status  only,
>> and the timer frame 1 can be accessed in both status?
>
> That does appear to be what it says.
>
> I assume in this case CNTCTLBase.CNTSAR<0> is RES0.
>
>> And because Linux kernel is running on Non-secure EL1, so should we
>> skip "SECURE" timer in Linux?
>
> I guess you mean by checking the GTx Common flags, to see if the timer
> is secure? Yes, we must skip those.

Yes, exactly.

I think we can check the  GTx Common flags, if the timer is set as
SECURE, this driver should just skip this timer.

Reason:
1, IF the timer is designed to be a secure timer which is only can be
accessed in secure status, the ACPI table should label this as SECURE,
then driver should skip it.
2, IF the timer is accessible from both status, but the firmware want
to use this driver for secure OS,  the ACPI table should also label
this as SECURE(meanwhile firmware should configure CNTSAR too), then
driver should skip it, too.

Actually I have added this into my next patchset v21. If you don't
have other suggestion I can post it tomorrow.

Can I? any thought?

>
> Looking further at this, the ACPI spec is sorely lacking any statement
> as to the configuration of CNTCTLBase.{CNTSAR,CNTTIDR,CNTACR}, so it's
> not clear if we can access anything in a frame, even if it is listed as
> being a non-secure timer.
>
> I think we need a stronger statement here. Otherwise, we will encounter
> problems. Linux currently assumes that CNTCTLBase.CNTACR<N> is
> writeable, given a non-secure frame N. This is only the case if
> CNTCTLBase.CNTSAR.NS<N> == 1.

the original driver has checked these registers, but the problem is:
What if the timer frame is designed to be a secure timer, all the
register in this frame is only can be accessed in secure status, just
like foundation model?
Note: for foundation model, Please check Table 3-1 Access permissions
of 3.1 ARMv8-A Foundation Platform memory map in ARMv8-A Foundation
Platform User Guide

So I think we should check the GTDT first, if it's not a secure timer,
then we can go on checking CNTSAR. :-)

Please correct me, If I miss something. :-)

Great thanks for your info :-)

>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat