Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191006222046.GA18027@roeck-us.net> <CAHk-=wgrqwuZJmwbrjhjCFeSUu2i57unaGOnP4qZAmSyuGwMZA@mail.gmail.com>
In-Reply-To: <CAHk-=wgrqwuZJmwbrjhjCFeSUu2i57unaGOnP4qZAmSyuGwMZA@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun, 6 Oct 2019 16:35:14 -0700
Message-ID: <CAHk-=wjRPerXedTDoBbJL=tHBpH+=sP6pX_9NfgWxpnmHC5RtQ@mail.gmail.com>
Subject: Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
To:     Guenter Roeck <linux@roeck-us.net>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Content-Type: multipart/mixed; boundary="000000000000219e680594466412"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--000000000000219e680594466412
Content-Type: text/plain; charset="UTF-8"

On Sun, Oct 6, 2019 at 4:06 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Ho humm. I've run variations of that patch over a few years on x86,
> but obviously not on alpha/sparc.

Oooh.

I wonder... This may be the name string copy loop. And it's special in
that the result may not be aligned.

Now, a "__put_user()" with an unaligned address _should_ work - it's
very easy to trigger that from user space by just giving an unaligned
address to any system call that then writes a single word.

But alpha does

  #define __put_user_32(x, addr)                                  \
  __asm__ __volatile__("1: stl %r2,%1\n"                          \
          "2:\n"                                                  \
          EXC(1b,2b,$31,%0)                                       \
                  : "=r"(__pu_err)                                \
                  : "m"(__m(addr)), "rJ"(x), "0"(__pu_err))

iow it implements that 32-bit __put_user() as a 'stl'.

Which will trap if it's not aligned.

And I wonder how much testing that has ever gotten. Nobody really does
unaigned accesses on alpha.

We need to do that memcpy unrolling on x86, because x86 actually uses
"user_access_begin()" and we have magic rules about what is inside
that region.

But on alpha (and sparc) it might be better to just do "__copy_to_user()".

Anyway, this does look like a possible latent bug where the alpha
unaligned trap doesn't then handle the case of exceptions. I know it
_tries_, but I doubt it's gotten a whole lot of testing.

Anyway, let me think about this, but just for testing, does the
attached patch make any difference? It's not the right thing in
general (and most definitely not on x86), but for testing whether this
is about unaligned accesses it might work.

It's entirely untested, and in fact on x86 it should cause objtool to
complain about a function call with AC set. But I think that on alpha
and sparc, using __copy_to_user() for the name copy should work, and
would work around the unaligned issue.

That said, if it *is* the unaligned issue, then that just means that
we have a serious bug elsewhere in the alpha port. Maybe nobody cares.

              Linus

--000000000000219e680594466412
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_k1fmjafm0>
X-Attachment-Id: f_k1fmjafm0

IGZzL3JlYWRkaXIuYyB8IDkgKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25z
KCspCgpkaWZmIC0tZ2l0IGEvZnMvcmVhZGRpci5jIGIvZnMvcmVhZGRpci5jCmluZGV4IDE5YmVh
NTkxYzNmMS4uZDQ5YzRlMmM2NmE4IDEwMDY0NAotLS0gYS9mcy9yZWFkZGlyLmMKKysrIGIvZnMv
cmVhZGRpci5jCkBAIC03Niw2ICs3NiwxNSBAQAogCXVuc2FmZV9wdXRfdXNlcigwLCBkc3QsIGxh
YmVsKTsJCQkJXAogfSB3aGlsZSAoMCkKIAorLyogQWxwaGEgKGFuZCBzcGFyYz8pIHRlc3QgcGF0
Y2ghICovCisjdW5kZWYgdW5zYWZlX2NvcHlfZGlyZW50X25hbWUKKyNkZWZpbmUgdW5zYWZlX2Nv
cHlfZGlyZW50X25hbWUoX2RzdCwgX3NyYywgX2xlbiwgbGFiZWwpIGRvIHsJXAorCWNoYXIgX191
c2VyICpkc3QgPSAoX2RzdCk7CQkJCVwKKwljb25zdCBjaGFyICpzcmMgPSAoX3NyYyk7CQkJCVwK
KwlzaXplX3QgbGVuID0gKF9sZW4pOwkJCQkJXAorCWlmIChfX2NvcHlfdG9fdXNlcihkc3QsIHNy
YywgbGVuKSkgZ290byBsYWJlbDsJCVwKKwl1bnNhZmVfcHV0X3VzZXIoMCwgZHN0K2xlbiwgbGFi
ZWwpOwkJCVwKK30gd2hpbGUgKDApCiAKIGludCBpdGVyYXRlX2RpcihzdHJ1Y3QgZmlsZSAqZmls
ZSwgc3RydWN0IGRpcl9jb250ZXh0ICpjdHgpCiB7Cg==
--000000000000219e680594466412--