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]
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/

Powered by blists - more mailing lists