On 4/30/20 6:40 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 7:29 AM Bernd Edlinger
> wrote:
>>
>> Ah, now I see, that was of course not the intended effect,
>> but that is not where the pseudo-deadlock happens at all,
>> would returning -RESTARTNOINTR in this function make this
>> patch
On Thu, Apr 30, 2020 at 7:29 AM Bernd Edlinger
wrote:
>
> Ah, now I see, that was of course not the intended effect,
> but that is not where the pseudo-deadlock happens at all,
> would returning -RESTARTNOINTR in this function make this
> patch acceptable, it will not have an effect on the test
Hi Linus,
On 4/30/20 3:47 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 6:39 AM Bernd Edlinger
> wrote:
>>
>> Excuse me, but what in my /proc folder there is no attr/something
>> is there a procfs equivalent of pthread_attach ?
>>
>> What exactly is "attr/something" ?
>
> Anything that
On Thu, Apr 30, 2020 at 6:39 AM Bernd Edlinger
wrote:
>
> Excuse me, but what in my /proc folder there is no attr/something
> is there a procfs equivalent of pthread_attach ?
>
> What exactly is "attr/something" ?
Anything that uses that proc_pid_attr_write().
Which you should have realized,
On 4/30/20 4:16 AM, Linus Torvalds wrote:
> On Wed, Apr 29, 2020 at 5:00 PM Jann Horn wrote:
>>
>> Wouldn't you end up livelocked in the scenario that currently deadlocks?
>
> The test case that we already know is broken, and any fix will have to
> change anyway?
>
The purpose of the test case
On Wed, Apr 29, 2020 at 8:25 PM Linus Torvalds
wrote:
>
> Bernd's approach _without_ the restart is unacceptable.
>
> It's unacceptable because it breaks things that currently work, and
> returns EAGAIN in situations where that is simple not a valid error
> code.
Looking at my restart thing, I
On Wed, Apr 29, 2020 at 8:41 PM Jann Horn wrote:
>
> | So a ptrace() user (or [...] wouldn't even see the impossible EAGAIN error.
>
> So I assumed you explicitly wanted ptrace() to restart, too. I was
> just pointing out that that didn't make sense to me.
I'm actually ok with the restart
On Thu, Apr 30, 2020 at 5:26 AM Linus Torvalds
wrote:
> On Wed, Apr 29, 2020 at 8:00 PM Jann Horn wrote:
> >
> > But if we go with Bernd's approach together with your restart
> > suggestion,
>
> So repeat after me: Bernd's approach _without_ the restart is unacceptable.
>
> It's unacceptable
On Wed, Apr 29, 2020 at 8:00 PM Jann Horn wrote:
>
> But if we go with Bernd's approach together with your restart
> suggestion,
So repeat after me: Bernd's approach _without_ the restart is unacceptable.
It's unacceptable because it breaks things that currently work, and
returns EAGAIN in
On Thu, Apr 30, 2020 at 4:20 AM Linus Torvalds
wrote:
> On Wed, Apr 29, 2020 at 6:08 PM Bernd Edlinger
> wrote:
> >
> > I added the BIG FAT WARNNIG comments as a mitigation for that.
> > Did you like those comments?
>
> No.
>
> What's the point olf saying "THIS CODE IS GARBAGE" and then
On Wed, Apr 29, 2020 at 6:08 PM Bernd Edlinger
wrote:
>
> I added the BIG FAT WARNNIG comments as a mitigation for that.
> Did you like those comments?
No.
What's the point olf saying "THIS CODE IS GARBAGE" and then expecting
that to make it ok?
No,m that doesn't make it ok. It just means that
On Wed, Apr 29, 2020 at 5:00 PM Jann Horn wrote:
>
> Wouldn't you end up livelocked in the scenario that currently deadlocks?
The test case that we already know is broken, and any fix will have to
change anyway?
Let's just say that I don't care in the least.
But Bernd's patch as-is breaks a
On 4/30/20 1:59 AM, Jann Horn wrote:
> On Thu, Apr 30, 2020 at 1:22 AM Linus Torvalds
> wrote:
>> On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds
>> wrote:
>>>
>>> If you do it properly, with a helper function instead of repeating
>>> that fragile nasty thing, maybe it will look better to me.
I
On Thu, Apr 30, 2020 at 1:22 AM Linus Torvalds
wrote:
> On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds
> wrote:
> >
> > If you do it properly, with a helper function instead of repeating
> > that fragile nasty thing, maybe it will look better to me.
>
> Side note: if it has a special helper
On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds
wrote:
>
> If you do it properly, with a helper function instead of repeating
> that fragile nasty thing, maybe it will look better to me.
Side note: if it has a special helper function for the "get lock,
repeat if it was invalid", you can do a
On Wed, Apr 29, 2020 at 12:23 PM Bernd Edlinger
wrote:
>
> By the way, all other attempts to fix it look much more dangerous
> than my initially proposed patch, you know the one you hated, but
> it does work and does not look overly complicated either.
I don't think it works.
The whole "take
On Wed, Apr 29, 2020 at 10:20 PM Bernd Edlinger
wrote:
> On 4/29/20 9:26 PM, Jann Horn wrote:
> > On Wed, Apr 29, 2020 at 9:23 PM Bernd Edlinger
> > wrote:
> >> On 4/29/20 7:58 PM, Linus Torvalds wrote:
> >>> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>
> On Wed, Apr 29, 2020 at
On 4/29/20 9:26 PM, Jann Horn wrote:
> On Wed, Apr 29, 2020 at 9:23 PM Bernd Edlinger
> wrote:
>> On 4/29/20 7:58 PM, Linus Torvalds wrote:
>>> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
wrote:
>
> - we move
On Wed, Apr 29, 2020 at 9:23 PM Bernd Edlinger
wrote:
> On 4/29/20 7:58 PM, Linus Torvalds wrote:
> > On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
> >>
> >> On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
> >> wrote:
> >>>
> >>> - we move check_unsafe_exec() down. As far as I can tell,
On 4/29/20 7:58 PM, Linus Torvalds wrote:
> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>>
>> On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
>> wrote:
>>>
>>> - we move check_unsafe_exec() down. As far as I can tell, there's no
>>> reason it's that early - the flags it sets aren't
On Wed, Apr 29, 2020 at 11:33 AM Jann Horn wrote:
>
> > That sequence count approach would be a much simpler change.
>
> In that model, what should happen if someone tries to attach to a
> process that's in execve(), but after the point of no return in
> de_thread()? "Abort" after the point of no
On Wed, Apr 29, 2020 at 7:58 PM Linus Torvalds
wrote:
> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
> >
> > On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
> > wrote:
> > >
> > > - we move check_unsafe_exec() down. As far as I can tell, there's no
> > > reason it's that early - the flags
On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>
> On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
> wrote:
> >
> > - we move check_unsafe_exec() down. As far as I can tell, there's no
> > reason it's that early - the flags it sets aren't actually used until
> > when we actually do that final
On Wed, Apr 29, 2020 at 12:14 AM Linus Torvalds
wrote:
> On Tue, Apr 28, 2020 at 2:53 PM Jann Horn wrote:
> >
> > You don't need LSM_UNSAFE_PTRACE if the tracer has already passed a
> > ptrace_may_access() check against the post-execve creds of the target
> > - that's no different from having
On Tue, Apr 28, 2020 at 2:53 PM Jann Horn wrote:
>
> You don't need LSM_UNSAFE_PTRACE if the tracer has already passed a
> ptrace_may_access() check against the post-execve creds of the target
> - that's no different from having done PTRACE_ATTACH after execve is
> over.
Hmm. That sounds
On Tue, Apr 28, 2020 at 11:37 PM Linus Torvalds
wrote:
> On Tue, Apr 28, 2020 at 2:06 PM Jann Horn wrote:
> > In execve:
> >
> > - After the point of no return, but before we start waiting for the
> >other threads to go away, finish calculating our post-execve creds
> >and stash them
On Tue, Apr 28, 2020 at 2:06 PM Jann Horn wrote:
>
> In execve:
>
> - After the point of no return, but before we start waiting for the
>other threads to go away, finish calculating our post-execve creds
>and stash them somewhere in the task_struct or so.
> - Drop the cred_guard_mutex.
On Tue, Apr 28, 2020 at 10:36 PM Linus Torvalds
wrote:
> On Tue, Apr 28, 2020 at 12:08 PM Oleg Nesterov wrote:
> >
> > Oops. I can update that old patch but somehow I thought there is a better
> > plan which I don't yet understand...
>
> I don't think any plan survived reality.
>
> Unless we
On Tue, Apr 28, 2020 at 12:08 PM Oleg Nesterov wrote:
>
> Oops. I can update that old patch but somehow I thought there is a better
> plan which I don't yet understand...
I don't think any plan survived reality.
Unless we want to do something *really* hacky.. The attached patch is
not meant to
On 04/28, Linus Torvalds wrote:
>
> On Mon, Apr 27, 2020 at 7:56 PM Bernd Edlinger
> wrote:
> >
> > was this resolved meanwhile?
>
> No. I think the tentative plan is to just apply Oleg's "don't wait for
> zombie threads with cred_guard_mutex held" patch, hopefully with that
> de_thread() moved
On Mon, Apr 27, 2020 at 7:56 PM Bernd Edlinger
wrote:
>
> was this resolved meanwhile?
No. I think the tentative plan is to just apply Oleg's "don't wait for
zombie threads with cred_guard_mutex held" patch, hopefully with that
de_thread() moved into install_exec_creds() (right after the
31 matches
Mail list logo
