diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2019-01-04 12:56:09 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2019-01-04 12:56:09 -0800 |
commit | 594cc251fdd0d231d342d88b2fdff4bc42fb0690 (patch) | |
tree | 259269a399e6504a7cf8739201cf172d1cbb197a /lib/muldi3.c | |
parent | 0b2c8f8b6b0c7530e2866c95862546d0da2057b0 (diff) | |
download | linux-594cc251fdd0d231d342d88b2fdff4bc42fb0690.tar.bz2 |
make 'user_access_begin()' do 'access_ok()'
Originally, the rule used to be that you'd have to do access_ok()
separately, and then user_access_begin() before actually doing the
direct (optimized) user access.
But experience has shown that people then decide not to do access_ok()
at all, and instead rely on it being implied by other operations or
similar. Which makes it very hard to verify that the access has
actually been range-checked.
If you use the unsafe direct user accesses, hardware features (either
SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged
Access Never - on ARM) do force you to use user_access_begin(). But
nothing really forces the range check.
By putting the range check into user_access_begin(), we actually force
people to do the right thing (tm), and the range check vill be visible
near the actual accesses. We have way too long a history of people
trying to avoid them.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/muldi3.c')
0 files changed, 0 insertions, 0 deletions