linux-kernel - Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <159315642733.62212.13203844825360378214@swboyd.mtv.corp.google.com>
Date:   Fri, 26 Jun 2020 00:27:07 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Julius Werner <jwerner@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Patrick Rudolph <patrick.rudolph@...ements.com>,
        Coreboot <coreboot@...eboot.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexios Zavras <alexios.zavras@...el.com>,
        Allison Randal <allison@...utok.net>,
        Julius Werner <jwerner@...omium.org>,
        Samuel Holland <samuel@...lland.org>
Subject: Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs

Quoting Julius Werner (2020-06-25 13:51:34)
> > > +What:          /sys/bus/coreboot/devices/.../cbmem_attributes/address
> > > +Date:          Apr 2020
> > > +KernelVersion: 5.6
> > > +Contact:       Patrick Rudolph <patrick.rudolph@...ements.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.

Ok. Regardless of the concern of the physical address is there any usage
of this attribute by userspace? The description makes it sound like it's
a pure debug feature, which implies that it should be in debugfs and not
in sysfs.