[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whuH+-swynMTVd9=uCB0uuhaoanQ5kfHEX=QaRZx7UgBw@mail.gmail.com>
Date: Mon, 29 Apr 2024 12:07:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Hillf Danton <hdanton@...a.com>, Andy Lutomirski <luto@...capital.net>, Peter Anvin <hpa@...or.com>,
Adrian Bunk <bunk@...nel.org>,
syzbot <syzbot+83e7f982ca045ab4405c@...kaller.appspotmail.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, andrii@...nel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] x86/mm: Remove broken vsyscall emulation code from the
page fault code
On Mon, 29 Apr 2024 at 11:47, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> In particular, I think the page fault emulation code should be moved
> from do_user_addr_fault() to do_kern_addr_fault(), and the horrible
> hack that is fault_in_kernel_space() should be removed (it is what now
> makes a vsyscall page fault be treated as a user address, and the only
> _reason_ for that is that we do the vsyscall handling in the wrong
> place).
Final note: we should also remove the XONLY option entirely, and
remove all the strange page table handling we currently do for it.
It won't work anyway on future CPUs with LASS, and we *have* to
emulate things (and not in the page fault path, I think LASS will
cause a GP fault).
I think the LASS patches ended up just disabling LASS if people wanted
vsyscall, which is probably the worst case.
Again, this is more of a "I think we have more work to do", and should
all happen after that sig_on_uaccess_err stuff is gone.
I guess that patch to rip out sig_on_uaccess_err needs to go into 6.9
and even be marked for stable, since it most definitely breaks some
stuff currently. Even if that "some stuff" is pretty esoteric (ie
"vsyscall=emulate" together with tracing).
Linus
Powered by blists - more mailing lists