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: <20201106075908.GJ1034841@piout.net>
Date:   Fri, 6 Nov 2020 08:59:08 +0100
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Claudius Heine <ch@...x.de>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Johannes Hahn <johannes-hahn@...mens.com>,
        werner.zeh@...mens.com
Subject: Re: [PATCH 0/2]  Adding I2C support to RX6110 RTC

On 06/11/2020 08:40:34+0100, Henning Schild wrote:
> Hi,
> 
> Am Thu, 5 Nov 2020 23:14:51 +0100
> schrieb Alexandre Belloni <alexandre.belloni@...tlin.com>:
> 
> > Hello Claudius!
> > 
> > It has been a while ;)
> > 
> > On 04/11/2020 11:26:27+0100, Claudius Heine wrote:
> > > Hi,
> > > 
> > > this patch introduces I2C support to the RX6110 RTC driver and also
> > > adds an ACPI identifier to it.
> > > 
> > > Since we are also pushing the coreboot changes for the ACPI table
> > > upstream in parallel, we are free to name this ACPI entry however we
> > > like it seems. So any feedback on that would be welcome ;)
> > >   
> > 
> > I don't care too much about ACPI so if you are really looking for
> > advice there, I guess you should ask seom of the ACPI guys (but I
> > guess you are free to choose whatever you want).
> > 
> 
> This is the coreboot stuff currently under review.
> 
> https://review.coreboot.org/c/coreboot/+/47235
> 

I can't really comment on the patch, however another part is worrying:
if VLF is set, coreboot is resetting the time to a valid value (user
defined or the build date). This is nasty because this hides the event
from the kernel and ulimately, userspace has no way of knowing whether
the RTC date is the real date or just a dummy date.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ