linux-kernel - Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yw1xfvhi5sjm.fsf@unicorn.mansr.com>
Date:	Thu, 31 Jul 2014 00:35:25 +0100
From:	Måns Rullgård <mans@...sr.com>
To:	Richard Henderson <rth@...ddle.net>
Cc:	linux-kernel@...r.kernel.org, mcree@...on.net.nz,
	linux-alpha@...r.kernel.org
Subject: Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

Richard Henderson <rth@...ddle.net> writes:

> On 07/30/2014 12:04 PM, Måns Rullgård wrote:
>> Richard Henderson <rth@...ddle.net> writes:
>> 
>>> The assignment to regs->r20 kills the original tls_val input
>>> to the clone syscall, which means that clone can no longer be
>>> restarted with the original inputs.
>>>
>>> We could, perhaps, retain this result for true fork, but OSF/1
>>> compatibility is no longer important.  Note that glibc has never
>>> used the r20 result value, instead always testing r0 vs 0 to
>>> determine the child/parent status.
>> 
>> What effect does this have on OSF/1 compat?
>
> I don't know, as I've never had access to osf/1 myself.  It depends on
> how that $20 value is used -- potentially, fork(3) no longer works.

That would render the entire OSF/1 compat useless.

> I can imagine that we could retain these assignments under the
> condition of clone_flags == 0, which both implies a basic fork as well
> as the fact that the tls_val argument is unused.
>
> But I do have to ask first if anyone actually cares.  Surely the
> amount of osf-on-linux emulation is a vanishingly small proportion of
> the already small alpha-linux population.

I don't like the idea of breaking features without good reason.  It's
also not obvious to me that those who have reasons to run Alpha hardware
at all also don't have reasons to run OSF/1 binaries on it.

I have Alpha machines with both Linux and OSF/1 (Tru64), so I could run
some quick tests, though I'm not certain what would make a good test
case for this.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/