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.
Thanks!
--
Gustavo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
