[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFEAcA_B+EJJG6gb3iVzL5VRQkGhmDPbYWrUw7UF4VNV0m7XCQ@mail.gmail.com>
Date: Wed, 19 Apr 2017 11:45:33 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Mark Rutland <mark.rutland@....com>,
"dongbo (E)" <dongbo4@...wei.com>,
Peter Maydell <Peter.Maydell@....com>,
Will Deacon <will.deacon@....com>,
Linuxarm <linuxarm@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org,
arm-mail-list <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
On 19 April 2017 at 11:33, Catalin Marinas <catalin.marinas@....com> wrote:
> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
>>
>> > That's affecting most architectures with a risk of ABI breakage. We
>> > could do it on arm64 only, though I'm not yet clear on the ABI
>> > implications (at a first look, there shouldn't be any).
>>
>> Is there a reason why it isn't just straightforwardly a bug
>> (which we could fix) to make READ_IMPLIES_EXEC propagate to
>> child processes?
>
> While I agree that it looks like a bug, if there are user programs
> relying on such bug we call it "ABI".
Can there be any? Such a program would behave differently
depending on how the program that spawned it happened to
have been compiled, and for instance could break when
the OS happened to have its init binary updated even if
the kernel didn't change.
>> Behaviour shouldn't be variable across architectures either, I would
>> hope.
>
> The behaviour has already been variable for a long time. Even on x86,
> AFAICT x86_32 differs from x86_64 in this respect.
That also sounds like a bug to me.
> Anyway, the patch should be posted to linux-arch for a cross-arch
> discussion.
Agreed -- there may be something I'm missing, since it looks
like this behaviour of inheriting READ_IMPLIES_EXEC has always
been there.
thanks
-- PMM
Powered by blists - more mailing lists