linux-kernel - RE: [PATCH v3] dcdbas: Add support for WSMT ACPI table

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:   Mon, 2 Jul 2018 14:07:00 +0000
From:   <Mario.Limonciello@...l.com>
To:     <andy.shevchenko@...il.com>, <stuart.w.hayes@...il.com>
CC:     <dvhart@...radead.org>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>
Subject: RE: [PATCH v3] dcdbas: Add support for WSMT ACPI table

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@...il.com]
> Sent: Friday, June 29, 2018 2:30 PM
> To: Stuart Hayes
> Cc: Darren Hart; Limonciello, Mario; Linux Kernel Mailing List; Platform Driver
> Subject: Re: [PATCH v3] dcdbas: Add support for WSMT ACPI table
> 
> On Fri, Jun 29, 2018 at 9:56 PM, Stuart Hayes <stuart.w.hayes@...il.com> wrote:
> > On 06/27/2018 06:52 PM, Andy Shevchenko wrote:
> >> On Fri, Jun 15, 2018 at 1:31 AM, Stuart Hayes <stuart.w.hayes@...il.com>
> wrote:
> >>> On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> >>>> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes <stuart.w.hayes@...il.com>
> wrote:
> >>>>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
> 
> >>>> Thanks, but here I meant += 1 vs += 16 step.
> 
> > I did realize that the debug code that printed the address of the EPS table was not
> > working right, and the table on my system is actually 16-byte aligned.  However,
> > the documentation on the EPS does not specify that it will be 16-byte aligned, so I
> > don't think the driver should make that assumption, especially since scanning a
> 64K
> > region byte by byte should take very little extra time over scanning every 16th
> byte.
> 
> > I guess this isn't needed since the table on my system actually is 16-byte aligned.
> 
> I think the 16 byte is a natural alignment applicable to all tables like a such.
> I would rather go with it until we will get a (weird) BIOS which does
> not support that.
> 
> (I believe this alignment just comes by definition of C ABIs for the
> structures / types. So, each defined type is located on an aligned
> boundaries)
> 
> >>> [ 4680.194012] dcdbas dcdbas: WSMT found, using firmware-provided SMI
> buffer.
> >>> [ 4680.195327] dcdbas dcdbas: Dell Systems Management Base Driver (version
> 5.6.0-3.3)
> >>
> >> OK, now the most important question, did you investigate "SMM
> >> Communication ACPI Table"?
> >> Can you utilize information in it?
> 
> > Dell BIOS does not provide a "SMM Communication ACPI Table", just the EPS.  It
> appears
> > that the "SMM Communication ACPI Table" is deprecated in the UEFI 2.7 spec.
> Also, the
> > dcdbas driver is for Dell systems only.
> 
> > The EPS table isn't an ACPI table,
> > it's just a Dell-defined table.
> 
> Hmm... It's either strange or has some background why is so.
> OK it has a note that there is no use case, but here it is!
> 
> Mario, can we consider this as a BIOS bug which doesn't provide SMM
> Communication ACPI table?
> 
> Can it be escalated on UEFI committee?
> 

I don't believe SMM communication ACPI table has ever been implemented by Dell
on server or client BIOS.  I do agree this table describes the behavior that DCDBAS driver
has used since before even UEFI BIOS pretty accurately.

Stuart and I did discuss with server BIOS (who uses this EPS mechanism) to see if its possible
to move EPS to SMM communication ACPI table however since it's been deprecated by
UEFI 2.7 they weren't willing to adopt it.

Stuart, anything else you want to add here?