search for: addr_limit

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()

...ally should have removed those double-underscore things ages ago. FWIW, on arm64 we always check/sanitize the user address as a result of our sanitization of speculated values. Almost all of our uaccess routines have an explicit access_ok(). All our uaccess routines mask the user pointer based on addr_limit, which prevents speculative or architectural uaccess to kernel addresses when addr_limit it USER_DS: 4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation") We also inhibit speculative stores to addr_limit being forwarded under speculation: c2f0ad4fc089cff8...

...double-underscore things ages ago. > > FWIW, on arm64 we always check/sanitize the user address as a result of > our sanitization of speculated values. Almost all of our uaccess > routines have an explicit access_ok(). > > All our uaccess routines mask the user pointer based on addr_limit, > which prevents speculative or architectural uaccess to kernel addresses > when addr_limit it USER_DS: > > 4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation") > > We also inhibit speculative stores to addr_limit being forwarded under >...

...double-underscore things ages ago. > > FWIW, on arm64 we always check/sanitize the user address as a result of > our sanitization of speculated values. Almost all of our uaccess > routines have an explicit access_ok(). > > All our uaccess routines mask the user pointer based on addr_limit, > which prevents speculative or architectural uaccess to kernel addresses > when addr_limit it USER_DS: > > 4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation") > > We also inhibit speculative stores to addr_limit being forwarded under >...

...> > Don't you take over the VM with "use_mm()" when you do the copies? So > yes, it's a kernel thread, but it has a user VM, and though that > should have the user limits. Oooh. *Just* as I sent this, I realized that "use_mm()" doesn't update the thread addr_limit. That actually looks like a bug to me - although one that you've apparently been aware of and worked around. Wouldn't it be nicer to just make "use_mm()" do set_fs(USER_DS); instead? And undo it on unuse_mm()? And, in fact, maybe we should default kernel threads to ha...

On Fri, Nov 02, 2018 at 09:14:51AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 6:04 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > I've tried making access_ok mask the parameter it gets. > > PLEASE don't do this. Okay. > Just use "copy_to/from_user()". Just for completeness I'd like to point out for vhost the copies are

On Fri, Nov 02, 2018 at 09:14:51AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 6:04 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > I've tried making access_ok mask the parameter it gets. > > PLEASE don't do this. Okay. > Just use "copy_to/from_user()". Just for completeness I'd like to point out for vhost the copies are

...\ ({ \ WARN_ON_IN_IRQ(); \ likely(!__range_not_ok(addr, size, user_addr_max())); \ }) and #define user_addr_max() (current->thread.addr_limit.seg) it seems that it depends on current not on the active mm. get_user and friends are similar: ENTRY(__get_user_1) mov PER_CPU_VAR(current_task), %_ASM_DX cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX jae bad_get_user sbb %_ASM_DX, %_ASM_DX /* array_index_mask...

...\ ({ \ WARN_ON_IN_IRQ(); \ likely(!__range_not_ok(addr, size, user_addr_max())); \ }) and #define user_addr_max() (current->thread.addr_limit.seg) it seems that it depends on current not on the active mm. get_user and friends are similar: ENTRY(__get_user_1) mov PER_CPU_VAR(current_task), %_ASM_DX cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX jae bad_get_user sbb %_ASM_DX, %_ASM_DX /* array_index_mask...

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

...++++++++++++++++++- arch/i386/xen/xen-ops.h | 1 5 files changed, 199 insertions(+), 5 deletions(-) =================================================================== --- a/arch/i386/kernel/asm-offsets.c +++ b/arch/i386/kernel/asm-offsets.c @@ -65,6 +65,7 @@ void foo(void) OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); OFFSET(TI_sysenter_return, thread_info, sysenter_return); + OFFSET(TI_cpu, thread_info, cpu); BLANK(); OFFSET(GDS_size, Xgt_desc_struct, size); ================================================================...

...++++++++++++++++++- arch/i386/xen/xen-ops.h | 1 5 files changed, 199 insertions(+), 5 deletions(-) =================================================================== --- a/arch/i386/kernel/asm-offsets.c +++ b/arch/i386/kernel/asm-offsets.c @@ -65,6 +65,7 @@ void foo(void) OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); OFFSET(TI_sysenter_return, thread_info, sysenter_return); + OFFSET(TI_cpu, thread_info, cpu); BLANK(); OFFSET(GDS_size, Xgt_desc_struct, size); ================================================================...

...++++++++++++++++++- arch/i386/xen/xen-ops.h | 1 5 files changed, 181 insertions(+), 5 deletions(-) =================================================================== --- a/arch/i386/kernel/asm-offsets.c +++ b/arch/i386/kernel/asm-offsets.c @@ -65,6 +65,7 @@ void foo(void) OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); OFFSET(TI_sysenter_return, thread_info, sysenter_return); + OFFSET(TI_cpu, thread_info, cpu); BLANK(); OFFSET(GDS_size, Xgt_desc_struct, size); ================================================================...

...++++++++++++++++++- arch/i386/xen/xen-ops.h | 1 5 files changed, 181 insertions(+), 5 deletions(-) =================================================================== --- a/arch/i386/kernel/asm-offsets.c +++ b/arch/i386/kernel/asm-offsets.c @@ -65,6 +65,7 @@ void foo(void) OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); OFFSET(TI_sysenter_return, thread_info, sysenter_return); + OFFSET(TI_cpu, thread_info, cpu); BLANK(); OFFSET(GDS_size, Xgt_desc_struct, size); ================================================================...

...++++++++++++++++++- arch/i386/xen/xen-ops.h | 1 5 files changed, 181 insertions(+), 5 deletions(-) =================================================================== --- a/arch/i386/kernel/asm-offsets.c +++ b/arch/i386/kernel/asm-offsets.c @@ -65,6 +65,7 @@ void foo(void) OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); OFFSET(TI_sysenter_return, thread_info, sysenter_return); + OFFSET(TI_cpu, thread_info, cpu); BLANK(); OFFSET(GDS_size, Xgt_desc_struct, size); ================================================================...

...0-linux-2.6.17-rc4-git3/arch/i386/kernel/asm-offsets.c 2005-07-15 04:38:36.000000000 +1000 +++ .23560-linux-2.6.17-rc4-git3.updated/arch/i386/kernel/asm-offsets.c 2006-05-17 17:10:49.000000000 +1000 @@ -53,6 +53,7 @@ void foo(void) OFFSET(TI_preempt_count, thread_info, preempt_count); OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); + OFFSET(TI_sysenter_return, thread_info, sysenter_return); BLANK(); OFFSET(EXEC_DOMAIN_handler, exec_domain, handler); @@ -68,5 +69,4 @@ void foo(void) sizeof(struct tss_struct)); DEFINE(PAGE_SIZE_asm,...

...0-linux-2.6.17-rc4-git3/arch/i386/kernel/asm-offsets.c 2005-07-15 04:38:36.000000000 +1000 +++ .23560-linux-2.6.17-rc4-git3.updated/arch/i386/kernel/asm-offsets.c 2006-05-17 17:10:49.000000000 +1000 @@ -53,6 +53,7 @@ void foo(void) OFFSET(TI_preempt_count, thread_info, preempt_count); OFFSET(TI_addr_limit, thread_info, addr_limit); OFFSET(TI_restart_block, thread_info, restart_block); + OFFSET(TI_sysenter_return, thread_info, sysenter_return); BLANK(); OFFSET(EXEC_DOMAIN_handler, exec_domain, handler); @@ -68,5 +69,4 @@ void foo(void) sizeof(struct tss_struct)); DEFINE(PAGE_SIZE_asm,...

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