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]
Message-ID: <CF6A88132359CE47947DB4C6E1709ED53C557DAB@ORSMSX122.amr.corp.intel.com>
Date:   Thu, 20 Dec 2018 01:15:43 +0000
From:   "Schmauss, Erik" <erik.schmauss@...el.com>
To:     "Williams, Dan J" <dan.j.williams@...el.com>
CC:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Busch, Keith" <keith.busch@...el.com>,
        "Moore, Robert" <robert.moore@...el.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: RE: [PATCHv2 01/12] acpi: Create subtable parsing infrastructure



> -----Original Message-----
> From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-
> owner@...r.kernel.org] On Behalf Of Dan Williams
> Sent: Wednesday, December 19, 2018 4:00 PM
> To: Schmauss, Erik <erik.schmauss@...el.com>
> Cc: Rafael J. Wysocki <rafael@...nel.org>; Busch, Keith
> <keith.busch@...el.com>; Moore, Robert <robert.moore@...el.com>;
> Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; ACPI Devel
> Maling List <linux-acpi@...r.kernel.org>; Linux Memory Management
> List <linux-mm@...ck.org>; Greg Kroah-Hartman
> <gregkh@...uxfoundation.org>; Hansen, Dave
> <dave.hansen@...el.com>
> Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing
> infrastructure
> 
> On Wed, Dec 19, 2018 at 3:19 PM Schmauss, Erik
> <erik.schmauss@...el.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-
> > > owner@...r.kernel.org] On Behalf Of Rafael J. Wysocki
> > > Sent: Tuesday, December 11, 2018 1:45 AM
> > > To: Busch, Keith <keith.busch@...el.com>
> > > Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; ACPI
> > > Devel Maling List <linux-acpi@...r.kernel.org>; Linux Memory
> > > Management List <linux-mm@...ck.org>; Greg Kroah-Hartman
> > > <gregkh@...uxfoundation.org>; Rafael J. Wysocki
> <rafael@...nel.org>;
> > > Hansen, Dave <dave.hansen@...el.com>; Williams, Dan J
> > > <dan.j.williams@...el.com>
> > > Subject: Re: [PATCHv2 01/12] acpi: Create subtable parsing
> > > infrastructure
> > >
> > > On Tue, Dec 11, 2018 at 2:05 AM Keith Busch
> <keith.busch@...el.com>
> > > wrote:
> > > >
> >
> > Hi Rafael and Bob,
> >
> > > > Parsing entries in an ACPI table had assumed a generic header
> > > > structure that is most common. There is no standard ACPI
> header,
> > > > though, so less common types would need custom parsers if they
> > > > want go through their sub-table entry list.
> > >
> > > It looks like the problem at hand is that acpi_hmat_structure is
> > > incompatible with acpi_subtable_header because of the different
> layout and field sizes.
> >
> > Just out of curiosity, why don't we use ACPICA code to parse static
> > ACPI tables in Linux?
> >
> > We have a disassembler for static tables that parses all supported
> > tables. This seems like a duplication of code/effort...
> 
Hi Dan,

> Oh, I thought acpi_table_parse_entries() was the common code.
> What's the ACPICA duplicate?

I was thinking AcpiDmDumpTable(). After looking at this ACPICA code,
I realized that the this ACPICA doesn't actually build a parse tree or data structure.
It loops over the data structure to format the input ACPI table to a file.

To me, it seems like a good idea for Linux and ACPICA to share the same code when
parsing and analyzing these structures. I know that Linux may emit warnings
that are specific to Linux but there are structural analyses that should be the same (such as
checking lengths of tables and subtables so that we don't have out of bounds access).

Erik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ