>
> Could you describe the problem in more details? I wonder whether we have
> the same thing in CRIU...
>
Sure, basically the issue is that orig_x0 gets recorded at the start of the
syscall entry, but is not otherwise part of the ptrace state. It used
to be primarily used for resetting the
Hi Andrei,
> This series introduces the PTRACE_O_ARM64_RAW_REGS option. If it is set,
> PTRACE_GETREGSET returns values of all registers, and PTRACE_SETREGSET
> allows to change any of them.
thanks for picking this up. I meant to work on this, but unfortunately ran out
of time to be able to push
Hi all,
The code in prctl(PR_SET_MM, ...) performs a number of sanity checks,
among them
```
/*
* @brk should be after @end_data in traditional maps.
*/
if (prctl_map->start_brk <= prctl_map->end_data ||
prctl_map->brk <= prctl_map->end_data)
goto out;
```
The original commit that
> > Now, if we have a seccomp filter that simply does
> > SECCOMP_RET_TRACE, and a ptracer that simply
> > does PTRACE_CONT
>
> Ok, so this means that we're _skipping_ the system call, right?
If the system call were positive this would result in the system call
being executed. The notion of
On Mon, Jun 1, 2020 at 5:23 AM Dave Martin wrote:
> > > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> > > syscall at the syscall enter stop, then modifying the regs at the
> > > syscall exit stop?
> >
> > Yes, it can. The idea behind SYSEMU is to be able to save half
On Mon, Jun 1, 2020 at 5:14 AM Dave Martin wrote:
> Can you explain why userspace would write a changed value for x7
> but at the same time need that new to be thrown away?
The discarding behavior is the primary reason things aren't completely
broken at the moment. If it read the wrong x7 value
> Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> syscall at the syscall enter stop, then modifying the regs at the
> syscall exit stop?
Yes, it can. The idea behind SYSEMU is to be able to save half the
ptrace traps that would require, in theory making the ptracer
a
> Keno -- are you planning to send out a patch? You previously spoke about
> implementing this using PTRACE_SETOPTIONS.
Yes, I'll have a patch for you. Though I've come to the conclusion
that introducing a new regset is probably a better way to solve it.
We can then also expose orig_x0 at the
Hi everyone,
I'm in the process of trying to port a debugging tool (http://rr-project.org/)
from x86 to various other architectures. This tool relies on noting every
change that was made to the memory of the process being debugged.
As such, it has a battery of tests for corner cases of copyin/out
is a syscall-stop, so the tracer's write
to x7 was ignored and x7 retained the value it had in the signal handler,
which broke the tracee.
Keno
On Sat, May 23, 2020 at 1:35 AM Keno Fischer wrote:
>
> I got bitten by this again, so I decided to write up a simple example
> that shows th
be quite disruptive to the
userspace program. This patch brings the arm64 behavior in line
with the other major architectures by using the generic
pseudo-single-step-stop, avoiding the problematic interaction
with SIGTRAP masks.
Fixes: 2c020ed8 ("arm64: Signal handling support")
Signed-of
I got bitten by this again, so I decided to write up a simple example
that shows the problem:
https://gist.github.com/Keno/cde691b26e32373307fb7449ad305739
This runs the same child twice. First vanilla where it prints "Hello world".
The second time, using a textbook ptrace example, to only print
I'm seeing the following while porting a ptracer from
x86_64 to arm64 (cc'ing arm64 folks, but in this case
x86_64 is the odd one out, I think other archs would
be consistent with arm64).
Consider userspace code like the following:
```
int ret = syscall(-10, 0);
assert(ret == -ENOSYS);
```
Hi Will,
> Yes, we inherited this from ARM and I think strace relies on it. In
> hindsight, it is a little odd, although x7 is a parameter register in the
> PCS and so it won't be live on entry to a system call.
I'm not familiar with the PCS acronym, but I assume you mean the
calling convention?
Continuing my theme of "weird things I encounter
while trying to use ptrace on arm64", I ran into the
effect of the following code in the syscall entry/exit
reporting:
```
/*
* A scratch register (ip(r12) on AArch32, x7 on AArch64) is
* used to denote syscall entry/exit:
*/
regno =
method was used to re-start the syscall
at the entry stop, rather than the method that was used to reach it.
Fix that by recording the original flag before performing the ptrace
stop, bringing the behavior in line with documentation and x86/powerpc.
Signed-off-by: Keno Fischer
---
arch/arm64/kernel
On Fri, May 15, 2020 at 8:13 AM Will Deacon wrote:
> But it also
> means that nobody is using this on arm64, so we could also consider removing
> it entirely. Did you spot this because you are trying to use it for
> something or just by inspection/unit-testing?
No, I was trying to port a tool
The behavior of PTRACE_SYSEMU on arm64
appears to differ substantially from that of x86 and powerpc
(the other two architectures on which this feature is implemented).
In particular, after PTRACE_SYSEMU the syscall will always
be skipped on x86 and powerpc, but executed on arm64 unless
the
> So, to be useful, this interface needs to be called before an
> application can run XGETBV or XSAVE for the first time and caches a
> "bad" value. I think that means that it might not be feasible to use
> outside of cases where you ptrace() something and inject things before
> it has a chance
> So, to be useful, this interface needs to be called before an
> application can run XGETBV or XSAVE for the first time and caches a
> "bad" value. I think that means that it might not be feasible to use
> outside of cases where you ptrace() something and inject things before
> it has a chance
> So we're talking about a workaround for broken software. The question
> is how wide spread is it?
For rr to work, it tries to replicate the process state *exactly*. That means:
1. The same instructions executed in the same order
2. The exact same register state at those instructions
3. The
> So we're talking about a workaround for broken software. The question
> is how wide spread is it?
For rr to work, it tries to replicate the process state *exactly*. That means:
1. The same instructions executed in the same order
2. The exact same register state at those instructions
3. The
On Mon, Jun 18, 2018 at 12:16 PM, Dave Hansen
wrote:
> On 06/18/2018 08:13 AM, Keno Fischer wrote:
>>>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update
>>>> XCR0, redo the xsaves/restores, put XCR0 back and continue
>>>> e
On Mon, Jun 18, 2018 at 12:16 PM, Dave Hansen
wrote:
> On 06/18/2018 08:13 AM, Keno Fischer wrote:
>>>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update
>>>> XCR0, redo the xsaves/restores, put XCR0 back and continue
>>>> e
>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update
>> XCR0, redo the xsaves/restores, put XCR0 back and continue
>> execution after the faulting instruction.
>
> I'm worried about the kernel pieces that go digging in the XSAVE data
> getting confused more than the
>> 4) Catch the fault thrown by xsaves/xrestors in this situation, update
>> XCR0, redo the xsaves/restores, put XCR0 back and continue
>> execution after the faulting instruction.
>
> I'm worried about the kernel pieces that go digging in the XSAVE data
> getting confused more than the
Hi Dave,
thank you for your thorough comments, replies inline:
On Mon, Jun 18, 2018 at 8:47 AM, Dave Hansen
wrote:
> On 06/16/2018 05:33 PM, Keno Fischer wrote:
>> For my use case, it would be sufficient to simply disallow
>> any value of XCR0 with "holes" in it,
>
Hi Dave,
thank you for your thorough comments, replies inline:
On Mon, Jun 18, 2018 at 8:47 AM, Dave Hansen
wrote:
> On 06/16/2018 05:33 PM, Keno Fischer wrote:
>> For my use case, it would be sufficient to simply disallow
>> any value of XCR0 with "holes" in it,
>
> Almost difference in CPU behavior
> between the replayer and the replayee.
Not sure what happened to this sentence.
What I meant to say was:
Almost any difference in CPU behavior between
the replayer and the replayee will cause problems
for the determinism of the trace.
To elaborate on this,
> Almost difference in CPU behavior
> between the replayer and the replayee.
Not sure what happened to this sentence.
What I meant to say was:
Almost any difference in CPU behavior between
the replayer and the replayee will cause problems
for the determinism of the trace.
To elaborate on this,
> Patch seems pointless if you can already control CPUID, which rr
> supports. Just disable AVX512 in CPUID. All code using AVX should check
> cpuid (or will fail anyways).
Unfortunately, that is insufficient. Almost difference in CPU behavior
between the replayer
and the replayee. In particular,
> Patch seems pointless if you can already control CPUID, which rr
> supports. Just disable AVX512 in CPUID. All code using AVX should check
> cpuid (or will fail anyways).
Unfortunately, that is insufficient. Almost difference in CPU behavior
between the replayer
and the replayee. In particular,
From: Keno Fischer
The rr (http://rr-project.org/) debugger provides user space
record-and-replay functionality by carefully controlling the process
environment in order to ensure completely deterministic execution
of recorded traces. The recently added ARCH_SET_CPUID arch_prctl
allows rr
From: Keno Fischer
The rr (http://rr-project.org/) debugger provides user space
record-and-replay functionality by carefully controlling the process
environment in order to ensure completely deterministic execution
of recorded traces. The recently added ARCH_SET_CPUID arch_prctl
allows rr
has been reached.
On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages)
<mtk.manpa...@gmail.com> wrote:
> Hello Keno
>
> On 12/03/2017 04:15 AM, Keno Fischer wrote:
>> Resending as plain text (apologies for those receiving it twice, and
>> those that got
>>
has been reached.
On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages)
wrote:
> Hello Keno
>
> On 12/03/2017 04:15 AM, Keno Fischer wrote:
>> Resending as plain text (apologies for those receiving it twice, and
>> those that got
>> an HTML copy, I'm used
not advocating for anything other
than clarity of what kernel behavior user space may assume.
On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox <wi...@infradead.org> wrote:
> On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote:
>> The catalyst for this patch was me experienci
not advocating for anything other
than clarity of what kernel behavior user space may assume.
On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox wrote:
> On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote:
>> The catalyst for this patch was me experiencing EINTR errors when
>&g
Particularly on network file systems, a stat call may require
submitting a message over the network and waiting interruptably
for a reply.
Signed-off-by: Keno Fischer <k...@juliacomputing.com>
---
The catalyst for this patch was me experiencing EINTR errors when
using the 9p file
Particularly on network file systems, a stat call may require
submitting a message over the network and waiting interruptably
for a reply.
Signed-off-by: Keno Fischer
---
The catalyst for this patch was me experiencing EINTR errors when
using the 9p file system. In linux commit 9523feac, the 9p
Hi Linus,
> But it sounds like your JIT case actually uses it for writing -
> but if you can write a small blurb about it, that would be nice.
yes, we use it for writing. Happy to describe the scheme in more detail.
> (b) it would probably be nice to limit FOLL_FORCE in general as much
>
Hi Linus,
> But it sounds like your JIT case actually uses it for writing -
> but if you can write a small blurb about it, that would be nice.
yes, we use it for writing. Happy to describe the scheme in more detail.
> (b) it would probably be nice to limit FOLL_FORCE in general as much
>
Hi Linus et al.,
In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed
punch through semantics of /proc//mem. We used these semantics as a
hardening mechanism in the julia JIT. By opening /proc/self/mem and using
these semantics, we could avoid needing RWX pages, or a dual
Hi Linus et al.,
In 8ee74a91 "proc: try to remove use of FOLL_FORCE entirely", you removed
punch through semantics of /proc//mem. We used these semantics as a
hardening mechanism in the julia JIT. By opening /proc/self/mem and using
these semantics, we could avoid needing RWX pages, or a dual
NCE to make sure we notice if we ever
do.
Signed-off-by: Keno Fischer <k...@juliacomputing.com>
---
Changes since v1:
* In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather
than allowing it, since that situation should not happen.
As suggested by Kirill A. Shutemov
mm/huge_me
NCE to make sure we notice if we ever
do.
Signed-off-by: Keno Fischer
---
Changes since v1:
* In follow_devmap_pmd, WARN_ONCE if FOLL_COW is encountered, rather
than allowing it, since that situation should not happen.
As suggested by Kirill A. Shutemov
mm/huge_memory.c | 18 +++
>> @@ -783,7 +793,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct
>> *vma, unsigned long addr,
>>
>> assert_spin_locked(pmd_lockptr(mm, pmd));
>>
>> - if (flags & FOLL_WRITE && !pmd_write(*pmd))
>> + if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
>>
>> @@ -783,7 +793,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct
>> *vma, unsigned long addr,
>>
>> assert_spin_locked(pmd_lockptr(mm, pmd));
>>
>> - if (flags & FOLL_WRITE && !pmd_write(*pmd))
>> + if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
>>
n gup.c in the original commit. The same pattern existed in
follow_devmap_pmd, so I have changed that location as well. However,
I do not have a test case that for that code path.
Signed-off-by: Keno Fischer <k...@juliacomputing.com>
---
mm/huge_memory.c | 14 --
1 file changed, 12
n gup.c in the original commit. The same pattern existed in
follow_devmap_pmd, so I have changed that location as well. However,
I do not have a test case that for that code path.
Signed-off-by: Keno Fischer
---
mm/huge_memory.c | 14 --
1 file changed, 12 insertions(+), 2 deletion
This is mostly out of curiosity, but I was surprised by the behavior, so
I was hoping somebody might be able to explain why this behavior was
chosen. In particular, consider any zombie process, e.g.
$ cat /proc/77078/status
Name: test
State: Z (zombie)
Tgid: 77078
Ngid: 0
Pid: 77078
PPid: 77077
This is mostly out of curiosity, but I was surprised by the behavior, so
I was hoping somebody might be able to explain why this behavior was
chosen. In particular, consider any zombie process, e.g.
$ cat /proc/77078/status
Name: test
State: Z (zombie)
Tgid: 77078
Ngid: 0
Pid: 77078
PPid: 77077
Hi Andy (),
this is more of a heads up than a bug report, since it turns out you
already fixed this in
731e33e: x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization
In any case, without that commit, trying to use PTRACE_SETREGS to set
either fs_base, or gs_base to 0 when it was previously
Hi Andy (),
this is more of a heads up than a bug report, since it turns out you
already fixed this in
731e33e: x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization
In any case, without that commit, trying to use PTRACE_SETREGS to set
either fs_base, or gs_base to 0 when it was previously
Just as an FYI, the linker bug has been fixed in binutils.
On Fri, Nov 11, 2016 at 5:07 PM, Richard Weinberger <rich...@nod.at> wrote:
> On 11.11.2016 22:03, Keno Fischer wrote:
>> Did you have CONFIG_INET set? I'm attaching my full .config. This is
>> on vanilla
Just as an FYI, the linker bug has been fixed in binutils.
On Fri, Nov 11, 2016 at 5:07 PM, Richard Weinberger wrote:
> On 11.11.2016 22:03, Keno Fischer wrote:
>> Did you have CONFIG_INET set? I'm attaching my full .config. This is
>> on vanilla Ubuntu 16.10.
>
> Yes, CONFI
This option was added in 6a89a314ab107a12af08c71420c19a37a30fc2d3 to allow use
of the devm_gpio_* functions without CONFIG_GPIOLIB. However, only a few months
later in b69ac52449c658b7ac40034dc3c5f5f4a71a723d, CONFIG_GPIOLIB, was added
as a dependency, defeating the original purpose of this
This option was added in 6a89a314ab107a12af08c71420c19a37a30fc2d3 to allow use
of the devm_gpio_* functions without CONFIG_GPIOLIB. However, only a few months
later in b69ac52449c658b7ac40034dc3c5f5f4a71a723d, CONFIG_GPIOLIB, was added
as a dependency, defeating the original purpose of this
Did you have CONFIG_INET set? I'm attaching my full .config. This is
on vanilla Ubuntu 16.10.
I did see the same error when building with `CONFIG_STATIC_LINK=y`.
Note that I also, separately, ran into a linker problem, though I
believe it is unrelated to this patch
(though perhaps is related to
Did you have CONFIG_INET set? I'm attaching my full .config. This is
on vanilla Ubuntu 16.10.
I did see the same error when building with `CONFIG_STATIC_LINK=y`.
Note that I also, separately, ran into a linker problem, though I
believe it is unrelated to this patch
(though perhaps is related to
On Thu, Nov 10, 2016 at 3:19 PM, Richard Weinberger wrote:
> Can you please reply to Sebastian's patch series and explain him how you
> trigger
> that error?
> I don't have a gcc broken by Debian on my machine right now.
I'm not sure how to reply to his patch series directly
On Thu, Nov 10, 2016 at 3:19 PM, Richard Weinberger wrote:
> Can you please reply to Sebastian's patch series and explain him how you
> trigger
> that error?
> I don't have a gcc broken by Debian on my machine right now.
I'm not sure how to reply to his patch series directly since I'm not
Yes
On Thu, Nov 10, 2016 at 3:14 PM, Richard Weinberger <rich...@nod.at> wrote:
> Keno,
>
> On 10.11.2016 21:10, Keno Fischer wrote:
>>> The problem is ready being solved in a generic way:
>>> http://marc.info/?l=linux-kernel=147828481602561=2
>>>
Yes
On Thu, Nov 10, 2016 at 3:14 PM, Richard Weinberger wrote:
> Keno,
>
> On 10.11.2016 21:10, Keno Fischer wrote:
>>> The problem is ready being solved in a generic way:
>>> http://marc.info/?l=linux-kernel=147828481602561=2
>>>
>>> Can you pleas
> The problem is ready being solved in a generic way:
> http://marc.info/?l=linux-kernel=147828481602561=2
>
> Can you please give this patch a try?
No dice. After backing out my patch and applying that one I get:
/usr/bin/ld: error: net/built-in.o: requires unsupported dynamic reloc
11;
> The problem is ready being solved in a generic way:
> http://marc.info/?l=linux-kernel=147828481602561=2
>
> Can you please give this patch a try?
No dice. After backing out my patch and applying that one I get:
/usr/bin/ld: error: net/built-in.o: requires unsupported dynamic reloc
11;
problems in modpost.
Signed-off-by: Keno Fischer <k...@juliacomputing.com>
---
I encountered this while trying to build uml in an attempt to debug some kernel
behavior I don't understand. To be as close to my actual kernel as possible,
I used the same .config, which of course tried to build a
problems in modpost.
Signed-off-by: Keno Fischer
---
I encountered this while trying to build uml in an attempt to debug some kernel
behavior I don't understand. To be as close to my actual kernel as possible,
I used the same .config, which of course tried to build a bunch of drivers.
Arguably I
Fixes the following link error:
```
/usr/bin/ld: net/built-in.o: relocation R_X86_64_32S against `.text'
can not be used when making a shared object; recompile with -fPIC
```
This is the same definition used on some other architectures.
Signed-off-by: Keno Fischer <k...@juliacomputing.com>
Fixes the following link error:
```
/usr/bin/ld: net/built-in.o: relocation R_X86_64_32S against `.text'
can not be used when making a shared object; recompile with -fPIC
```
This is the same definition used on some other architectures.
Signed-off-by: Keno Fischer
---
I am not sure
Hi Anton,
I was reading the powerpc syscall entry code and git points me at your commit
05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one
part that confused me, so I hope you don't mind a quick question. In particular,
that commit removed the use of r10 to restore lr, but
Hi Anton,
I was reading the powerpc syscall entry code and git points me at your commit
05b05f28 (powerpc: Relocatable system call no longer uses the LR) for one
part that confused me, so I hope you don't mind a quick question. In particular,
that commit removed the use of r10 to restore lr, but
11:34 AM, Oleg Nesterov <o...@redhat.com> wrote:
> On 08/18, Keno Fischer wrote:
>>
>> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <o...@redhat.com> wrote:
>> >
>> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
>> > PTRA
11:34 AM, Oleg Nesterov wrote:
> On 08/18, Keno Fischer wrote:
>>
>> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote:
>> >
>> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
>> > PTRACE_INTERRUPT, you know that the tracee did
Hi folks,
this is more of a general linux question, but since I noticed it
while looking perf_events code, I'm ccing perf_events folks
in case the answer is perf_events specific (hope that's ok).
uapi/linux/perf_event.h has the following:
#define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64)
#define
Hi folks,
this is more of a general linux question, but since I noticed it
while looking perf_events code, I'm ccing perf_events folks
in case the answer is perf_events specific (hope that's ok).
uapi/linux/perf_event.h has the following:
#define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64)
#define
On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote:
>
> And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
> PTRACE_INTERRUPT, you know that the tracee did not report the "new"
> SIGTTIN.
It seems possible to remember whether or not we injected a stopping
On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov wrote:
>
> And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
> PTRACE_INTERRUPT, you know that the tracee did not report the "new"
> SIGTTIN.
It seems possible to remember whether or not we injected a stopping
signal and if so
Consider below test case (not all of it is necessary for reproducing
the behavior in question, but I wanted to cover related cases as well
to make sure they behave as expected). In this test case, the last
group-stop (after PTRACE_INTERRUPT) is delivered with a
WSTOPSIG(status) of SIGTTIN, which
Consider below test case (not all of it is necessary for reproducing
the behavior in question, but I wanted to cover related cases as well
to make sure they behave as expected). In this test case, the last
group-stop (after PTRACE_INTERRUPT) is delivered with a
WSTOPSIG(status) of SIGTTIN, which
80 matches
Mail list logo