On 05/17/2018 02:15 PM, Greg Kroah-Hartman wrote:
Shouldn't we just do this in one place, in the valid_port() function?

That way it keeps the range checking logic in one place (now it is in 3
places in the function), which should make maintenance much simpler.

Yep, I thought about that, the thing is: what happens if the hardware is
"trained" to predict that valid_port always evaluates to false, and then
malicious values are stored in pdev_nr and nhport?

It seems to me that under this scenario we need to serialize instructions in
this place.

What do you think?

I don't understand, it should not matter where you put the barrier.  Be
it a function call back or right after it, it does the same thing, it
stops speculation from crossing that barrier.

Yeah. It makes sense.

So it _should_ work either way, if I understand the issue correctly.

If not, what am I missing?

No. It seems I'm the one who was missing something.

I'll place the barrier into valid_port and send v2 shortly.

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

Reply via email to