linux-kernel - Re: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch

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: <Y+9HOdHGqmPP/Ude@kroah.com>
Date:   Fri, 17 Feb 2023 10:22:01 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Kumaravel.Thiagarajan@...rochip.com
Cc:     srinivas.kandagatla@...aro.org, linux-gpio@...r.kernel.org,
        michael@...le.cc, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, Tharunkumar.Pasumarthi@...rochip.com,
        arnd@...db.de
Subject: Re: [PATCH v5 char-misc-next] misc: microchip: pci1xxxx: Add
 OTP/EEPROM driver for the pci1xxxx switch

On Fri, Feb 17, 2023 at 08:57:32AM +0000, Kumaravel.Thiagarajan@...rochip.com wrote:
> On Thu, 2023-02-16 at 12:49 +0100, Greg KH wrote:
> > > > > > Greg & Michael, I do not want to expose the entire or even
> > > > > > partial
> > > > > > set of device registers to the user space access directly for
> > > > > > safety
> > > > reasons.
> > > > 
> > > > But that's all exposed here through this block device, right?
> > > The block device created by this driver does not expose the device
> > > registers to the user space applications.
> > 
> > What is it exposing?
> The device's OTP and EEPROM are not directly mapped into the
> processor's address space using PCIe's BAR registers.

Ok, that was not obvious and is a lot of the confusion here.

> There is a OTP controller and EEPROM controller in the device and the
> registers of these controllers are mapped into the processor's address
> space along with other registers using the BAR registers.
> OTP/EEPROM driver maps these registers into kernel's virtual space
> using devm_ioremap and accomplishes the reads and writes by accessing
> these registers. To the user side, the driver shows two separate disks
> (one for OTP and one for EEPROM) and both of them could be programmed
> using the "linux dd" command with "oflag=direct" option.
> The driver handles the IO requests that originate out of the dd command
> and this way we would not need a separate user space program also.

I do not recommend using a block interface for this at all.  Why not the
"normal" EEPROM interface that the kernel has today (i.e. a binary sysfs
file)?  That way you can mmap it and edit locations how ever you want.

thanks,

greg k-h