Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Balbir Singh <bsingharora@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Eugene Syromiatnikov <esyr@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <keescook@chromium.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>,
	Dave Martin <Dave.Martin@arm.com>
Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
Date: Fri, 7 Jun 2019 10:05:13 -0700
Message-ID: <A495EEB4-F05F-4AB3-831A-0F15B912A7EC@amacapital.net> (raw)
In-Reply-To: <ac8827d7b516f4b58e1df20f45b94998d36c418c.camel@intel.com>




> On Jun 7, 2019, at 9:45 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> 
> On Fri, 2019-06-07 at 09:35 -0700, Andy Lutomirski wrote:
>>> On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>>> 
>>>>> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
>>>>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
>>>>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
>>>>> that allows execution of legacy, non-IBT compatible library by an
>>>>> IBT-enabled application.  When set, each bit in the bitmap indicates
>>>>> one page of legacy code.
>>>>> 
>>>>> The bitmap is allocated and setup from the application.
>>>>> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
>>>>> +{
>>>>> +    u64 r;
>>>>> +
>>>>> +    if (!current->thread.cet.ibt_enabled)
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    current->thread.cet.ibt_bitmap_addr = bitmap;
>>>>> +    current->thread.cet.ibt_bitmap_size = size;
>>>>> +
>>>>> +    /*
>>>>> +     * Turn on IBT legacy bitmap.
>>>>> +     */
>>>>> +    modify_fpu_regs_begin();
>>>>> +    rdmsrl(MSR_IA32_U_CET, r);
>>>>> +    r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
>>>>> +    wrmsrl(MSR_IA32_U_CET, r);
>>>>> +    modify_fpu_regs_end();
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>> 
>>>> So you just program a random user supplied address into the hardware.
>>>> What happens if there's not actually anything at that address or the
>>>> user munmap()s the data after doing this?
>>> 
>>> This function checks the bitmap's alignment and size, and anything else is
>>> the
>>> app's responsibility.  What else do you think the kernel should check?
>>> 
>> 
>> One might reasonably wonder why this state is privileged in the first place
>> and, given that, why we’re allowing it to be written like this.
>> 
>> Arguably we should have another prctl to lock these values (until exec) as a
>> gardening measure.
> 
> We can prevent the bitmap from being set more than once.  I will test it.
> 

I think it would be better to make locking an explicit opt-in.

  reply index

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 20:09 [PATCH v7 00/14] Control-flow Enforcement: Branch Tracking, PTRACE Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 01/14] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 02/14] x86/cet/ibt: User-mode indirect branch tracking support Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Yu-cheng Yu
2019-06-07  8:08   ` Peter Zijlstra
2019-06-07 16:23     ` Yu-cheng Yu
2019-06-07 16:35       ` Andy Lutomirski
2019-06-07 16:39         ` Dave Hansen
2019-06-07 16:45         ` Yu-cheng Yu
2019-06-07 17:05           ` Andy Lutomirski [this message]
2019-06-07 17:43       ` Peter Zijlstra
2019-06-07 17:59         ` Dave Hansen
2019-06-07 18:29           ` Andy Lutomirski
2019-06-07 18:58             ` Dave Hansen
2019-06-07 19:56               ` Yu-cheng Yu
2019-06-07 20:40               ` Andy Lutomirski
2019-06-07 21:05                 ` Dave Hansen
2019-06-07 19:49             ` Yu-cheng Yu
2019-06-07 20:00               ` Dave Hansen
2019-06-07 20:06                 ` Yu-cheng Yu
2019-06-07 21:09                   ` Dave Hansen
2019-06-07 22:27                     ` Andy Lutomirski
2019-06-10 16:03                       ` Yu-cheng Yu
2019-06-10 16:05                     ` Yu-cheng Yu
2019-06-10 17:28                       ` Florian Weimer
2019-06-10 17:59                       ` Dave Hansen
2019-06-07 20:43               ` Andy Lutomirski
2019-06-10 15:22                 ` Yu-cheng Yu
2019-06-10 18:02                   ` Dave Hansen
2019-06-10 19:38                     ` Yu-cheng Yu
2019-06-10 19:52                       ` Dave Hansen
2019-06-10 19:55                         ` Andy Lutomirski
2019-06-10 20:27                         ` Yu-cheng Yu
2019-06-10 20:43                           ` Dave Hansen
2019-06-10 20:58                             ` Yu-cheng Yu
2019-06-10 22:02                               ` Dave Hansen
2019-06-10 22:40                                 ` Yu-cheng Yu
2019-06-10 22:59                                   ` Dave Hansen
2019-06-10 23:20                                     ` H.J. Lu
2019-06-10 23:37                                       ` Dave Hansen
2019-06-10 23:54                                     ` Andy Lutomirski
2019-06-11  0:08                                       ` Dave Hansen
2019-06-11  0:36                                         ` Andy Lutomirski
2019-06-14 15:25                                     ` Yu-cheng Yu
2019-06-14 16:13                                       ` Dave Hansen
2019-06-14 17:13                                         ` Yu-cheng Yu
2019-06-14 20:57                                           ` Dave Hansen
2019-06-14 21:34                                             ` Yu-cheng Yu
2019-06-14 22:06                                               ` Dave Hansen
2019-06-15 15:30                                                 ` Andy Lutomirski
2019-06-11  7:24                                 ` Florian Weimer
2019-06-08 20:52           ` Pavel Machek
2019-06-10 15:47             ` Yu-cheng Yu
2019-06-11 10:33               ` Pavel Machek
2019-06-07 19:03   ` Dave Hansen
2019-06-07 19:23     ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 04/14] x86/cet/ibt: Handle signals for IBT Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 05/14] mm/mmap: Add IBT bitmap size to address space limit check Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 06/14] x86/cet/ibt: ELF header parsing for IBT Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 07/14] x86/cet/ibt: Add arch_prctl functions " Yu-cheng Yu
2019-06-07  8:07   ` Peter Zijlstra
2019-06-06 20:09 ` [PATCH v7 08/14] x86/cet/ibt: Add ENDBR to op-code-map Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 09/14] x86/vdso: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2019-06-06 20:26   ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 10/14] x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point Yu-cheng Yu
2019-06-06 20:25   ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 11/14] x86/vsyscall/64: Add ENDBR64 to vsyscall entry points Yu-cheng Yu
2019-06-06 20:28   ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 12/14] x86/vsyscall/64: Fixup shadow stack and branch tracking for vsyscall Yu-cheng Yu
2019-06-06 20:27   ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 13/14] x86/cet: Add PTRACE interface for CET Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 14/14] x86: Discard .note.gnu.property sections Yu-cheng Yu

Reply instructions:

You may reply publically 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=A495EEB4-F05F-4AB3-831A-0F15B912A7EC@amacapital.net \
    --to=luto@amacapital.net \
    --cc=Dave.Martin@arm.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=bsingharora@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=esyr@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vedvyas.shanbhogue@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org linux-mm@archiver.kernel.org
	public-inbox-index linux-mm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox