Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 Jan 2018 10:17:49 +0000
From: Will Deacon <>
To: Dan Williams <>
Cc: Linus Torvalds <>,
	Russell King - ARM Linux <>,
	Thomas Gleixner <>,
	linux-arch <>,
	Kernel Hardening <>,
	Peter Zijlstra <>,
	Catalin Marinas <>, X86 ML <>,
	Ingo Molnar <>,
	Greg KH <>,
	"H. Peter Anvin" <>, Alan Cox <>
Subject: Re: [PATCH v4.1 02/10] asm/nospec, array_ptr: sanitize speculative
 array de-references

On Mon, Jan 22, 2018 at 10:52:54AM -0800, Dan Williams wrote:
> On Mon, Jan 22, 2018 at 10:37 AM, Linus Torvalds
> <> wrote:
> > Note that 'idx' itself can have any range (that's kind of the _point_,
> > after all: checking that idx is in some range). But the logic only
> > works for a positive array size.
> >
> > Which honestly is not really a limitation, but it's worth spelling out, I think.

Agreed. We should be absolutely clear about when this thing works and when
it doesn't.

> > In particular, if you have a user pointer, and a 3G:1G split in
> > user:kernel address space, you camn *not* do something like
> >
> >     uptr = array_ptr(NULL, userptr, TASK_SIZE);
> >
> > to get a sanitized user pointer, because TASK_SIZE is not positive in 'long'.
> >
> > Hmm?
> We could at least have a BUILD_BUG_ON when 'size' is a
> builtin_contstant and greater than LONG_MAX. Alternatively we could
> require archs to provide the equivalent of the x86 array_ptr_mask()
> that does not have the LONG_MAX limitation?

I'd rather avoid imposing that limitation and instead just treat uaccess
specially. It looks like we can satisfy the current definition of
array_ptr_mask with three instructions, but I'm not sure how we could get it
working on arm64 if we needed to deal with arbitrary sizes (particularly as
we're trying to avoid conditional instructions).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.