linux-kernel - Re: [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules

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: <53AF2A83.8040003@ahsoftware.de>
Date:	Sat, 28 Jun 2014 22:50:11 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Marc Dietrich <marvin24@....de>
CC:	John Stultz <john.stultz@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	John Whitmore <arigead@...il.com>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules

Am 28.06.2014 20:54, schrieb Marc Dietrich:
> On Sat, 28 Jun 2014 09:32:50 +0200
> Alexander Holler <holler@...oftware.de> wrote:
>
>> Am 28.06.2014 09:18, schrieb Alexander Holler:
>>> Am 27.06.2014 19:27, schrieb John Stultz:
>>>> Its been pointed out that the RTC hctosys functionality doesn't
>>>> work well with RTC modules, which may not be loaded until after
>>>> late_init().
>>>>
>>>> While there have been other attempts to sovle this, this patchset
>>>> is a very quick 10 minute effort to show how I'd try to resolve
>>>> this. There likely are still issues here, but I'd be happy to
>>>> make fixes and adjustments to ensure it works.
>>
>> How long you needed to getthe idea?
>>
>>>>
>>>> Feedback and comments always appreciated!
>>>
>>> And it still uses the non-deterministic and therefor almost unusable
>>> rtcN. Well done.
>>
>> Besides that the current hctosys-mechanism doesn't really work with
>> hot-plugable devices at all. Guess what N will be when you unplug and
>> plug in such a RTC again.
>
> We have a patch in the kernel which binds the rtc number to the
> hw device, so this even works for hotpluggable devices (at least on
> systems supporting device-tree). Not sure what your needs are.

First, the number depends on the kernel-configuration and the order how 
RTCs are detected and might even change between minor kernel versions. 
Thus it's totally non-deterministic across different kernel builds.

Second, I wonder about which hotpluggable devices you are talking. Last 
time I've dived into that part of the kernel was when I've written my 
fully working patch set and at that time a usb-rtc (the only really 
hotpluggable RTC I currently know about) did get a new N whenever it 
appeared again (e.g. on suspend/resume). So with the proposed 
non-working clone of my patch, the RTC would be gone after a resume.

Anyway, sorry, I won't spend more time on discussing with kernel 
maintainers. I don't receive any compensations to do so and therefor I 
absolutely have no reason to accept all the pain and insults which are 
happening when doing so. I've come to the conclusion that I should not 
have posted patches at all (not just this one) and really regret that.

Alexander Holler
--
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/