On Wed, Jan 31, 2018 at 02:13:45PM +, Van De Ven, Arjan wrote:
> > > short term there was some extremely rudimentary static analysis done.
> > > clearly
> > > that has extreme limitations both in insane rate of false positives, and
> > > missing
> > > cases.
> >
> > What was the output rough
> > short term there was some extremely rudimentary static analysis done.
> > clearly
> > that has extreme limitations both in insane rate of false positives, and
> > missing
> > cases.
>
> What was the output roughly, how many suspect places that need
> array_idx_nospec()
> handling: a few, a f
* Van De Ven, Arjan wrote:
> > > IOW, is there some work on tooling/analysis/similar? Not asking for
> > > near-term, but more of a "big picture" question..
>
> short term there was some extremely rudimentary static analysis done. clearly
> that has extreme limitations both in insane rate of f
> > Anyway, I do think the patches I've seen so far are ok, and the real
> > reason I'm writing this email is actually more about future patches:
> > do we have a good handle on where these array index sanitations will
> > be needed?
the obvious cases are currently obviously being discussed.
but
[ adding Arjan ]
On Tue, Jan 30, 2018 at 11:38 AM, Linus Torvalds
wrote:
[..]
> Anyway, I do think the patches I've seen so far are ok, and the real
> reason I'm writing this email is actually more about future patches:
> do we have a good handle on where these array index sanitations will
> be n
On Mon, Jan 29, 2018 at 10:29 PM, Dan Williams wrote:
>
> Of course, and everything about the technical feedback and suggestions
> was completely valid, on point, and made the patches that much better.
> What wasn't appreciated and what I am tired of grinning and bearing is
> the idea that it's on
On Sun, Jan 28, 2018 at 10:36 AM, Thomas Gleixner wrote:
> On Sun, 28 Jan 2018, Dan Williams wrote:
>> On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
>> >> + */
>> >> +#define array_idx(idx, sz) \
>> >> +({
On Sun, Jan 28, 2018 at 10:33 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> Thomas, Peter, and Alexei wanted s/nospec_barrier/ifence/ and
>
> I just checked past discussions, and I cannot find that part, got any links or
> message-IDs?
>
> PeterZ's feedback on Jan 8 was:
>
>> On Sun, Jan
On Sun, 28 Jan 2018, Dan Williams wrote:
> On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
> >> + */
> >> +#define array_idx(idx, sz) \
> >> +({ \
> >> + typeof(idx) _i = (idx);
* Dan Williams wrote:
> Thomas, Peter, and Alexei wanted s/nospec_barrier/ifence/ and
I just checked past discussions, and I cannot find that part, got any links or
message-IDs?
PeterZ's feedback on Jan 8 was:
> On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote:
> > How abo
On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
>
> Firstly, I only got a few patches of this series so I couldn't review all of
> them
> - please Cc: me to all future Meltdown and Spectre related patches!
>
> * Dan Williams wrote:
>
>> 'array_idx' is proposed as a generic mechanism to miti
On Sun, 28 Jan 2018, Ingo Molnar wrote:
> * Dan Williams wrote:
> > +
> > +#ifndef __NOSPEC_H__
> > +#define __NOSPEC_H__
_LINUX_NOSPEC_H
We have an established practice for those header guards...
> > +/*
> > + * When idx is out of bounds (idx >= sz), the sign bit will be set.
> > + * Extend th
Firstly, I only got a few patches of this series so I couldn't review all of
them
- please Cc: me to all future Meltdown and Spectre related patches!
* Dan Williams wrote:
> 'array_idx' is proposed as a generic mechanism to mitigate against
> Spectre-variant-1 attacks, i.e. an attack that byp
13 matches
Mail list logo