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: <53D97A9E.3090908@twiddle.net>
Date:	Wed, 30 Jul 2014 13:07:10 -1000
From:	Richard Henderson <rth@...ddle.net>
To:	Måns Rullgård <mans@...sr.com>
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

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.

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.

r~
--
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/