All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
Date: Sun, 29 May 2016 12:08:29 -0700	[thread overview]
Message-ID: <CALCETrVg_LeHu3iCa-yGT6NubF6Vxo338wfytG-jWa0_+mmgmg@mail.gmail.com> (raw)
In-Reply-To: <e1454076-faac-47d1-823f-416950c22e28@email.android.com>

On May 29, 2016 11:42 AM, "Boris Petkov" <bp@alien8.de> wrote:
>
> Andy Lutomirski <luto@amacapital.net> wrote:
> >Easier said than done.  struct thread_info doesn't have addr_limit on
> >sensible architectures (e.g. sparc), and I'd rather not stick a bunch
> >of ifdefs in generic code.
>
> It's not like it doesn't have an actual address limit though - I'm guessing it is something like the max userspace address on the arch... UINT_MAX or somesuch.

Sure, but how do I implement that?  There's no "does this arch have
addr_limit in thread_info" general flag that I know of.

--Andy

  reply	other threads:[~2016-05-29 19:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24 22:48 [PATCH 0/7] x86: uaccess hardening, easy part Andy Lutomirski
2016-05-24 22:48 ` [PATCH 1/7] x86/xen: Simplify set_aliased_prot Andy Lutomirski
2016-05-25  9:38   ` Andrew Cooper
2016-05-25  9:38   ` Andrew Cooper
2016-05-25  9:50   ` David Vrabel
2016-05-25  9:50   ` [Xen-devel] " David Vrabel
2016-06-10 22:12     ` Andy Lutomirski
2016-06-11  9:29       ` Ingo Molnar
2016-06-11  9:29       ` [Xen-devel] " Ingo Molnar
2016-06-10 22:12     ` Andy Lutomirski
2016-06-11  9:34   ` [tip:x86/asm] x86/xen: Simplify set_aliased_prot() tip-bot for Andy Lutomirski
2016-06-11  9:34   ` tip-bot for Andy Lutomirski
2016-05-24 22:48 ` [PATCH 1/7] x86/xen: Simplify set_aliased_prot Andy Lutomirski
2016-05-24 22:48 ` [PATCH 2/7] x86/extable: Pass error_code and an extra unsigned long to exhandlers Andy Lutomirski
2016-05-24 22:48 ` [PATCH 3/7] x86/uaccess: Give uaccess faults their own handler Andy Lutomirski
2016-05-24 22:48 ` [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski
2016-05-25 11:32   ` Borislav Petkov
2016-05-29 16:44     ` Andy Lutomirski
2016-05-25 11:39   ` Borislav Petkov
2016-05-29 16:47     ` Andy Lutomirski
2016-05-29 18:42       ` Boris Petkov
2016-05-29 19:08         ` Andy Lutomirski [this message]
2016-05-30  7:40           ` Borislav Petkov
2016-05-24 22:48 ` [PATCH 5/7] x86/uaccess: Warn on uaccess faults other than #PF Andy Lutomirski
2016-05-25  9:49   ` Borislav Petkov
2016-05-29 16:42     ` Andy Lutomirski
2016-05-24 22:48 ` [PATCH 6/7] x86/uaccess: Don't fix up USER_DS uaccess faults to kernel addresses Andy Lutomirski
2016-05-24 22:48 ` [PATCH 7/7] x86/uaccess: OOPS or warn on a fault with KERNEL_DS and !pagefault_disabled() Andy Lutomirski
2016-05-25 15:33   ` Borislav Petkov
2016-05-29 16:52     ` Andy Lutomirski
2016-05-25  3:55 ` [PATCH 0/7] x86: uaccess hardening, easy part Brian Gerst
2016-05-25 17:19   ` Kees Cook
2016-05-25 17:31 ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALCETrVg_LeHu3iCa-yGT6NubF6Vxo338wfytG-jWa0_+mmgmg@mail.gmail.com \
    --to=luto@amacapital.net \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.