linux-kernel - Re: [PATCH v2] nvmem: core: Set no-read-write provider to avoid userspace read/write

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]

Date:   Thu, 21 Mar 2019 14:14:26 +0100
From:   Marc Gonzalez <marc.w.gonzalez@...e.fr>
To:     Gaurav Kohli <gkohli@...eaurora.org>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v2] nvmem: core: Set no-read-write provider to avoid
 userspace read/write

On 20/03/2019 18:50, Gaurav Kohli wrote:

> On 3/20/2019 9:56 PM, Srinivas Kandagatla wrote:
> 
>> Am guessing these are some kind of keys or something that you do not 
>> want user to see.
> 
> Yes exactly, there are certain keys or even certain bit that we don't 
> want to expose to user.
> 
>> Is root only option not helping you in this case?
>
> Yes we want to protect at root level as well, I mean it is better if we 
> can avoid exposing to userspace at all.

NB: root has access to /dev/mem and /dev/kmem (and probably other ways
into the kernel)

>> We could go down the route of adding new config option something like 
>> CONFIG_NVMEM_NO_SYSFS_ENTRY to prevent adding nvmem entry in userspace.
>>
>> Let me know if you are happy to create a patch for this change?
> 
> I am happy with either way, config option or DT binding (seems easy),
> please let me know we will post new patch for the same.

Device tree nodes are supposed to be hardware descriptions. Obviously,
implementing security policies such as "hide this information from
user-space" is not a good fit for a DT node.

The qcom kernel is full of "config knobs" in DT nodes. It would be good
if you could spread the word, and slowly turn things around :-)

Regards.