linux-kernel - Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

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: <CAMuHMdUHnFKzhe3x3=bG63HwnM7psu7AA=nba8q+nTDnxBAryw@mail.gmail.com>
Date:   Sun, 10 Jun 2018 10:29:45 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Michael Schmitz <schmitzmic@...il.com>,
        Andreas Schwab <schwab@...ux-m68k.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on
 unsupported hardware

Hi Finn,

On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@...egraphics.com.au> wrote:
> > > > Is this enum used by any user space code? If so, perhaps rather
> > > > leave the PMU_68K_V1 in there to avoid upsetting that?
> > >
> > > It also changes the value of PMU_68K_V2, which is an ABI break.
> >
> > Yes, that's what I worry about - but do we know of any users of that
> > particular interface?
>
> There is no ABI issue AFAIK. The value of pmu_kind is visible to userland
> only on powerpc. /dev/pmu and /proc/pmu/* do not exist on m68k. This patch
> series will make these UAPIs available on m68k, and for that reason I've
> chosen the value PMU_UNKNOWN for pmu_kind.

While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
unless we are 100% sure there are no users.

If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
needing to check the PMU type, it would have a switch() statement with
all existing values defined in <linux/pmu.h>. So that would become broken
by your change.

Hence the enum is append-only.

> New pmu_kind values can be defined as and when the need arises. But that
> would imply a useful classification scheme for pre-PCI powerbooks, and I
> don't know what that scheme will look like because at this stage there is
> neither userland nor kernel code to support backlight, buttons and battery
> for pre-PCI powerbooks.
>
> In anycase, the "v1" and "v2" scheme is obviously inadequate when you
> consider the range of m68k powerbook models. Also, consider the

New values can be added at the bottom.

> out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has
> this ABI break:
>
> diff --git a/include/linux/pmu.h b/include/linux/pmu.h
> index cafe98d9694..9882a185a52 100644
> --- a/include/linux/pmu.h
> +++ b/include/linux/pmu.h
> @@ -90,6 +90,7 @@ enum {
>          PMU_HEATHROW_BASED,     /* PowerBook G3 series */
>          PMU_PADDINGTON_BASED,   /* 1999 PowerBook G3 */
>          PMU_KEYLARGO_BASED,     /* Core99 motherboard (PMU99) */
> +        PMU_NUBUS_BASED,        /* 1400, 2300, 5300 */
>          PMU_68K_V1,             /* 68K PMU, version 1 */
>          PMU_68K_V2,             /* 68K PMU, version 2 */
>  };

That's bad.  But as long as the NuBus-PMac project is out-of-tree, the
enum values it uses are not part of the Linux ABI, IMHO.
During upstreaming, PMU_NUBUS_BASED should be moved to the bottom.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds