linux-kernel - Re: [PATCH] rtc: sun6i: Add NVMEM provider

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] [day] [month] [year] [list]

Message-ID: <70366b7a-f8e2-abaf-682b-998094095f59@sholland.org>
Date:   Wed, 26 May 2021 23:09:09 -0500
From:   Samuel Holland <samuel@...lland.org>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        linux-rtc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider


On 5/25/21 3:24 AM, Maxime Ripard wrote:
> On Sun, May 09, 2021 at 10:39:30PM -0500, Samuel Holland wrote:
>> On 4/30/21 4:02 AM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote:
>>>> The sun6i RTC provides 32 bytes of general-purpose data registers.
>>>> They can be used to save data in the always-on RTC power domain.
>>>> The registers are writable via 32-bit MMIO accesses only.
>>>>
>>>> Expose the region as a NVMEM provider so it can be used by userspace and
>>>> other drivers.
>>>>
>>>> Signed-off-by: Samuel Holland <samuel@...lland.org>
>>>
>>> As far as I understood, you want to use those registers to implement
>>> super-standby? If so, while it makes sense for the kernel to be able to
>>> be able to write to those registers, I guess it would be a bit unwise to
>>> allow the userspace to access it?
>>
>> I want the user to be able to pass information to the bootloader (to
>> select a boot device, e.g. reboot to FEL). I also want the user to be
>> able to read data stored to these registers by system firmware (e.g.
>> crust writes exception information there). It's not really related to
>> standby.
> 
> What information do you want to provide? This looks like punching
> through the abstraction layer provided by the kernel.

I don't see how registering an NVMEM provider is punching through any
abstraction layer. NVMEM _is_ the relevant abstraction layer provided by
the kernel. What else would you suggest I use?

> This is also an issue since it ties an ABI to the use of crust: if
> there's another user for those RTC registers at some point, the
> userspace would have no way to tell whether or not crust is being
> used and might get complete garbage (compared to what crust usually
> provides) instead.

If the user chooses to interact with the NVMEM via sysfs, then the user
has to deal with the consequences. This is equivalent to the user's
responsibility when using, for example, /dev/mem or libusb.

For the purpose of providing the abstraction, the actual data stored
there is irrelevant. And if you want to partition up the registers to
reserve for different users, that is what NVMEM cells accomplish.

>> I would want to stack a nvmem-reboot-mode on top to give friendlier
>> names to some of the numbers, but I don't see a problem with root having
>> direct access to the registers. It's no different from /dev/nvram
>> providing access to the PC CMOS RAM.
> 
> And those solutions have issues too. efivarfs for example can totally
> brick the system it runs on if the user has an unfortunate rm -rf.

The sun6i RTC, like PC CMOS, is battery-backed RAM. efivarfs writes to
flash. The magnitude of any such "danger" is vastly different between
the two. (And I think we can do better than vendors who release those
brickable EFI implementations.)

Regards,
Samuel