From: Peter Maydell <peter.maydell@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"dongbo (E)" <dongbo4@huawei.com>,
Peter Maydell <Peter.Maydell@arm.com>,
Will Deacon <will.deacon@arm.com>, Linuxarm <linuxarm@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
arm-mail-list <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
Date: Wed, 19 Apr 2017 11:45:33 +0100 [thread overview]
Message-ID: <CAFEAcA_B+EJJG6gb3iVzL5VRQkGhmDPbYWrUw7UF4VNV0m7XCQ@mail.gmail.com> (raw)
In-Reply-To: <20170419103313.GA3238@e104818-lin.cambridge.arm.com>
On 19 April 2017 at 11:33, Catalin Marinas <catalin.marinas@arm.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
next prev parent reply other threads:[~2017-04-19 10:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1492088223-98232-1-git-send-email-zhangshaokun@hisilicon.com>
2017-04-13 12:33 ` [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation dongbo (E)
2017-04-18 17:01 ` Catalin Marinas
2017-04-18 20:01 ` Peter Maydell
2017-04-19 10:33 ` Catalin Marinas
2017-04-19 10:45 ` Peter Maydell [this message]
2017-04-20 3:50 ` dongbo (E)
2017-04-24 15:40 ` Will Deacon
2017-04-24 15:58 ` Catalin Marinas
2017-04-24 16:05 ` Will Deacon
2017-04-24 16:14 ` Catalin Marinas
2017-04-25 7:04 ` dongbo (E)
2017-04-25 6:58 ` [PATCH REPOST] " dongbo (E)
2017-06-12 13:41 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA_B+EJJG6gb3iVzL5VRQkGhmDPbYWrUw7UF4VNV0m7XCQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=Peter.Maydell@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dongbo4@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).