All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicoleotsuka@gmail.com (Nicolin Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT
Date: Wed, 17 Jan 2018 12:41:56 -0800	[thread overview]
Message-ID: <20180117204154.GA2935@Asurada-Nvidia> (raw)
In-Reply-To: <83b9c187-7fbf-3e05-6321-de7fa05fd868@arm.com>

On Wed, Jan 17, 2018 at 09:03:48AM +0000, Marc Zyngier wrote:

> > So ignoring a condition for a Thumb instruction may cause its IT
> > scope shifting. For ARM mode, the only penalty could be two Rts
> > getting written -- which shouldn't corrupt userspace execution.
> > 
> > Please correct me if I am wrong or not thorough.
> 
> Consider the following:
> 	
> 	mov	r0, #0
> 	mov	r1, #0
> 	cmp	r1, #3
> 	mrrceq	r0, r1, cntvct // simplified version
> 
> Oh look, you've corrupted r0 and r1, which should never have be changed.
> Whatever uses the content r0 and r1 after the mrrc will misbehave. How
> is that an acceptable behaviour? How do you expect userspace to cope
> with such a brain damage?
> 
> If you intend to emulate the CPU, you must emulate it fully, to the
> letter of the architecture. No ifs, no buts.

Thanks for the explain. I see the point here.

I saw your version for arm64 compat doesn't check if (rt != 31)
as MRS handler does. Is there any reason for that?

Thank you
Nicolin

WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
	will.deacon@arm.com, oleg@redhat.com, cdall@linaro.org,
	tbaicar@codeaurora.org, julien.thierry@arm.com,
	Dave.Martin@arm.com, robin.murphy@arm.com, james.morse@arm.com,
	ard.biesheuvel@linaro.org, xiexiuqi@huawei.com, mingo@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT
Date: Wed, 17 Jan 2018 12:41:56 -0800	[thread overview]
Message-ID: <20180117204154.GA2935@Asurada-Nvidia> (raw)
In-Reply-To: <83b9c187-7fbf-3e05-6321-de7fa05fd868@arm.com>

On Wed, Jan 17, 2018 at 09:03:48AM +0000, Marc Zyngier wrote:

> > So ignoring a condition for a Thumb instruction may cause its IT
> > scope shifting. For ARM mode, the only penalty could be two Rts
> > getting written -- which shouldn't corrupt userspace execution.
> > 
> > Please correct me if I am wrong or not thorough.
> 
> Consider the following:
> 	
> 	mov	r0, #0
> 	mov	r1, #0
> 	cmp	r1, #3
> 	mrrceq	r0, r1, cntvct // simplified version
> 
> Oh look, you've corrupted r0 and r1, which should never have be changed.
> Whatever uses the content r0 and r1 after the mrrc will misbehave. How
> is that an acceptable behaviour? How do you expect userspace to cope
> with such a brain damage?
> 
> If you intend to emulate the CPU, you must emulate it fully, to the
> letter of the architecture. No ifs, no buts.

Thanks for the explain. I see the point here.

I saw your version for arm64 compat doesn't check if (rt != 31)
as MRS handler does. Is there any reason for that?

Thank you
Nicolin

  reply	other threads:[~2018-01-17 20:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11  4:43 [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT Nicolin Chen
2018-01-11  4:43 ` Nicolin Chen
2018-01-11  8:51 ` Marc Zyngier
2018-01-11  8:51   ` Marc Zyngier
2018-01-16 20:32   ` Nicolin Chen
2018-01-16 21:19     ` Marc Zyngier
2018-01-16 21:37       ` Nicolin Chen
2018-01-17  2:13         ` Nicolin Chen
2018-01-17  2:13           ` Nicolin Chen
2018-01-17  9:03           ` Marc Zyngier
2018-01-17  9:03             ` Marc Zyngier
2018-01-17 20:41             ` Nicolin Chen [this message]
2018-01-17 20:41               ` Nicolin Chen
2018-01-17 23:35               ` Robin Murphy
2018-01-17 23:35                 ` Robin Murphy
2018-01-17 23:39                 ` Nicolin Chen
2018-01-17 23:39                   ` Nicolin Chen

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=20180117204154.GA2935@Asurada-Nvidia \
    --to=nicoleotsuka@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.