Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200407082923.2001556-1-patrick.rudolph@9elements.com>
 <20200407082923.2001556-2-patrick.rudolph@9elements.com> <159306873839.62212.9311861115757727633@swboyd.mtv.corp.google.com>
In-Reply-To: <159306873839.62212.9311861115757727633@swboyd.mtv.corp.google.com>
From:   Julius Werner <jwerner@chromium.org>
Date:   Thu, 25 Jun 2020 13:51:34 -0700
Message-ID: <CAODwPW9Gp+sjt7hdTrDmU-KnfpbXNkuQL52+v_FxwSzSSTH_yg@mail.gmail.com>
Subject: Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs
To:     Stephen Boyd <swboyd@chromium.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Patrick Rudolph <patrick.rudolph@9elements.com>,
        Coreboot <coreboot@coreboot.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Alexios Zavras <alexios.zavras@intel.com>,
        Allison Randal <allison@lohutok.net>,
        Julius Werner <jwerner@chromium.org>,
        Samuel Holland <samuel@sholland.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> > +What:          /sys/bus/coreboot/devices/.../cbmem_attributes/address
> > +Date:          Apr 2020
> > +KernelVersion: 5.6
> > +Contact:       Patrick Rudolph <patrick.rudolph@9elements.com>
> > +Description:
> > +               coreboot device directory can contain a file named
> > +               cbmem_attributes/address if the device corresponds to a CBMEM
> > +               buffer.
> > +               The file holds an ASCII representation of the physical address
> > +               of the CBMEM buffer in hex (e.g. 0x000000008000d000) and should
> > +               be used for debugging only.
>
> If this is for debugging purposes only perhaps it should go into
> debugfs. We try to not leak information about physical addresses to
> userspace and this would let an attacker understand where memory may be.
> That's not ideal and should be avoided.

This is memory allocated by firmware and not subject to (k)ASLR, so
nothing valuable can be leaked here. The same addresses could already
be parsed out of /sys/firmware/log. Before this interface we usually
accessed this stuff via /dev/mem (and tools that want to remain
backwards-compatible will probably want to keep doing that), so having
a quick shorthand to grab physical addresses can be convenient.