[lkml]   [2020]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
On Thu, Apr 02, 2020 at 07:03:28PM +0200, Christophe Leroy wrote:

> user_access_begin() grants both read and write.
> This patch adds user_read_access_begin() and user_write_access_begin() but
> it doesn't remove user_access_begin()

Ouch... So the most generic name is for the rarest case?

> > What should we do about that? Do we prohibit such blocks outside
> > of arch?
> >
> > What should we do about arm and s390? There we want a cookie passed
> > from beginning of block to its end; should that be a return value?
> That was the way I implemented it in January, see
> There was some discussion around that and most noticeable was:
> H. Peter (hpa) said about it: "I have *deep* concern with carrying state in
> a "key" variable: it's a direct attack vector for a crowbar attack,
> especially since it is by definition live inside a user access region."

> This patch minimises the change by just adding user_read_access_begin() and
> user_write_access_begin() keeping the same parameters as the existing
> user_access_begin().

Umm... What about the arm situation? The same concerns would apply there,
wouldn't they? Currently we have
static __always_inline unsigned int uaccess_save_and_enable(void)
unsigned int old_domain = get_domain();

/* Set the current domain access to permit user accesses */
set_domain((old_domain & ~domain_mask(DOMAIN_USER)) |

return old_domain;
return 0;
static __always_inline void uaccess_restore(unsigned int flags)
/* Restore the user access mask */

How much do we need nesting on those, anyway? rmk?

 \ /
  Last update: 2020-04-02 19:51    [W:0.086 / U:2.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site