linux-kernel - Re: [PATCH 2/2] arm64: acpi: Prepare for longer MADTs

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: <20181101142247.GB27913@e107155-lin>
Date:   Thu, 1 Nov 2018 14:22:47 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Jeremy Linton <jeremy.linton@....com>,
        linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
        will.deacon@....com, ard.biesheuvel@...aro.org,
        james.morse@....com, rafael.j.wysocki@...el.com,
        takahiro.akashi@...aro.org, Sudeep Holla <sudeep.holla@....com>,
        ahs3@...hat.com, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: acpi: Prepare for longer MADTs

On Thu, Nov 01, 2018 at 11:31:36AM +0000, Lorenzo Pieralisi wrote:
> On Fri, Oct 12, 2018 at 02:29:37PM -0500, Jeremy Linton wrote:
> > The BAD_MADT_GICC_ENTRY check is a little too strict because
> > it rejects MADT entries that don't match the currently known
> > lengths. We should remove this restriction to avoid problems
> > if the table length changes. Future code which might depend on
> > additional fields should be written to validate those fields
> > before using them, rather than trying to globally check
> > known MADT version lengths.
> >
> > Signed-off-by: Jeremy Linton <jeremy.linton@....com>
> > ---
> >  arch/arm64/include/asm/acpi.h | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
>
> Hi Jeremy,
>
> I assume there is no [PATCH 1/2] (to make sure I have not missed
> anything).
>

IIRC, it's a patch fixing module device table entry for SPE. They are
independent, just happened to be put out together.

--
Regards,
Sudeep