linux-kernel - Re: [PATCH v2] platform/x86/intel/ifs: Allow non-default names for IFS image

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, 28 Jul 2022 14:07:30 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Jithu Joseph <jithu.joseph@...el.com>, markgross@...nel.org,
        ashok.raj@...el.com, tony.luck@...el.com, ravi.v.shankar@...el.com,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        patches@...ts.linux.dev
Subject: Re: [PATCH v2] platform/x86/intel/ifs: Allow non-default names for
 IFS image

On Thu, Jul 28, 2022 at 01:57:25PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 7/10/22 18:59, Greg KH wrote:
> > On Sun, Jul 10, 2022 at 09:00:11AM -0700, Jithu Joseph wrote:
> >> Existing implementation limits IFS images to be loaded only from
> >> a default file-name /lib/firmware/intel/ifs/ff-mm-ss.scan.
> > 
> > That was by design, why is this suddenly not acceptable?
> > 
> >> But there are situations where there may be multiple scan files
> >> that can be run on a particular system stored in /lib/firmware/intel/ifs
> > 
> > Again, this was by design.
> > 
> >> E.g.
> >> 1. Because test contents are larger than the memory reserved for IFS by BIOS
> > 
> > What does the BIOS have to do with this?
> > 
> >> 2. To provide increased test coverage
> > 
> > Test coverage of what?
> > 
> >> 3. Custom test files to debug certain specific issues in the field
> > 
> > Why can't you rename the existing file?
> > 
> >> Renaming each of these to ff-mm-ss.scan and then loading might be
> >> possible in some environments. But on systems where /lib is read-only
> >> this is not a practical solution.
> > 
> > What system puts /lib/ as read-only that you want to have loading
> > hardware firmware?  That kind of defeats the security implications of
> > having a read-only /lib/, right?
> > 
> >> Modify the semantics of the driver file
> >> /sys/devices/virtual/misc/intel_ifs_0/reload such that,
> >> it interprets the input as the filename to be loaded.
> > 
> > So you are now going to allow any file to be read from the system, in an
> > unknown filesystem namespace, by this driver?
> 
> @Intel folks to me this is the big blocker which needs to be solved before
> we can move forward with figuring out how to allow loading multiple
> different sets of test patterns through IFS.
> 
> Which in turn is required to remove the broken marking...
> 
> How about echoing a suffix to be appended to the default filename to
> the reload attribute? This suffix would then need to be sanity checked
> to only contain [a-z][0-9] (we don't want '/' but it seems better to
> limit this further) to avoid directory traversal attacks. 
> 
> (and echoing an empty suffix can be used to force reloading the
> default test-patterns after a linux-firmware pkg upgrade)
> 
> This way we avoid the allowing user to load an arbitrary file issue.
> 
> Greg, would using a suffix appended to the default filename be
> acceptable to you as a solution to solving the load arbitrary
> file issue?

Not really, a suffix doesn't protect much at all.

This really feels like a "test the product in the factory" type of
option that someone seems to want to do without just renaming the
firmware file.  Why this is unique from all other firmware file loading
in the kernel needs to really be explained here in order to even
consider justifying this type of change.

thanks,

greg k-h