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: <20200924175023.GN5030@zn.tnic>
Date:   Thu, 24 Sep 2020 19:50:23 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Smita Koralahalli Channabasappa <skoralah@....com>,
        Punit Agrawal <punit1.agrawal@...hiba.co.jp>
Cc:     Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-edac@...r.kernel.org,
        linux-efi@...r.kernel.org, linux-acpi@...r.kernel.org,
        devel@...ica.org, Tony Luck <tony.luck@...el.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Yazen Ghannam <yazen.ghannam@....com>
Subject: Re: [PATCH v4] cper, apei, mce: Pass x86 CPER through the MCA
 handling chain

On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa wrote:
> > Even though it's not defined in the UEFI spec, it doesn't mean a
> > structure definition cannot be created.

Created for what? That structure better have a big fat comment above it, what
firmware generates its layout.

> > After all, the patch is relying on some guarantee of the meaning of
> > the values and their ordering.

AFAICT, this looks like an ad-hoc definition and the moment they change
it in some future revision, that struct of yours becomes invalid so we'd
need to add another one.

> > If the patch is relying on the definitions in the SMCA spec it is a good

Yes, what SMCA spec is that?

> > idea to reference it here - both for review and providing relevant
> > context for future developers.
> 
> Okay, I agree the structure definition will make the code less arbitrary
> and provides relevant context compared to pointer arithmetic. I did not
> think this way. I can try this out if no objections.

Again, this struct better have "versioning" info because the moment your
fw people change it in some future platform, this code needs touching
again.

It probably would need touching even with the offsets if those offsets
change but at least not having it adhere to some slow-moving spec is
probably easier in case they wanna add/change fields.

So Smita, you probably should talk to fw people about how stable that
layout at ctx_info + 1 is going to be wrt future platforms so that
we make sure we only access the correct offsets, now and on future
platforms.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ