From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls
Date: Mon, 30 Apr 2012 14:55:32 -0400 [thread overview]
Message-ID: <4F9EE024.8000906@redhat.com> (raw)
In-Reply-To: <20120430100746.GA11080@mudshark.cambridge.arm.com>
On 04/30/2012 06:07 AM, Will Deacon wrote:
> Hi Jon,
>
> On Sun, Apr 29, 2012 at 07:38:24AM +0100, Jon Masters wrote:
>> The audit subsystem builds upon ptrace to record system calls. This is done
>> in a couple of places (on return from fork into a new task, on exit from
>> the SWI vector), using calls to syscall_trace. The latter function abuses
>> the userspace intra-procedure scratch register (regs->ARM_ip, aka r12),
>> and intends to restore it prior to return to userspace. Unfortunately,
>> there are cases where we will return to userspace without restoring.
>>
>> If we are in fact not ptracing but are merely auditing calls, we will
>> happily trash the content of ip but will exit to userspace without
>> restoring the value. It just so happens that GLIBC uses ip as a
>> storage for the TLS thread pointer info, and bad things result.
>
> Ouch, that's pretty horrible. We should have spotted this when we were
> fixing the build breakage introduced by the audit stuff. Looking more
> closely, does this code work even with your patch? It looks like we use the
> saved ip to infer syscall entry, rather than why. On top of that, I think
> the polarity is back-to-front.
Yea, so like I said (I think?) elsewhere, I've not tested to see that
audit works in anger yet. It was a case of dealing with the register
corruption issue (which has - to use a British phase - taken me around
the houses finding it) first, then wanting to figure out what's left.
But I'll look over your patch and do some poking. Now that we know where
this problem is, I think the priority is for me to test this patch from
you (took the day off, but I'll give it a test tonight) to make sure
nothing blows up, then schedule some time for audit to make sure it's
actually doing anything useful. I'll email you later today. Still
leaning toward recommending nobody actually turn on audit on ARM systems
until we know that it doesn't do anything else that's terrible.
Jon.
next prev parent reply other threads:[~2012-04-30 18:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-29 6:38 Fixing audit on ARM Jon Masters
2012-04-29 6:38 ` [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls Jon Masters
2012-04-30 10:07 ` Will Deacon
2012-04-30 18:55 ` Jon Masters [this message]
2012-05-01 11:07 ` Will Deacon
2012-05-01 11:37 ` Russell King - ARM Linux
2012-05-01 16:52 ` Jon Masters
2012-05-02 6:27 ` Jon Masters
2012-05-02 8:58 ` Will Deacon
2012-05-02 14:10 ` Jon Masters
2012-05-02 14:48 ` Eric Paris
2012-05-02 15:39 ` Will Deacon
2012-05-02 17:37 ` Jon Masters
2012-04-30 19:00 ` Russell King - ARM Linux
2012-05-03 2:59 ` Jon Masters
2012-05-03 3:03 ` Al Viro
2012-05-03 8:55 ` Will Deacon
2012-05-03 7:34 ` Russell King - ARM Linux
2012-05-02 6:22 ` Jon Masters
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=4F9EE024.8000906@redhat.com \
--to=jcm@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 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).