linux-kernel - Re: [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers

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: <15d81463b631e03b00a7031510304d5598fc246c.camel@intel.com>
Date:   Tue, 12 Oct 2021 23:15:00 +0000
From:   "Winiarska, Iwona" <iwona.winiarska@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
CC:     "corbet@....net" <corbet@....net>,
        "jae.hyun.yoo@...ux.intel.com" <jae.hyun.yoo@...ux.intel.com>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        "andrew@...id.au" <andrew@...id.au>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "yazen.ghannam@....com" <yazen.ghannam@....com>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "olof@...om.net" <olof@...om.net>, "arnd@...db.de" <arnd@...db.de>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
        "zweiss@...inix.com" <zweiss@...inix.com>,
        "d.mueller@...oft.ch" <d.mueller@...oft.ch>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "joel@....id.au" <joel@....id.au>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent
 headers

On Mon, 2021-10-11 at 23:31 +0200, Borislav Petkov wrote:
> On Mon, Oct 11, 2021 at 08:38:43PM +0000, Winiarska, Iwona wrote:
> > Everything that's part of this series runs on the BMC (Baseboard
> > Management Controller). There's nothing ARM specific to it - it's just
> > that the BMC hardware we're currently supporting is ARM-based. PECI is
> > an interface that's exposed by some x86 CPUs - but that's a hardware
> > interface (available completely independent from whatever is actually
> > running on the x86 CPU).
> 
> Aha, I think I got it: so this whole PECI pile is supposed to run on
> the BMC - which can be ARM but doesn't have to be, i.e., code should be
> generic enough - and the interfaces to the x86 CPU do get exposed to the
> Linux running on the BMC.
> 
> Which brings me to the answer to your other mail:
> 
> On Mon, Oct 11, 2021 at 07:32:38PM +0000, Winiarska, Iwona wrote:
> > Nothing wrong - just a trade-off between churn and keeping things tidy
> > and not duplicated, similar to patch 1. And just like in patch 1, if
> > you have a strong opinion against it - we can duplicate.
> 
> So it is not about strong opinion. Rather, it is about whether this
> exporting would be disadvantageous for x86 freedom. And I think it will
> be:
> 
> Because if you exported those and then we went and changed those
> interfaces and defines (changed their naming, function arguments,
> whatever) and something outside of x86 used them, we will break that
> something.
> 
> And usually we go and fix those users too but I doubt anyone has access
> to that PECI hw to actually test fixes, etc, etc.

We (OpenBMC) do have PECI HW, so that shouldn't be a problem.

> So I'd prefer the small amount of duplication vs external stuff using
> x86 facilities any day of the week. And so I'd suggest you simply copy
> the handful of functions and defines you're gonna be needing and the
> defines and be done with it.
> 
> Dave's idea makes sense to me too but lately it keeps happening that
> we change something in x86-land and it turns out something "from the
> outside" is using it and it breaks, so it is a lot easier if things are
> independent.

Both CPUID.EAX=1 decoding and definitions in intel-family are pretty "well-
defined". I understand the scenario that you're describing, but in order to
break the outside user there would need to be some "logic" behind the pulled in
concepts (if, for example, I would use something like X86_MATCH_* defines in
PECI).

Thanks
-Iwona

> 
> Thx.
>