mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Cyril Novikov <cnovikov@lynx.com>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	X86 ML <x86@kernel.org>, Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Alan Cox <alan@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
Date: Sun, 28 Jan 2018 19:36:38 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1801281931180.2126@nanos> (raw)
In-Reply-To: <CAPcyv4jTaskPT1qXhdCO2mWVkcaMDMBq12vUJ_hSfjOU49qvgQ@mail.gmail.com>

On Sun, 28 Jan 2018, Dan Williams wrote:
> On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >> + */
> >> +#define array_idx(idx, sz)                                           \
> >> +({                                                                   \
> >> +     typeof(idx) _i = (idx);                                         \
> >> +     typeof(sz) _s = (sz);                                           \
> >> +     unsigned long _mask = array_idx_mask(_i, _s);                   \
> >> +                                                                     \
> >> +     BUILD_BUG_ON(sizeof(_i) > sizeof(long));                        \
> >> +     BUILD_BUG_ON(sizeof(_s) > sizeof(long));                        \
> >> +                                                                     \
> >> +     _i &= _mask;                                                    \
> >> +     _i;                                                             \
> >> +})
> >> +#endif /* __NOSPEC_H__ */
> >
> > For heaven's sake, please name a size variable as 'size', not 'sz'. We don't have
> > a shortage of characters and can deobfuscate common primitives, can we?
> >
> > Also, beyond the nits, I also hate the namespace here. We have a new generic
> > header providing two new methods:
> >
> >         #include <linux/nospec.h>
> >
> >         array_idx_mask()
> >         array_idx()
> >
> > which is then optimized for x86 in asm/barrier.h. That's already a non-sequitor.
> >
> > Then we introduce uaccess API variants with a _nospec() postfix.
> >
> > Then we add ifence() to x86.
> >
> > There's no naming coherency to this.
> 
> Ingo, I love you, but please take the incredulity down a bit,
> especially when I had 'nospec' in all the names in v1. Thomas, Peter,
> and Alexei wanted s/nospec_barrier/ifence/ and

Sorry, I never was involved in that discussion.

> s/array_idx_nospec/array_idx/. You can always follow on with a patch
> to fix up the names and placements to your liking. While they'll pick
> on my name choices, they won't pick on yours, because I simply can't
> be bothered to care about a bikeshed color at this point after being
> bounced around for 5 revisions of this patch set.

Oh well, we really need this kind of attitude right now. We are all fed up
with that mess, but Ingo and I care about the details, consistency and
general code quality beyond the current rush to get stuff solved. It's our
damned job as maintainers.

If you decide you don't care anymore, please let me know, so I can try to
free up some cycles to pick up the stuff from where you decided to dump it.

Thanks,

	tglx

  parent reply	other threads:[~2018-01-28 18:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <151703971300.26578.1185595719337719486.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-27 19:26 ` [PATCH v5 00/12] spectre variant1 mitigations for tip/x86/pti Dan Williams
     [not found] ` <151703972396.26578.7326612698912543866.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  8:55   ` [PATCH v5 02/12] array_idx: sanitize speculative array de-references Ingo Molnar
2018-01-28 11:36     ` Thomas Gleixner
2018-01-28 16:28     ` Dan Williams
2018-01-28 18:33       ` Ingo Molnar
2018-01-29 16:45         ` Dan Williams
2018-01-28 18:36       ` Thomas Gleixner [this message]
2018-01-30  6:29         ` Dan Williams
2018-01-30 19:38           ` Linus Torvalds
2018-01-30 20:13             ` Dan Williams
2018-01-30 20:27               ` Van De Ven, Arjan
2018-01-31  8:03                 ` Ingo Molnar
2018-01-31 14:13                   ` Van De Ven, Arjan
2018-01-31 14:21                     ` Greg KH
     [not found] ` <151703972912.26578.6792656143278523491.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  9:02   ` [PATCH v5 03/12] x86: implement array_idx_mask Ingo Molnar
     [not found] ` <151703973427.26578.15693075353773519333.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  9:14   ` [PATCH v5 04/12] x86: introduce __uaccess_begin_nospec and ifence Ingo Molnar
2018-01-29 20:41     ` Dan Williams
2018-01-30  6:56       ` Ingo Molnar
     [not found] ` <151703974000.26578.2874964402485950653.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  9:19   ` [PATCH v5 05/12] x86, __get_user: use __uaccess_begin_nospec Ingo Molnar
     [not found] ` <151703974570.26578.3809646715924406820.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  9:25   ` [PATCH v5 06/12] x86, get_user: use pointer masking to limit speculation Ingo Molnar
     [not found] ` <151703975137.26578.11230688940391207602.stgit@dwillia2-desk3.amr.corp.intel.com>
2018-01-28  9:29   ` [PATCH v5 07/12] x86: remove the syscall_64 fast-path Ingo Molnar
2018-01-28 15:22     ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1801281931180.2126@nanos \
    --to=tglx@linutronix.de \
    --cc=alan@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=cnovikov@lynx.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®