search for: __chk_user_ptr

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- Changes from v2: https://lore.kernel.org/virtualization/20230410074929-mutt-send-email-mst at kernel.org/ - Fix a typo of commit title include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h index 8b95b69ef694..77a9c2f52919 100644 --- a/include/linux/virtio_ring.h +++ b/include/linux/virtio_ring.h @@ -58,6

...ndef UACCESS_H > #define UACCESS_H > -extern void *__user_addr_min, *__user_addr_max; > > -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) > +#include <linux/compiler.h> > + > +extern void *__user_addr_min, *__user_addr_max; > > static inline void __chk_user_ptr(const volatile void *p, size_t size) > { > @@ -13,7 +14,7 @@ static inline void __chk_user_ptr(const volatile void *p, size_t size) > ({ \ > typeof(ptr) __pu_ptr = (ptr); \ > __chk_user_ptr(__pu_ptr, sizeof(*__pu_ptr)); \ > - ACCESS_ONCE(*(__pu_ptr)) = x; \...

...tools/virtio/linux/uaccess.h @@ -1,8 +1,9 @@ #ifndef UACCESS_H #define UACCESS_H -extern void *__user_addr_min, *__user_addr_max; -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) +#include <linux/compiler.h> + +extern void *__user_addr_min, *__user_addr_max; static inline void __chk_user_ptr(const volatile void *p, size_t size) { @@ -13,7 +14,7 @@ static inline void __chk_user_ptr(const volatile void *p, size_t size) ({ \ typeof(ptr) __pu_ptr = (ptr); \ __chk_user_ptr(__pu_ptr, sizeof(*__pu_ptr)); \ - ACCESS_ONCE(*(__pu_ptr)) = x; \ + WRITE_ONCE(*(__pu_ptr), x);...

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

...io/linux/uaccess.h > > index 991dfb263998..cde2c344b260 100644 > > --- a/tools/virtio/linux/uaccess.h > > +++ b/tools/virtio/linux/uaccess.h > > @@ -6,15 +6,10 @@ > > > > extern void *__user_addr_min, *__user_addr_max; > > > > -static inline void __chk_user_ptr(const volatile void *p, size_t size) > > -{ > > - assert(p >= __user_addr_min && p + size <= __user_addr_max); > > -} > > - What does this function have to do with container_of()? > > #define put_user(x, ptr) \ > > ({ \ > > t...

...7 +154,7 @@ extern int __get_user_bad(void); #define get_user(x, ptr) \ ({ \ - int __ret_gu; \ + unsigned long __ret_gu; \ unsigned long __val_gu; \ __chk_user_ptr(ptr); \ might_fault(); \ @@ -176,7 +176,7 @@ extern int __get_user_bad(void); break; \ } \ (x) = (__typeof__(*(ptr)))__val_gu; \ - __ret_gu;...

...ad(void); > > #define get_user(x, ptr) \ > ({ \ > - int __ret_gu; \ > + unsigned long __ret_gu; \ > unsigned long __val_gu; \ > __chk_user_ptr(ptr); \ > might_fault(); \ > @@ -176,7 +176,7 @@ extern int __get_user_bad(void); > break; \ > } \ > (x) = (__typeof__(*(ptr)))__val_gu;...

...? In the new patch below I used (void)-EFAULT so that you would get an error at compile time (as suggested in __builtin_choose_expr in gcc's manual), if that branch would ever get expanded. Does that sound right? > >> __typeof__(*(ptr)) __pu_val; \ >> __chk_user_ptr(ptr); \ >> might_fault(); \ >> __pu_val = x; \ >> + /* return value is 0 or -EFAULT, both fit in 1 byte, and \ >> + * are sign-extendable to int */ \ >> switch (size...

...uot;=a" (__ret_pu) \ :"0" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx") #define put_user(x, ptr) \ ({ \ int __ret_pu; \ __typeof__(*(ptr)) __pu_val; \ __chk_user_ptr(ptr); \ __pu_val = x; \ switch (sizeof(*(ptr))) { \ case 1: \ __put_user_x(1, __pu_val, ptr, __ret_pu); \ break; \ case 2: \...

On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: > > one thing that seems to be clear to everyone except me is... what > > are the > > semantics supposed to be? > > I don't know of any other semantic other than, if they are supposed to > be in the same register, then they have to be in the same register.

...Note that, depending on architecture, this function probably just + * checks that the pointer is in the user space range - after calling + * this function, memory access functions may still return -EFAULT. + */ +#define access_ok_nospec(type, addr, size) \ +({ \ + WARN_ON_IN_IRQ(); \ + __chk_user_ptr(addr); \ + addr = (typeof(addr) __force) \ + __verify_range_nospec((unsigned long __force)(addr), \ + size, user_addr_max()); \ +}) + +#define access_ok(type, addr, size) access_ok_nospec(type, addr, size) + /* * These are the main single-value transfer routines. They automatic...

...Note that, depending on architecture, this function probably just + * checks that the pointer is in the user space range - after calling + * this function, memory access functions may still return -EFAULT. + */ +#define access_ok_nospec(type, addr, size) \ +({ \ + WARN_ON_IN_IRQ(); \ + __chk_user_ptr(addr); \ + addr = (typeof(addr) __force) \ + __verify_range_nospec((unsigned long __force)(addr), \ + size, user_addr_max()); \ +}) + +#define access_ok(type, addr, size) access_ok_nospec(type, addr, size) + /* * These are the main single-value transfer routines. They automatic...

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook <keescook at chromium.org> wrote: > > + memset(&rsp, 0, sizeof(rsp)); > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > + resp = vq->iov[out].iov_base; > + ret = __copy_to_user(resp, &rsp, sizeof(rsp)); > > Is it actually safe to trust that iov_base has passed an earlier > access_ok()

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook <keescook at chromium.org> wrote: > > + memset(&rsp, 0, sizeof(rsp)); > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > + resp = vq->iov[out].iov_base; > + ret = __copy_to_user(resp, &rsp, sizeof(rsp)); > > Is it actually safe to trust that iov_base has passed an earlier > access_ok()

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel