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 ac
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 ca
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 use
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, sin
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 th
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 option,
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 beca
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 situa
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 expecting
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 tes
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 a
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 funct
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 bette
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 loc
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 check_unsa
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, ther
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 actually
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 i
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 don
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 believab
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 som
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 want
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 b
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 in
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 dropping
31 matches
Mail list logo
