Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221003142400.1177057-1-e.velu@criteo.com> <0d7537b3e1ef68440b72f56cc2739aa3efbe52f9.camel@suse.com>
In-Reply-To: <0d7537b3e1ef68440b72f56cc2739aa3efbe52f9.camel@suse.com>
From:   Erwan Velu <erwanaliasr1@gmail.com>
Date:   Wed, 12 Oct 2022 14:11:16 +0200
Message-ID: <CAL2JzuyvsTtUBB8VpbiuKJ2b6vEU_zLYELeYn-pm3-e82AbB_g@mail.gmail.com>
Subject: Re: [PATCH] firmware/dmi: Print product serial number if any
To:     Jean Delvare <jdelvare@suse.com>
Cc:     "e.velu@criteo.com" <e.velu@criteo.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

[...]
> I see the value of this change. However it raises a privacy concern. So
> far, /sys/devices/virtual/dmi/id/product_serial is only readable by
> root. Writing the same string to the kernel log where everybody can
> read it is thus questionable.
>
> I can think of 2 ways to solve that problem:
> 1* I'm not really sure why the serial numbers stored in the DMI table
> were originally considered a secret. So we could change these sysfs
> attributes to mode 644, and then printing them in the kernel log would
> of course be OK.
> 2* We could make your code dependent on
> CONFIG_SECURITY_DMESG_RESTRICT=y. If dmesg is restricted to root then
> including the serial number there is OK, regardless of the permissions
> of /sys/devices/virtual/dmi/id/product_serial .
>
> For simplicity I'd go with option 1, but if people strongly disagree
> with making serial numbers world-readable, we can go with option 2.


Yeah I don't really see why showing a serial host in a dmesg is a
security problem.
We already expose other serials like disk or mac addresses which could
be considered private in the same way.


> Now from an implementation perspective, you chose to go with
> DMI_PRODUCT_SERIAL. That will work fine for vendor systems, however for
> self-assembled systems, DMI_PRODUCT_SERIAL is typically unset and
> DMI_BOARD_SERIAL would be more relevant. So it may make sense to
> fallback to "BSN: <DMI_BOARD_SERIAL>" if DMI_PRODUCT_SERIAL is unset.
> Unless you think such systems are out of scope for the intended purpose
> anyway, in which case your code is OK.

Note we have already the same issue with DMI_BIOS_VERSION vs DMI_BIOS_RELEASE.
On HPE system, reported the VERSION is useless as it points to the
motherboard type (U30/U32..) while the release field is the 'version'
like 2.56. On ODM systems, that is the opposite. \o/