linux-kernel - Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

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: <20150911020555.GB15719@roeck-us.net>
Date:	Thu, 10 Sep 2015 19:05:55 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Jon Masters <jcm@...hat.com>
Cc:	fu.wei@...aro.org, Suravee.Suthikulpanit@....com,
	hanjun.guo@...aro.org, linaro-acpi@...ts.linaro.org,
	linux-watchdog@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	tekkamanninja@...il.com, graeme.gregory@...aro.org,
	al.stone@...aro.org, arnd@...db.de, vgandhi@...eaurora.org,
	wim@...ana.be, leo.duran@....com, corbet@....net,
	mark.rutland@....com, catalin.marinas@....com, will.deacon@....com,
	rjw@...ysocki.net, dyoung@...hat.com, panand@...hat.com
Subject: Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

On Thu, Sep 10, 2015 at 06:29:53PM -0400, Jon Masters wrote:
> On 08/24/2015 01:01 PM, fu.wei@...aro.org wrote:
> 
> > +	/*
> > +	 * Get the frequency of system counter from the cp15 interface of ARM
> > +	 * Generic timer. We don't need to check it, because if it returns "0",
> > +	 * system would panic in very early stage.
> > +	 */
> > +	gwdt->clk = arch_timer_get_cntfrq();
> 
> Just thinking out loud...
> 
> What happens later if we virtualize this device within KVM/QEMU/Xen and
> then live migrate to another system in which the frequency changes?
> 
I don't know, but I would suspect that we might end up in all kinds of
trouble if clocks can change like that, and not just in this driver.
Many drivers make the assumption that clock rates are not changed
under the hood. If it can happen, shouldn't there be a callback into
the drivers using the affected clock(s) ?

Also, it seems to me that changing a clock like that would be inherently
unsafe. For example, what will happen if the system is stopped and migrated
right after the clock frequency is read, but before the returned value
is used ? Can that happen ? Or does it only happen during suspend/resume
cycles, if it happens ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/