Re: [PATCH 00/31 v2] PTI support for x86_32
Hi Linus, On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds wrote: > So let's try to fix the iscsi and ipsec issues. Not that anybody sane > should use that overly complex ipsec thing, and I think we should > strive to merge WireGuard and get people moved over to that instead, > but I haven't heard anything from davem about it since I last asked.. > I have some hope that it's slowly happening. Sorry for missing this comment earlier. We're really quite close to a point where we can post our v1 patchset. I'm headed on the road this week, but will be back on the first of April, and I expect that sometime in the spring we should begin to have the cycles of posting patches and receiving reviews and getting this into shape for shipping upstream. So, fear not, we're still rolling ahead! Regards, Jason
Re: [PATCH 00/31 v2] PTI support for x86_32
On Thu, Feb 22, 2018 at 12:10 PM, Greg KH wrote:
> On Wed, Feb 21, 2018 at 05:59:34PM +0100, Arnd Bergmann wrote:
>> On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti wrote:
>> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH
>> > wrote:
>> >> > > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
>> >> > >
>> >> > > Back in 2015 someone started to work on that, and properly marked that
>> >> > > the kernel could not handle this with commit 74005991b78a ("xfrm: Do
>> >> > > not
>> >> > > parse 32bits compiled xfrm netlink msg on 64bits host")
>> >> > >
>> >> > > This is starting to be hit by some Android systems that are moving
>> >> > > (yeah, slowly) to 4.4 :(
>> >> >
>> >> > Does anybody have test-programs/harnesses for this?
>> >>
>> >> Lorenzo (now on the To: line), is the one that I think is looking into
>> >> this, and should have some sort of test for it. Lorenzo?
>> >
>> > Sorry for the late reply here. The issue is that the xfrm uapi structs
>> > don't specify padding at the end, so they're a different size on
>> > 32-bit and 64-bit archs. This by itself would be fine, as the kernel
>> > could just ignore the (lack of) padding. But some of these structs
>> > contain others (e.g., xfrm_userspi_info contains xfrm_usersa_info),
>> > and in that case the whole layout after the contained struct is
>> > different.
>>
>> So this is x86 specific then and it already works correctly on all
>> other architectures (especially arm64 Android), right?
>
> Why is this an x86-specific issue? I think people have noticed this
> with ARM systems given that the original bug report I saw was for an
> ARM Android-based system that had a 64bit kernel and 32bit userspace.
The patch Lorenzo linked to is only for x86, it addresses the fact that
the padding at the end of xfrm_usersa_info differs between 32-bit x86
and all other architectures because of the x86 specific quirk that u64
variables have 32-bit alignment.
xfrm_usersa_info should have the exact same layout on arm32, arm64
and x86_64.
Arnd
Re: [PATCH 00/31 v2] PTI support for x86_32
On Wed, Feb 21, 2018 at 05:59:34PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti wrote:
> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH wrote:
> >> > > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
> >> > >
> >> > > Back in 2015 someone started to work on that, and properly marked that
> >> > > the kernel could not handle this with commit 74005991b78a ("xfrm: Do
> >> > > not
> >> > > parse 32bits compiled xfrm netlink msg on 64bits host")
> >> > >
> >> > > This is starting to be hit by some Android systems that are moving
> >> > > (yeah, slowly) to 4.4 :(
> >> >
> >> > Does anybody have test-programs/harnesses for this?
> >>
> >> Lorenzo (now on the To: line), is the one that I think is looking into
> >> this, and should have some sort of test for it. Lorenzo?
> >
> > Sorry for the late reply here. The issue is that the xfrm uapi structs
> > don't specify padding at the end, so they're a different size on
> > 32-bit and 64-bit archs. This by itself would be fine, as the kernel
> > could just ignore the (lack of) padding. But some of these structs
> > contain others (e.g., xfrm_userspi_info contains xfrm_usersa_info),
> > and in that case the whole layout after the contained struct is
> > different.
>
> So this is x86 specific then and it already works correctly on all
> other architectures (especially arm64 Android), right?
Why is this an x86-specific issue? I think people have noticed this
with ARM systems given that the original bug report I saw was for an
ARM Android-based system that had a 64bit kernel and 32bit userspace.
thanks,
greg k-h
Re: [PATCH 00/31 v2] PTI support for x86_32
On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti wrote:
> On Wed, Feb 14, 2018 at 5:54 PM, Greg KH wrote:
>> > > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
>> > >
>> > > Back in 2015 someone started to work on that, and properly marked that
>> > > the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
>> > > parse 32bits compiled xfrm netlink msg on 64bits host")
>> > >
>> > > This is starting to be hit by some Android systems that are moving
>> > > (yeah, slowly) to 4.4 :(
>> >
>> > Does anybody have test-programs/harnesses for this?
>>
>> Lorenzo (now on the To: line), is the one that I think is looking into
>> this, and should have some sort of test for it. Lorenzo?
>
> Sorry for the late reply here. The issue is that the xfrm uapi structs
> don't specify padding at the end, so they're a different size on
> 32-bit and 64-bit archs. This by itself would be fine, as the kernel
> could just ignore the (lack of) padding. But some of these structs
> contain others (e.g., xfrm_userspi_info contains xfrm_usersa_info),
> and in that case the whole layout after the contained struct is
> different.
So this is x86 specific then and it already works correctly on all
other architectures (especially arm64 Android), right?
Arnd
Re: [PATCH 00/31 v2] PTI support for x86_32
On Wed, Feb 14, 2018 at 5:54 PM, Greg KH wrote:
> > > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
> > >
> > > Back in 2015 someone started to work on that, and properly marked that
> > > the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
> > > parse 32bits compiled xfrm netlink msg on 64bits host")
> > >
> > > This is starting to be hit by some Android systems that are moving
> > > (yeah, slowly) to 4.4 :(
> >
> > Does anybody have test-programs/harnesses for this?
>
> Lorenzo (now on the To: line), is the one that I think is looking into
> this, and should have some sort of test for it. Lorenzo?
Sorry for the late reply here. The issue is that the xfrm uapi structs
don't specify padding at the end, so they're a different size on
32-bit and 64-bit archs. This by itself would be fine, as the kernel
could just ignore the (lack of) padding. But some of these structs
contain others (e.g., xfrm_userspi_info contains xfrm_usersa_info),
and in that case the whole layout after the contained struct is
different.
On another thread Florian pointed out that he once wrote a patch to
fix this - https://patchwork.ozlabs.org/patch/45855/ . Florian, think
you could revive that?
Re: [PATCH 00/31 v2] PTI support for x86_32
Hi David, thanks a lot for your testing, much appreciated! On Mon, Feb 19, 2018 at 10:45:56PM -0500, David H. Gutteridge wrote: > (1) There is a regression when the QXL display driver is enabled; the > VM hangs during boot. (QXL has been a source of similar trouble in the > past.) I don't have an example trace for it at present. > > (2) There is a regression when the VGA display driver is enabled; it > intermittently (but reproducibly) faults, which makes it impossible > to boot to the graphical login manager. Can you please send me the kernel-config used and the qemu command-line of the VM? I'll try to reproduce this here. > [ 25.439213] kernel BUG at arch/x86/mm/fault.c:268! > [ 25.439218] invalid opcode: [#1] SMP PTI > [ 25.439218] Modules linked in: bochs_drm(+) ttm snd_hda_core > drm_kms_helper snd_hwdep drm snd_seq snd_seq_device snd_pcm snd_timer > snd pcspkr virtio_balloon i2c_piix4 soundcore virtio_console 8139too > crc32c_intel virtio_pci virtio_ring serio_raw virtio 8139cp ata_generic > mii pata_acpi floppy qemu_fw_cfg > [ 25.439236] CPU: 1 PID: 545 Comm: systemd-udevd Tainted: > GW4.15.0+ #1 > [ 25.439237] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.10.2-1 04/01/2014 > [ 25.439241] EIP: vmalloc_fault+0x1e7/0x210 > [ 25.439242] EFLAGS: 00010083 CPU: 1 > [ 25.439243] EAX: 02788000 EBX: d78ecdf8 ECX: 0080 EDX: > [ 25.439244] ESI: 000fd000 EDI: fdf3 EBP: f3f639a0 ESP: f3f63988 > [ 25.439245] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 25.439246] CR0: 80050033 CR2: f7e0 CR3: 33e3a000 CR4: 06f0 This is a kernel-cr3, so that is at least not the issue. Thanks, Joerg
Re: [PATCH 00/31 v2] PTI support for x86_32
On 09/02/18 10:25, Joerg Roedel wrote: > Hi, > > here is the second version of my PTI implementation for > x86_32, based on tip/x86-pti-for-linus. It took a lot longer > than I had hoped, but there have been a number of obstacles > on the way. It also isn't the small patch-set anymore that v1 > was, but compared to it this one actually works :) [...] >I do not claim that I've found the best solution for every >problem I encountered, so please review and give me feedback >on what I should change or solve differently. Of course I am >also interested in all bugs that may still be in there. > >Thanks a lot, > > Joerg Hello, I thought I'd try my hand at testing this patch set from an end user's perspective. I built a test kernel based on Fedora's config-4.15.2-300.fc27.i686+PAE, the only change obviously being the addition of CONFIG_PAGE_TABLE_ISOLATION=y. I ran this kernel in two test environments: an LG X110 netbook, which has an Atom N270 with 1GB of RAM (booted with "pti=on"), and a QEMU VM emulating a quad Core i7 Nehalem setup. (The X110 is the only i686 hardware I had on hand I could practically use. I figured it'd be a suitable low-end hardware spec to work with, even though no one realistically would force-enable PTI on it.) Testing consisted in part of using the laptop's Mate session to remotely render the VM's Xfce session, while both had PTI enabled on their test kernels. The VM also successfully ran the basic kernel tests and the performance test suite that Fedora provides for community testing (https://pagure.io/kernel-tests.git). (Well, it had a hiccup with the performance testing, but that's apparently unrelated to the PTI patches.) The laptop was also used for various everyday activities, like web browsing using Firefox, and document editing using LibreOffice Writer. (It obviously isn't a star at this, but it was usable.) General results: X110: no issues whatsoever. (I was actually expecting more of a noticable performance hit in some aspects.) QEMU VM: I encountered two similar issues: (1) There is a regression when the QXL display driver is enabled; the VM hangs during boot. (QXL has been a source of similar trouble in the past.) I don't have an example trace for it at present. (2) There is a regression when the VGA display driver is enabled; it intermittently (but reproducibly) faults, which makes it impossible to boot to the graphical login manager. [ 25.430588] [drm] Found bochs VGA, ID 0xb0c0. [ 25.431212] [drm] Framebuffer size 16384 kB @ 0xfd00, mmio @ 0xfebd4000. [ 25.432586] [TTM] Zone kernel: Available graphics memory: 426476 kiB [ 25.433099] [TTM] Zone highmem: Available graphics memory: 1549744 kiB [ 25.433890] [TTM] Initializing pool allocator [ 25.434863] [TTM] Initializing DMA pool allocator [ 25.436767] [ cut here ] [ 25.439213] kernel BUG at arch/x86/mm/fault.c:268! [ 25.439218] invalid opcode: [#1] SMP PTI [ 25.439218] Modules linked in: bochs_drm(+) ttm snd_hda_core drm_kms_helper snd_hwdep drm snd_seq snd_seq_device snd_pcm snd_timer snd pcspkr virtio_balloon i2c_piix4 soundcore virtio_console 8139too crc32c_intel virtio_pci virtio_ring serio_raw virtio 8139cp ata_generic mii pata_acpi floppy qemu_fw_cfg [ 25.439236] CPU: 1 PID: 545 Comm: systemd-udevd Tainted: GW4.15.0+ #1 [ 25.439237] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 25.439241] EIP: vmalloc_fault+0x1e7/0x210 [ 25.439242] EFLAGS: 00010083 CPU: 1 [ 25.439243] EAX: 02788000 EBX: d78ecdf8 ECX: 0080 EDX: [ 25.439244] ESI: 000fd000 EDI: fdf3 EBP: f3f639a0 ESP: f3f63988 [ 25.439245] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 25.439246] CR0: 80050033 CR2: f7e0 CR3: 33e3a000 CR4: 06f0 [ 25.439249] Call Trace: [ 25.439254] ? kvm_async_pf_task_wake+0x100/0x100 [ 25.439256] __do_page_fault+0x34d/0x4d0 [ 25.439257] ? __ioremap_caller+0x23a/0x3d0 [ 25.439259] ? kvm_async_pf_task_wake+0x100/0x100 [ 25.439260] do_page_fault+0x27/0xe0 [ 25.439261] ? kvm_async_pf_task_wake+0x100/0x100 [ 25.439263] do_async_page_fault+0x55/0x80 [ 25.439265] common_exception+0xef/0xf6 [ 25.439268] EIP: memset+0xb/0x20 [ 25.439268] EFLAGS: 00010206 CPU: 1 [ 25.439269] EAX: EBX: f7e0 ECX: 0030 EDX: [ 25.439270] ESI: f3f63b5c EDI: f7e0 EBP: f3f63a58 ESP: f3f63a50 [ 25.439271] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 25.439278] ttm_bo_move_memcpy+0x47c/0x4a0 [ttm] [ 25.439283] ttm_bo_handle_move_mem+0x55a/0x580 [ttm] [ 25.439286] ? ttm_bo_mem_space+0x394/0x460 [ttm] [ 25.439290] ttm_bo_validate+0x116/0x130 [ttm] [ 25.439294] bochs_bo_pin+0xa1/0x170 [bochs_drm] [ 25.439297] bochsfb_create+0xce/0x310 [bochs_drm] [ 25.439308] __drm_fb_helper_initial_config_and_unlock+0x1cc/0x460 [drm_kms_helper] [ 25.439314] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] [ 25.439317] bochs_fbdev_i
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun 2018-02-11 11:42:47, Andy Lutomirski wrote: > > > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> > >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a > >>> 32-bit install? > >> > >> Quite easy, yeah. Crossgrading userspace is not for the faint of the > >> heart, > >> but changing just the kernel is fine. > > > > ISTR that iscsi doesn't work when running a 64-bit kernel with a 32-bit > > userspace. I remember someone offered kernel patches to fix it, but I think > > they were rejected. I haven't messed with that stuff in many years, so > > perhaps the userspace side now has accommodation for it. It might be > > something to check on. > > > > At the risk of suggesting heresy, should we consider removing x86_32 support > at some point? We have just found out that majority of 64-bit machines are broken in rather fundamental ways (Spectre) and Intel does not even look interested in fixing that (because it would make them look bad on benchmarks). Even when the Spectre bug is mitigated... this looks like can of worms that can not be closed. OTOH -- we do know that there are non-broken machines out there, unfortunately they are mostly 32-bit :-). Removing support for majority of working machines may not be good idea... [And I really hope future CPUs get at least option to treat cache miss as a side-effect -- thus disalowed during speculation -- and probably option to turn off speculation altogether. AFAICT, it should "only" result in 50% slowdown -- or that was result in some riscv presentation.] Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 00/31 v2] PTI support for x86_32
On Tue, Feb 13, 2018 at 09:25:34AM -0800, Linus Torvalds wrote:
> On Tue, Feb 13, 2018 at 12:54 AM, Greg KH wrote:
> > On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
> >>
> >> ISTR that iscsi doesn't work when running a 64-bit kernel with a
> >> 32-bit userspace. I remember someone offered kernel patches to fix it,
> >> but I think they were rejected. I haven't messed with that stuff in
> >> many years, so perhaps the userspace side now has accommodation for
> >> it. It might be something to check on.
> >
> > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
> >
> > Back in 2015 someone started to work on that, and properly marked that
> > the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
> > parse 32bits compiled xfrm netlink msg on 64bits host")
> >
> > This is starting to be hit by some Android systems that are moving
> > (yeah, slowly) to 4.4 :(
>
> Does anybody have test-programs/harnesses for this?
Lorenzo (now on the To: line), is the one that I think is looking into
this, and should have some sort of test for it. Lorenzo?
> This is an area I care deeply about: I really want people to not have
> any excuses for not upgrading to a 64-bit kernel. It used to be
> autofs (I actually added that whole "packetized pipe" model just to
> make automount "just w ork" even though the stupid protocol used a
> pipe to send command packets that had different layout on 32-bit and
> 64-bit).
>
> See commit 64f371bc3107 ("autofs: make the autofsv5 packet file
> descriptor use a packetized pipe") for some discussion of that
> particular saga.
>
> Some drm people used to run 32-bit kernels because of compat worries,
> and that would have been a disaster. They got very good about not
> having compat issues.
>
> So let's try to fix the iscsi and ipsec issues. Not that anybody sane
> should use that overly complex ipsec thing, and I think we should
> strive to merge WireGuard and get people moved over to that instead,
> but I haven't heard anything from davem about it since I last asked..
> I have some hope that it's slowly happening.
WireGuard is still being worked on, it needs some crypto library changes
that should be coming soon, but will probably be 6 months out at the
earliest to get merged. There are still lots of people using IPSEC :(
thanks,
greg k-h
Re: [PATCH 00/31 v2] PTI support for x86_32
On Tue, Feb 13, 2018 at 12:54 AM, Greg KH wrote:
> On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
>>
>> ISTR that iscsi doesn't work when running a 64-bit kernel with a
>> 32-bit userspace. I remember someone offered kernel patches to fix it,
>> but I think they were rejected. I haven't messed with that stuff in
>> many years, so perhaps the userspace side now has accommodation for
>> it. It might be something to check on.
>
> IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
>
> Back in 2015 someone started to work on that, and properly marked that
> the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
> parse 32bits compiled xfrm netlink msg on 64bits host")
>
> This is starting to be hit by some Android systems that are moving
> (yeah, slowly) to 4.4 :(
Does anybody have test-programs/harnesses for this?
This is an area I care deeply about: I really want people to not have
any excuses for not upgrading to a 64-bit kernel. It used to be
autofs (I actually added that whole "packetized pipe" model just to
make automount "just w ork" even though the stupid protocol used a
pipe to send command packets that had different layout on 32-bit and
64-bit).
See commit 64f371bc3107 ("autofs: make the autofsv5 packet file
descriptor use a packetized pipe") for some discussion of that
particular saga.
Some drm people used to run 32-bit kernels because of compat worries,
and that would have been a disaster. They got very good about not
having compat issues.
So let's try to fix the iscsi and ipsec issues. Not that anybody sane
should use that overly complex ipsec thing, and I think we should
strive to merge WireGuard and get people moved over to that instead,
but I haven't heard anything from davem about it since I last asked..
I have some hope that it's slowly happening.
Linus
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
> > On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote:
> >
> >> Does Debian make it easy to upgrade to a 64-bit kernel if you have a
> >> 32-bit install?
> >
> > Quite easy, yeah. Crossgrading userspace is not for the faint of the heart,
> > but changing just the kernel is fine.
>
> ISTR that iscsi doesn't work when running a 64-bit kernel with a
> 32-bit userspace. I remember someone offered kernel patches to fix it,
> but I think they were rejected. I haven't messed with that stuff in
> many years, so perhaps the userspace side now has accommodation for
> it. It might be something to check on.
IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
Back in 2015 someone started to work on that, and properly marked that
the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
parse 32bits compiled xfrm netlink msg on 64bits host")
This is starting to be hit by some Android systems that are moving
(yeah, slowly) to 4.4 :(
thanks,
greg k-h
Re: [PATCH 00/31 v2] PTI support for x86_32
Hi Ingo, On Sun, Feb 11, 2018 at 08:13:12PM +0100, Ingo Molnar wrote: > Could you please measure the PTI kernel vs. vanilla kernel? Okay, did that, here is the data. The test machine is a Xeon E5-1620v2, which is Ivy Bridge based (no PCIE) and has 4C/8T. I ran the 2 tests you suggested: * Test-1: perf stat --null --sync --repeat 10 perf bench sched messaging -g 20 * Test-2: perf stat --null --sync --repeat 10 perf bench sched messaging -g 20 -t The tests ran on these kernels: * tip-32-pae: current top of tip/x86-tip-for-linus branch, compiled as a 32 bit kernel with PAE (commit b2ac58f90540e39324e7a29a7ad471407ae0bf48) * pti-32-pae: Same as above with my patches on-top, as on git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git pti-x32-v2 compiled as a 32 bit kernel with PAE (commit dbb0074f778b396a11e0c897fef9d0c4583e7ccb) * pti-off-64: current top of tip/x86-tip-for-linus branch, compiled as a 64 bit kernel, booted with pti=off (commit b2ac58f90540e39324e7a29a7ad471407ae0bf48) * pti-on-64: current top of tip/x86-tip-for-linus branch, compiled as a 64 bit kernel, booted with pti=on (commit b2ac58f90540e39324e7a29a7ad471407ae0bf48) Results are: | Test-1 | Test-2 ++- tip-32-pae | 0.28s (+-0.44%)| 0.27s (+-2.15%) ++- pti-32-pae | 0.44s (+-0.40%)| 0.42s (+-0.48%) ++- pti-off-64 | 0.24s (+-0.40%)| 0.25s (+-1.31%) ++- pti-on-64 | 0.30s (+-0.47%)| 0.31s (+-0.95%) On 32 bit with PTI enabled the test needs 157% (non-threaded) and 156% (threaded) of time compared to the non-PTI baseline. On 64 bit these numbers are 125% (non-threaded) and 124% (threaded). The pti-32-pae kernel still used 'rep movsb' in the entry code. I replaced that with 'rep movsl' and measured again, but overhead is still around 152%. I also measured cycles with 'perf record' to see where the additional time is spent. The report showed around 25% in entry_SYSENTER_32 for the pti-32-pae kernel. The same report on the tip-32-pae kernel shows around 2.5% for the same symbol. The entry_SYSENTER_32 path does no stack-copy on entry (it only push/pops 8 bytes for the cr3 switch), but one full pt_regs copy on exit. The exit-path was easy to optimize, I got it to the point where it only copied 8 bytes to the entry stack (flags and eax). This way I got the 'perf report' numbers for entry_SYSENTER_32 down to around 20%, but the overall numbers for Test-1 and Test-2 are still at around 150% of the baseline. So it seems that most of the additional time is actually spent switching the cr3s. Regards, Joerg
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun, 2018-02-11 at 14:30 -0800, Andy Lutomirski wrote: > > > > > On Feb 11, 2018, at 2:12 PM, James Bottomley > nPartnership.com> wrote: > > > > > > > > On Sun, 2018-02-11 at 11:42 -0800, Andy Lutomirski wrote: > > > > > > > > > > > On Feb 11, 2018, at 9:40 AM, Mark D Rustad > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Feb 11, 2018, at 2:59 AM, Adam Borowski > > > > pl> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Does Debian make it easy to upgrade to a 64-bit kernel if > > > > > > you > > > > > > have a > > > > > > 32-bit install? > > > > > > > > > > Quite easy, yeah. Crossgrading userspace is not for the > > > > > faint of the heart, but changing just the kernel is fine. > > > > > > > > ISTR that iscsi doesn't work when running a 64-bit kernel with > > > > a 32-bit userspace. I remember someone offered kernel patches > > > > to fix it, but I think they were rejected. I haven't messed > > > > with that stuff in many years, so perhaps the userspace side > > > > now has accommodation for it. It might be something to check > > > > on. > > > > > > > > > > At the risk of suggesting heresy, should we consider removing > > > x86_32 support at some point? > > > > Hey, my cloud server is 32 bit: > > > > bedivere:~# cat /proc/cpuinfo > > processor: 0 > > vendor_id: GenuineIntel > > cpu family: 15 > > model: 2 > > model name: Intel(R) Pentium(R) 4 CPU 2.80GHz > > stepping: 9 > > microcode: 0x2e > > cpu MHz: 2813.464 > > [...] > > > > I suspect a lot of people are in the same position: grandfathered > > in on an old hosting plan, but not really willing to switch to a > > new 64 bit box because the monthly cost about doubles and nothing > > it does is currently anywhere up to (let alone over) the capacity > > of the single 686 processor. > > > > The thing which is making me consider it is actually getting a TPM > > to protect the private keys, but doubling the monthly cost is still > > a huge disincentive. > > Where are they hosting this? Last I checked, replacing a P4 and > motherboard with something new paid for itself in about a year in > power savings. It's a rented server not a co-lo cage. I don't doubt it's costing the hosting provider, but they're keeping my rates low. James
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun, 11 Feb 2018 11:42:47 -0800 Andy Lutomirski wrote: > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> > >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a > >>> 32-bit install? > >> > >> Quite easy, yeah. Crossgrading userspace is not for the faint of the > >> heart, > >> but changing just the kernel is fine. > > > > ISTR that iscsi doesn't work when running a 64-bit kernel with a 32-bit > > userspace. I remember someone offered kernel patches to fix it, but I think > > they were rejected. I haven't messed with that stuff in many years, so > > perhaps the userspace side now has accommodation for it. It might be > > something to check on. > > > > At the risk of suggesting heresy, should we consider removing x86_32 support > at some point? Probably - although it's still relevant for Quark. I can't think of any other in-production 32bit only processor at this point. Big core Intel went 64bit 2006 or so, atoms mostly 2008 or so (with some stragglers that are 32 or 64 bit depending if it's enabled) until 2011 (Cedartrail) If someone stuck a fork in it just after the next long term kernel release then by the time that expired it would probably be historical interest only. Does it not depend if there is someone crazy enough to maintain it however - 68000 is doing fine 8) Alan
Re: [PATCH 00/31 v2] PTI support for x86_32
> On Feb 11, 2018, at 2:12 PM, James Bottomley > wrote: > >> On Sun, 2018-02-11 at 11:42 -0800, Andy Lutomirski wrote: >> >>> On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: >>> >>> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > > Does Debian make it easy to upgrade to a 64-bit kernel if you > have a > 32-bit install? Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, but changing just the kernel is fine. >>> >>> ISTR that iscsi doesn't work when running a 64-bit kernel with a >>> 32-bit userspace. I remember someone offered kernel patches to fix >>> it, but I think they were rejected. I haven't messed with that >>> stuff in many years, so perhaps the userspace side now has >>> accommodation for it. It might be something to check on. >>> >> >> At the risk of suggesting heresy, should we consider removing x86_32 >> support at some point? > > Hey, my cloud server is 32 bit: > > bedivere:~# cat /proc/cpuinfo > processor: 0 > vendor_id: GenuineIntel > cpu family: 15 > model: 2 > model name: Intel(R) Pentium(R) 4 CPU 2.80GHz > stepping: 9 > microcode: 0x2e > cpu MHz: 2813.464 > [...] > > I suspect a lot of people are in the same position: grandfathered in on > an old hosting plan, but not really willing to switch to a new 64 bit > box because the monthly cost about doubles and nothing it does is > currently anywhere up to (let alone over) the capacity of the single > 686 processor. > > The thing which is making me consider it is actually getting a TPM to > protect the private keys, but doubling the monthly cost is still a huge > disincentive. Where are they hosting this? Last I checked, replacing a P4 and motherboard with something new paid for itself in about a year in power savings. > > James >
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun 2018-02-11 11:42:47, Andy Lutomirski wrote: > > > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> > >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a > >>> 32-bit install? > >> > >> Quite easy, yeah. Crossgrading userspace is not for the faint of the > >> heart, > >> but changing just the kernel is fine. > > > > ISTR that iscsi doesn't work when running a 64-bit kernel with a 32-bit > > userspace. I remember someone offered kernel patches to fix it, but I think > > they were rejected. I haven't messed with that stuff in many years, so > > perhaps the userspace side now has accommodation for it. It might be > > something to check on. > > It might make sense to retry those patches... if we want people to move to 64bit kernels, it makes sense to provide complete emulation for 32bit distros... > At the risk of suggesting heresy, should we consider removing x86_32 > support at some point? Heresy! We still support 486s. I don't know if anyone really uses them, but T40p is an acceptable machine to ssh from. X60 is still the machine I prefer for traveling. Fast enough if you don't compile, and nicer keyboard/screen than X220... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun, 2018-02-11 at 11:42 -0800, Andy Lutomirski wrote: > > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > > > > > > > > On Feb 11, 2018, at 2:59 AM, Adam Borowski > > > wrote: > > > > > > > > > > > Does Debian make it easy to upgrade to a 64-bit kernel if you > > > > have a > > > > 32-bit install? > > > > > > Quite easy, yeah. Crossgrading userspace is not for the faint of > > > the heart, > > > but changing just the kernel is fine. > > > > ISTR that iscsi doesn't work when running a 64-bit kernel with a > > 32-bit userspace. I remember someone offered kernel patches to fix > > it, but I think they were rejected. I haven't messed with that > > stuff in many years, so perhaps the userspace side now has > > accommodation for it. It might be something to check on. > > > > At the risk of suggesting heresy, should we consider removing x86_32 > support at some point? Hey, my cloud server is 32 bit: bedivere:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 9 microcode : 0x2e cpu MHz : 2813.464 [...] I suspect a lot of people are in the same position: grandfathered in on an old hosting plan, but not really willing to switch to a new 64 bit box because the monthly cost about doubles and nothing it does is currently anywhere up to (let alone over) the capacity of the single 686 processor. The thing which is making me consider it is actually getting a TPM to protect the private keys, but doubling the monthly cost is still a huge disincentive. James
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sun, Feb 11, 2018 at 11:42 AM, Andy Lutomirski wrote: > > At the risk of suggesting heresy, should we consider removing x86_32 support > at some point? Maybe in five or ten years. Not in the near future, I'm afraid. We removed support for the 80386 back at the end of 2012. At that point it just became too painful to support at all. In contrast, we could continue supporting 32-bit for a long time. Even if it might be in some degraded form (ie no PTI at all, or only a slow one). It's not really a lot of pain for people who don't care. Linus
Re: [PATCH 00/31 v2] PTI support for x86_32
On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: >> >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a >>> 32-bit install? >> >> Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, >> but changing just the kernel is fine. > > ISTR that iscsi doesn't work when running a 64-bit kernel with a 32-bit > userspace. I remember someone offered kernel patches to fix it, but I think > they were rejected. I haven't messed with that stuff in many years, so > perhaps the userspace side now has accommodation for it. It might be > something to check on. > At the risk of suggesting heresy, should we consider removing x86_32 support at some point?
Re: [PATCH 00/31 v2] PTI support for x86_32
* Joerg Roedel wrote: > Hi Andy, > > On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > > One thing worth noting is that performance of this whole series is > > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > > any kernel built with this option set that runs on a CPU that has the > > PCID bit set in CPUID should print a big fat warning like "WARNING: > > you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your > > performance will increase dramatically if you switch to a 64-bit > > kernel." > > Thanks for your review. I can add this warning, but I just hope that not > a lot of people will actually see it :) Could you please measure the PTI kernel vs. vanilla kernel? Nothing complex, just perf's built-in scheduler and syscall benchmark should be enough: perf stat --null --sync --repeat 10 perf bench sched messaging -g 20 this should give us a pretty good worst-case overhead figure for process workloads. Add '-t' to test threaded workloads as well: perf stat --null --sync --repeat 10 perf bench sched messaging -g 20 -t The 10 runs used should be enough to reach good stability in practice: Performance counter stats for 'perf bench sched messaging -g 20 -t' (10 runs): 0.380742219 seconds time elapsed ( +- 0.73% ) Maybe do the same on the 64-bit kernel as well, so that we have 4 good data points on the same hardware? Thanks, Ingo
Re: [PATCH 00/31 v2] PTI support for x86_32
> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> Does Debian make it easy to upgrade to a 64-bit kernel if you have a >> 32-bit install? > > Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, > but changing just the kernel is fine. ISTR that iscsi doesn't work when running a 64-bit kernel with a 32-bit userspace. I remember someone offered kernel patches to fix it, but I think they were rejected. I haven't messed with that stuff in many years, so perhaps the userspace side now has accommodation for it. It might be something to check on. -- Mark Rustad, mrus...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sat, Feb 10, 2018 at 12:22:59PM -0800, Linus Torvalds wrote: > On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski wrote: > > > > Alas, we got some data: > > https://popcon.debian.org/ says 20% of x86 users have i386 as their main ABI > > (current; people with popcon installed). > > One of the issues I've seen is that people often simply move a disk > (or copy an installation) when upgrading machines. Less skilled users (ie, most of them) had until recently a different hurdle: the "32-bit" option was shown way too prominently, without an explanation. > Does Debian make it easy to upgrade to a 64-bit kernel if you have a > 32-bit install? Quite easy, yeah. Crossgrading userspace is not for the faint of the heart, but changing just the kernel is fine. > Because if not, then it's entirely possible that a lot > of people started out with a 32-bit install (maybe they even had a > 64-bit kernel, but they started when the 32-bit install was the > default one), and never upgraded their kernel. > > It really should be easy to _just_ upgrade the kernel. But if the > distro doesn't support it, most people won't do it. I just realized that, for people who use distro kernels, the right way is a message during upgrade. Ie, it's up to the packagers rather than you. Having a dire-sounding printk, though, would still be nice. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Re: [PATCH 00/31 v2] PTI support for x86_32
On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski wrote: > > Alas, we got some data: > https://popcon.debian.org/ says 20% of x86 users have i386 as their main ABI > (current; people with popcon installed). One of the issues I've seen is that people often simply move a disk (or copy an installation) when upgrading machines. Does Debian make it easy to upgrade to a 64-bit kernel if you have a 32-bit install? Because if not, then it's entirely possible that a lot of people started out with a 32-bit install (maybe they even had a 64-bit kernel, but they started when the 32-bit install was the default one), and never upgraded their kernel. It really should be easy to _just_ upgrade the kernel. But if the distro doesn't support it, most people won't do it. Linus
Re: [PATCH 00/31 v2] PTI support for x86_32
On Fri, Feb 09, 2018 at 08:11:12PM +0100, Joerg Roedel wrote: > On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > > One thing worth noting is that performance of this whole series is > > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > > any kernel built with this option set that runs on a CPU that has the > > PCID bit set in CPUID should print a big fat warning like "WARNING: > > you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your > > performance will increase dramatically if you switch to a 64-bit > > kernel." > > Thanks for your review. I can add this warning, but I just hope that not > a lot of people will actually see it :) Alas, we got some data: https://popcon.debian.org/ says 20% of x86 users have i386 as their main ABI (current; people with popcon installed). Of those, 80% use 32-bit kernels: i686 881, x86_64 229, i586 14 (uname -m included in bug reports; data for 2016) -- and bug reporters tend to have more clue than the average user. There's no way so many folks still use pre-2004 computers. Thus, if you could include that big fat warning, distro developers would be thankful. Make it show fiery letters if you can. Preferably, we'd want a huge mallet reach out of the screen and bonk the user on the head, but with that impossible, a scary message would help. Let them use 32-bit userland, but if someone runs such a kernel on a modern machine, some kind of verbal abuse is warranted. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Re: [PATCH 00/31 v2] PTI support for x86_32
On 09/02/2018 21:09, Pavel Machek wrote: > On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote: >> PCID bit set in CPUID should print a big fat warning like "WARNING: >> you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your >> performance will increase dramatically if you switch to a 64-bit >> kernel." > Hardware supports PCID even on 32-bit kernels, no? Attempting to set CR4.PCIDE is disallowed outside of long mode. It is strictly a 64bit-only feature. ~Andrew
Re: [PATCH 00/31 v2] PTI support for x86_32
On Fri, Feb 9, 2018 at 1:09 PM, Pavel Machek wrote: > > Hardware supports PCID even on 32-bit kernels, no? We're not adding support for it even if it were possible. No way. Christ, even if you want to run 32-bit user code, you'd better run a 64-bit kernel. Backporting the PCID bits to something that no actual real developer will ever use is crazy and unacceptable. Linus
Re: [PATCH 00/31 v2] PTI support for x86_32
On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote: > On Fri, Feb 9, 2018 at 9:25 AM, Joerg Roedel wrote: > > Hi, > > > > here is the second version of my PTI implementation for > > x86_32, based on tip/x86-pti-for-linus. It took a lot longer > > than I had hoped, but there have been a number of obstacles > > on the way. It also isn't the small patch-set anymore that v1 > > was, but compared to it this one actually works :) > > One thing worth noting is that performance of this whole series is > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > any kernel built with this option set that runs on a CPU that has >the What kind of slowdown are we talking about here? > PCID bit set in CPUID should print a big fat warning like "WARNING: > you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your > performance will increase dramatically if you switch to a 64-bit > kernel." Hardware supports PCID even on 32-bit kernels, no? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 00/31 v2] PTI support for x86_32
Hi Andy, On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > One thing worth noting is that performance of this whole series is > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > any kernel built with this option set that runs on a CPU that has the > PCID bit set in CPUID should print a big fat warning like "WARNING: > you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your > performance will increase dramatically if you switch to a 64-bit > kernel." Thanks for your review. I can add this warning, but I just hope that not a lot of people will actually see it :) Joerg
Re: [PATCH 00/31 v2] PTI support for x86_32
On Fri, Feb 9, 2018 at 9:25 AM, Joerg Roedel wrote: > Hi, > > here is the second version of my PTI implementation for > x86_32, based on tip/x86-pti-for-linus. It took a lot longer > than I had hoped, but there have been a number of obstacles > on the way. It also isn't the small patch-set anymore that v1 > was, but compared to it this one actually works :) One thing worth noting is that performance of this whole series is going to be abysmal due to the complete lack of 32-bit PCID. Maybe any kernel built with this option set that runs on a CPU that has the PCID bit set in CPUID should print a big fat warning like "WARNING: you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your performance will increase dramatically if you switch to a 64-bit kernel."
Re: [PATCH 00/31 v2] PTI support for x86_32
On 09/02/18 13:35, Joerg Roedel wrote: > Hi Juergen, > > On Fri, Feb 09, 2018 at 01:11:42PM +0100, Juergen Gross wrote: >> On 09/02/18 10:25, Joerg Roedel wrote: >>> XENPV is also untested from my side, but I added checks to >>> not do the stack switches in the entry-code when XENPV is >>> enabled, so hopefully it works. But someone should test it, >>> of course. >> That's unfortunate. 32 bit XENPV kernel is vulnerable to Meltdown, too. >> I'll have a look whether 32 bit XENPV is still working, though. >> >> Adding support for KPTI with Xen PV should probably be done later. :-) > Not sure how much is missing to make it work there, one point is > certainly to write the right stack into tss.sp0 for xenpv on 32bit. This > write has a check to only happen for !xenpv. > > But let's first test the code as-is on XENPV and see if it still boots > :) IMO, the only sensible way to do KPTI + Xen PV is to have Xen to do the pagetable switch for 32bit like we already do for 64bit guests. All context switches already pass through the hypervisor, and it saves the guest having to make the updates itself (which will trap for auditing) or having to juggle the set_stack_base() semantics. ~Andrew
Re: [PATCH 00/31 v2] PTI support for x86_32
Hi Juergen, On Fri, Feb 09, 2018 at 01:11:42PM +0100, Juergen Gross wrote: > On 09/02/18 10:25, Joerg Roedel wrote: > > XENPV is also untested from my side, but I added checks to > > not do the stack switches in the entry-code when XENPV is > > enabled, so hopefully it works. But someone should test it, > > of course. > > That's unfortunate. 32 bit XENPV kernel is vulnerable to Meltdown, too. > I'll have a look whether 32 bit XENPV is still working, though. > > Adding support for KPTI with Xen PV should probably be done later. :-) Not sure how much is missing to make it work there, one point is certainly to write the right stack into tss.sp0 for xenpv on 32bit. This write has a check to only happen for !xenpv. But let's first test the code as-is on XENPV and see if it still boots :) Thanks, Joerg
Re: [PATCH 00/31 v2] PTI support for x86_32
On 09/02/18 10:25, Joerg Roedel wrote: > Hi, > > here is the second version of my PTI implementation for > x86_32, based on tip/x86-pti-for-linus. It took a lot longer > than I had hoped, but there have been a number of obstacles > on the way. It also isn't the small patch-set anymore that v1 > was, but compared to it this one actually works :) > > The biggest changes were necessary in the entry code, a lot > of it is moving code around, but there are also significant > changes to get all cases covered. This includes NMIs and > exceptions on the kernel exit-path where we are already on > the entry-stack. To make this work I decided to mostly split > up the common kernel-exit path into a return-to-kernel, > return-to-user and return-from-nmi part. > > On the page-table side I had to do a lot of special cases > for PAE because PAE paging is so, well, special. The biggest > example here is the LDT mapping code, which needs to work on > the PMD level instead of PGD when PAE is enabled. > > During development I also experimented with unshared PMDs > between the kernel and the user page-tables for PAE. It > worked by allocating 8k PMDs and using the lower half for > the kernel and the upper half for the user page-table. While > this worked and allowed me to NX-protect the user-space > address-range in the kernel page-table, it also required 5 > order-1 allocations in low-mem for each process. In my > testing I got this to fail pretty quickly and trigger OOM, > so I abandoned the approach for now. > > Here is how I tested these patches: > > * Booted on a real machine (4C/8T, 16GB RAM) and run > an overnight load-test with 'perf top' running > (for the NMIs), the ldt_gdt selftest running in a > loop (for more stress on the entry/exit path) and > a -j16 kernel compile also running in a loop. The > box survived the test, which ran for more than 18 > hours. > > * Tested most x86 selftests in the kernel on the > real machine. This showed no regressions. I did > not run the mpx and protection-key tests, as the > machine does not support these features, and I > also skipped the check_initial_reg_state test, as > it made problems while compiling and it didn't > seem relevant enough to fix that for this > patch-set. > > * Boot tested all valid combinations of [NO]HIGHMEM* vs. > VMSPLIT* vs. PAE in KVM. All booted fine. > > * Did compile-tests with various configs (allyes, > allmod, defconfig, ..., basically what I usually > use to test the iommu-tree as well). All compiled > fine. > > * Some basic compile, boot and runtime testing of > 64 bit to make sure I didn't break anything there. > > I did not explicitly test wine and dosemu, but since the > vm86 and the ldt_gdt self-tests all passed fine I am > confident that those will also still work. > > XENPV is also untested from my side, but I added checks to > not do the stack switches in the entry-code when XENPV is > enabled, so hopefully it works. But someone should test it, > of course. That's unfortunate. 32 bit XENPV kernel is vulnerable to Meltdown, too. I'll have a look whether 32 bit XENPV is still working, though. Adding support for KPTI with Xen PV should probably be done later. :-) Juergen
