linux-kernel - Re: [PATCH] firmware: export x86_64 platform flash bios region via 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 12 Nov 2021 13:25:13 +0100
From:   Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Richard Hughes <hughsient@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Mauro Lima <mauro.lima@...ypsium.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philipp Deppenwiese <philipp.deppenwiese@...u.ne>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs

Am Fr., 12. Nov. 2021 um 11:43 Uhr schrieb Greg KH <gregkh@...uxfoundation.org>:
>
> On Fri, Nov 12, 2021 at 10:09:14AM +0000, Richard Hughes wrote:
> > On Fri, 12 Nov 2021 at 06:52, Greg KH <gregkh@...uxfoundation.org> wrote:
> > > Why don't we just export these areas to userspace and let the decoding
> > > of them happen there?
> >
> > Unless I'm missing something, the patch from Hans-Gert does just that:
> > exposing the IFD BIOS partition that encloses the various EFI file
> > volumes.
>
> But it is not tied into the EFI subsystem at all, binding only to those
> resources.  It does not do anything with any efi symbol or access
> control.
>
> Again, that's my primary complaint here, the driver HAS to be able to
> tell the kernel what resource it wants to bind to and control, right now
> it just "assumes" that it can have access to a chunk of memory without
> any notification or checks at all, which will cause problems on systems
> that do not follow that assumption.
>
> So while you all are arguing over oddities, the main complaint here of
> "this driver is not ok as-is" seems to keep being ignored for some odd
> reason.

No, no, at least I am not ignoring it. I am aware of that and I was
planning to fix the broken parts since the start of the discussion.
Sorry for the miscommunication here.

>
> I'm going to just ignore this thread now and wait for a new patch to
> review.

That's the plan and I'd be happy if we don't have to discuss it
further right now.

>
> thanks,
>
> greg k-h

Hans-Gert