All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: <linux-mips@linux-mips.org>, <Zubair.Kakakhel@imgtec.com>,
	<david.daney@cavium.com>, <peterz@infradead.org>,
	<paul.gortmaker@windriver.com>, <davidlohr@hp.com>,
	<macro@linux-mips.org>, <chenhc@lemote.com>, <zajec5@gmail.com>,
	<james.hogan@imgtec.com>, <keescook@chromium.org>,
	<alex@alex-smith.me.uk>, <tglx@linutronix.de>,
	<blogic@openwrt.org>, <jchandra@broadcom.com>,
	<qais.yousef@imgtec.com>, <linux-kernel@vger.kernel.org>,
	<ralf@linux-mips.org>, <markos.chandras@imgtec.com>,
	<manuel.lauss@gmail.com>, <akpm@linux-foundation.org>,
	<lars.persson@axis.com>
Subject: Re: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack
Date: Mon, 6 Oct 2014 13:42:32 -0700	[thread overview]
Message-ID: <5432FEB8.401@imgtec.com> (raw)
In-Reply-To: <20141006122917.GB4704@pburton-laptop>

On 10/06/2014 05:29 AM, Paul Burton wrote:

>>
>> First some general questions: is there any reason to need the page used
>> to be at the same virtual address for each thread? I can't think of one,
>> and if that's the case then why not simply allocate a series of pages
>> per-thread via mmap_region or similar, on demand when a thread first
>> executes an FP branch instruction? That would of course consume some
>> more virtual address space, but would avoid the hassles of manually
>> prodding at the TLB, tracking ASIDs & flushing the caches. Perhaps the
>> shrinker interface could be used to allow freeing those pages if & when
>> it becomes necessary for long running threads.
The only reason to have the same virtual address is to keep mmap 
accounting the same. An original 'VDSO' is presented in mmap for all 
threads of the same mmap.

As for another approach, I think it may be too much code to handle it 
and too much implicit interlinks with common Linux code and GLIBC/bionic.

>>
>> Also VDSO is really a misnomer throughout, as I've pointed out to you
>> before. I'm aware it's an existing misnomer, but it would be nice if
>> we could clear that up rather than repeat it...
>>
Yes, I agree but that is outside of this patch. I think it has sense to 
rename the current stuff to something like "Emulation" right before some 
patch which implement the real VDSO capability on MIPS.

>> +		if (get_isa16_mode(regs->cp0_epc)) {
>> +			*(u16 *)&fr->emul = (u16)(ir >> 16);
>> +			*((u16 *)(&fr->emul) + 1) = (u16)(ir & 0xffff);
> This microMIPS case doesn't set badinst, as I pointed out internally.
Thank you, I missed it, may be due to long citation. I will add it.

>   I
> think it would be much cleaner if you were to do something along the
> lines of:
>
I try to keep it as close as an original code for better understanding. 
Even with it there are questions.

Your variant may be cleaner but it may be some next style change patch.

- Leonid.

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org, Zubair.Kakakhel@imgtec.com,
	david.daney@cavium.com, peterz@infradead.org,
	paul.gortmaker@windriver.com, davidlohr@hp.com,
	macro@linux-mips.org, chenhc@lemote.com, zajec5@gmail.com,
	james.hogan@imgtec.com, keescook@chromium.org,
	alex@alex-smith.me.uk, tglx@linutronix.de, blogic@openwrt.org,
	jchandra@broadcom.com, qais.yousef@imgtec.com,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	markos.chandras@imgtec.com, manuel.lauss@gmail.com,
	akpm@linux-foundation.org, lars.persson@axis.com
Subject: Re: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack
Date: Mon, 6 Oct 2014 13:42:32 -0700	[thread overview]
Message-ID: <5432FEB8.401@imgtec.com> (raw)
Message-ID: <20141006204232.n4H7SiR9AFHBFlHWCuL7wia8nfkrpoAMt-6ZDv_QjQo@z> (raw)
In-Reply-To: <20141006122917.GB4704@pburton-laptop>

On 10/06/2014 05:29 AM, Paul Burton wrote:

>>
>> First some general questions: is there any reason to need the page used
>> to be at the same virtual address for each thread? I can't think of one,
>> and if that's the case then why not simply allocate a series of pages
>> per-thread via mmap_region or similar, on demand when a thread first
>> executes an FP branch instruction? That would of course consume some
>> more virtual address space, but would avoid the hassles of manually
>> prodding at the TLB, tracking ASIDs & flushing the caches. Perhaps the
>> shrinker interface could be used to allow freeing those pages if & when
>> it becomes necessary for long running threads.
The only reason to have the same virtual address is to keep mmap 
accounting the same. An original 'VDSO' is presented in mmap for all 
threads of the same mmap.

As for another approach, I think it may be too much code to handle it 
and too much implicit interlinks with common Linux code and GLIBC/bionic.

>>
>> Also VDSO is really a misnomer throughout, as I've pointed out to you
>> before. I'm aware it's an existing misnomer, but it would be nice if
>> we could clear that up rather than repeat it...
>>
Yes, I agree but that is outside of this patch. I think it has sense to 
rename the current stuff to something like "Emulation" right before some 
patch which implement the real VDSO capability on MIPS.

>> +		if (get_isa16_mode(regs->cp0_epc)) {
>> +			*(u16 *)&fr->emul = (u16)(ir >> 16);
>> +			*((u16 *)(&fr->emul) + 1) = (u16)(ir & 0xffff);
> This microMIPS case doesn't set badinst, as I pointed out internally.
Thank you, I missed it, may be due to long citation. I will add it.

>   I
> think it would be much cleaner if you were to do something along the
> lines of:
>
I try to keep it as close as an original code for better understanding. 
Even with it there are questions.

Your variant may be cleaner but it may be some next style change patch.

- Leonid.

  reply	other threads:[~2014-10-06 20:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-04  3:17 [PATCH 0/3] MIPS executable stack protection Leonid Yegoshin
2014-10-04  3:17 ` Leonid Yegoshin
2014-10-04  3:17 ` [PATCH 1/3] MIPS: mips_flush_cache_range is added Leonid Yegoshin
2014-10-04  3:17   ` Leonid Yegoshin
2014-10-04  3:17 ` [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack Leonid Yegoshin
2014-10-04  3:17   ` Leonid Yegoshin
2014-10-04 20:00   ` Peter Zijlstra
2014-10-05  5:52     ` Leonid Yegoshin
2014-10-06 12:29   ` Paul Burton
2014-10-06 12:29     ` Paul Burton
2014-10-06 20:42     ` Leonid Yegoshin [this message]
2014-10-06 20:42       ` Leonid Yegoshin
2014-10-06 18:05   ` David Daney
2014-10-06 20:03     ` Leonid Yegoshin
2014-10-06 20:03       ` Leonid Yegoshin
2014-10-04  3:17 ` [PATCH 3/3] MIPS: set stack/data protection as non-executable Leonid Yegoshin
2014-10-04  3:17   ` Leonid Yegoshin
2014-10-04  8:23 ` [PATCH 0/3] MIPS executable stack protection Peter Zijlstra
2014-10-04 16:03   ` Linus Torvalds
2014-10-04 16:17     ` Leonid Yegoshin
2014-10-04 16:27       ` Linus Torvalds

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=5432FEB8.401@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@alex-smith.me.uk \
    --cc=blogic@openwrt.org \
    --cc=chenhc@lemote.com \
    --cc=david.daney@cavium.com \
    --cc=davidlohr@hp.com \
    --cc=james.hogan@imgtec.com \
    --cc=jchandra@broadcom.com \
    --cc=keescook@chromium.org \
    --cc=lars.persson@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    --cc=markos.chandras@imgtec.com \
    --cc=paul.burton@imgtec.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@imgtec.com \
    --cc=ralf@linux-mips.org \
    --cc=tglx@linutronix.de \
    --cc=zajec5@gmail.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
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.