netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	Will Deacon <will.deacon@arm.com>,
	Mircea Gherzan <mgherzan@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Alexei Starovoitov <ast@plumgrid.com>
Subject: Re: [PATCH net-next] net: bpf: arm: make hole-faulting more robust
Date: Fri, 19 Sep 2014 00:11:54 +0100	[thread overview]
Message-ID: <20140918231154.GH5182@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1411081023-17874-1-git-send-email-dborkman@redhat.com>

On Fri, Sep 19, 2014 at 12:57:03AM +0200, Daniel Borkmann wrote:
> Will Deacon pointed out, that the currently used opcode for filling holes,
> that is 0xe7ffffff, seems not robust enough ...

If you're after a single 32-bit word which will fault if executed in
ARM or Thumb mode, and you only want it to raise an undefined
instruction exception (iow, you're not using it as a breakpoint or
similar), then may I suggest the poison value I chose for the vectors
page, designed to trap userspace branches to locations in there?

0xe7fddef1

> Similarly, ptrace, kprobes, kgdb, bug and uprobes make use of such instruction
> as well to trap. Given mentioned section from the specification, we can find
> such a universe as (where 'x' denotes 'don't care'):
> 
>   ARM:    xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
>   Thumb:  1101 1110 xxxx xxxx

You'll notice that the value conforms to the ARM undefined instruction
space.  You'll also notice that the low 16 bits correspond to the
Thumb case.  The only question is, what is 0xe7fd as a Thumb instruction...

00000000 <a>:
   0:   def1                            ; <UNDEFINED> instruction: 0xdef1
   2:   e7fd            b.n     0 <a>

So, if either 0 or 2 gets branched to, we end up at the Thumb UDF
instruction.  (Sorry, my binutils doesn't know about UDF.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2014-09-18 23:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 22:57 [PATCH net-next] net: bpf: arm: make hole-faulting more robust Daniel Borkmann
2014-09-18 23:11 ` Russell King - ARM Linux [this message]
2014-09-18 23:20   ` Daniel Borkmann

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=20140918231154.GH5182@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=ast@plumgrid.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mgherzan@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).