Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Tony Luck]

On Sat, Jan 13, 2018 at 10:51 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck <tony.l...@gmail.com> wrote:
> So your argument depends on "the uarch will actually run the code in
> order if there are no events that block the pipeline".

And might be bogus ... I'm a software person not a u-arch expert. That
sounded good in my head, but the level of parallelism may be greater
than I can imagine.

> Or at least it depends on a certain latency of the killing of any OoO
> execution being low enough that the cache access doesn't even begin.
>
> I realize that that is very much a particular microarchitectural
> detail, but it's actually a *big* deal. Do we have a set of rules for
> what is not a worry, simply because the speculated accesses get killed
> early enough?
>
> Apparently "test a register value against a constant" is good enough,
> assuming that register is also needed for the address of the access.

People who do understand this are working on what can be guaranteed.
For now don't make big plans based on my ramblings.

-Tony

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Tony Luck]

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
 wrote:
> Should the array access in entry_SYSCALL_64_fastpath be made to use
> the masking approach?

That one has a bounds check for an inline constant.

 cmpq$__NR_syscall_max, %rax

so should be safe.

The classic Spectre variant #1 code sequence is:

int array_size;

   if (x < array_size) {
   something with array[x]
   }

which runs into problems because the array_size variable may not
be in cache, and while the CPU core is waiting for the value it
speculates inside the "if" body.

The syscall entry is more like:

#define ARRAY_SIZE 10

 if (x < ARRAY_SIZE) {
  something with array[x]
 }

Here there isn't any reason for speculation. The core has the
value of 'x' in a register and the upper bound encoded into the
"cmp" instruction.  Both are right there, no waiting, no speculation.

-Tony

Re: [PATCH v3 1/9] string: introduce memweight

[Tony Luck]

On Fri, Jun 8, 2012 at 5:50 PM, Akinobu Mita akinobu.m...@gmail.com wrote:
  lib/string.c           |   36 

Is lib/string.c the right place for this?  I get a build error on the
ia64 sim_defconfig:

  LD  arch/ia64/hp/sim/boot/bootloader

It fails because it pulls in lib/lib.a(string.o) to get some
innocuous function like strcpy() ... but it also gets
given memweight() which relies on __bitmap_weight()
which it doesn't have, because it doesn't include lib/built-in.o
(which is where bitmap.o, the definer of __bitmap_weight(), has
been linked).

Moving memweight() to lib/bitmap.c fixes the problem. But it
isn't really clear that it belongs there either.  Perhaps it should
be its own file lib/memweight.c that gets included in lib/lib.a?

-Tony
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html