From: dborkman@redhat.com (Daniel Borkmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH net-next] net: bpf: arm: make hole-faulting more robust
Date: Fri, 19 Sep 2014 01:20:18 +0200 [thread overview]
Message-ID: <541B68B2.80905@redhat.com> (raw)
In-Reply-To: <20140918231154.GH5182@n2100.arm.linux.org.uk>
On 09/19/2014 01:11 AM, Russell King - ARM Linux wrote:
> 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.)
Yes, that should keep the code even simpler! Will try that out tomorrow
and respin the patch.
Thanks Russell!
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <dborkman@redhat.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
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 01:20:18 +0200 [thread overview]
Message-ID: <541B68B2.80905@redhat.com> (raw)
In-Reply-To: <20140918231154.GH5182@n2100.arm.linux.org.uk>
On 09/19/2014 01:11 AM, Russell King - ARM Linux wrote:
> 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.)
Yes, that should keep the code even simpler! Will try that out tomorrow
and respin the patch.
Thanks Russell!
next prev parent reply other threads:[~2014-09-18 23:20 UTC|newest]
Thread overview: 6+ 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 22:57 ` Daniel Borkmann
2014-09-18 23:11 ` Russell King - ARM Linux
2014-09-18 23:11 ` Russell King - ARM Linux
2014-09-18 23:20 ` Daniel Borkmann [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=541B68B2.80905@redhat.com \
--to=dborkman@redhat.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.