Re: [PATCH 00/31 v2] PTI support for x86_32

Re: [PATCH 00/31 v2] PTI support for x86_32

[David H. Gutteridge]

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 @ 0xfd000000, 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: 0000 [#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:
G        W        4.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: 00000080 EDX: 00000000
[   25.439244] ESI: 000fd000 EDI: fd0000f3 EBP: f3f639a0 ESP: f3f63988
[   25.439245]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   25.439246] CR0: 80050033 CR2: f7e00000 CR3: 33e3a000 CR4: 000006f0
[   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: 00000000 EBX: f7e00000 ECX: 00300000 EDX: 00000000
[   25.439270] ESI: f3f63b5c EDI: f7e00000 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_init+0x74/0x80 [bochs_drm]
[   25.439319]  bochs_load+0x7a/0x90 [bochs_drm]
[   25.439333]  drm_dev_register+0x133/0x1b0 [drm]
[   25.439343]  drm_get_pci_dev+0x86/0x160 [drm]
[   25.439346]  bochs_pci_probe+0xcb/0x110 [bochs_drm]
[   25.439348]  ? bochs_load+0x90/0x90 [bochs_drm]
[   25.439351]  pci_device_probe+0xc7/0x160
[   25.439353]  driver_probe_device+0x2dc/0x460
[   25.439354]  __driver_attach+0x99/0xe0
[   25.439356]  ? driver_probe_device+0x460/0x460
[   25.439357]  bus_for_each_dev+0x5a/0xa0
[   25.439359]  driver_attach+0x19/0x20
[   25.439360]  ? driver_probe_device+0x460/0x460
[   25.439362]  bus_add_driver+0x187/0x230
[   25.439363]  ? 0xf7afa000
[   25.439364]  driver_register+0x56/0xd0
[   25.439365]  ? 0xf7afa000
[   25.439367]  __pci_register_driver+0x3a/0x40
[   25.439369]  bochs_init+0x41/0x1000 [bochs_drm]
[   25.439371]  do_one_initcall+0x49/0x170
[   25.439373]  ? _cond_resched+0x2a/0x40
[   25.439375]  ? kmem_cache_alloc_trace+0x175/0x1e0
[   25.439376]  ? do_init_module+0x21/0x1dc
[   25.439378]  ? do_init_module+0x21/0x1dc
[   25.439379]  do_init_module+0x50/0x1dc
[   25.439380]  load_module+0x1fce/0x28e0
[   25.439383]  SyS_finit_module+0x8a/0xe0
[   25.439385]  do_fast_syscall_32+0x81/0x1b0
[   25.439518]  entry_SYSENTER_32+0x5f/0xb9
[   25.439519] EIP: 0xb7f21cf9
[   25.439520] EFLAGS: 00000246 CPU: 1
[   25.439521] EAX: ffffffda EBX: 00000011 ECX: b7afae75 EDX: 00000000
[   25.439522] ESI: 019d5740 EDI: 019acc00 EBP: 019ade00 ESP: bff9bb4c
[   25.439524]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[   25.439525] Code: e2 00 f0 1f 00 81 ea 00 00 20 00 21 d0 8b 55 e8 89
c6 81 e2 ff 0f 00 00 0f ac d6 0c 8d 04 b6 c1 e0 03 39 45 ec 0f 84 27 ff
ff ff <0f> 0b 8d b4 26 00 00 00 00 83 c4 0c ba ff ff ff ff 5b 89 d0 5e
[   25.439547] EIP: vmalloc_fault+0x1e7/0x210 SS:ESP: 0068:f3f63988
[   25.439548] ---[ end trace 18f2d11043a28ec0 ]---

The Virtio and VMVGA display drivers both worked consistently for me.

I haven't tested a non-PAE kernel, but can do so if it's of interest.
Or I can provide further details or testing if need be. If so, please
CC me. I hope this is of some use.

Regards,

Dave

Re: [PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

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: 0000 [#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:
> G        W        4.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: 00000080 EDX: 00000000
> [   25.439244] ESI: 000fd000 EDI: fd0000f3 EBP: f3f639a0 ESP: f3f63988
> [   25.439245]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [   25.439246] CR0: 80050033 CR2: f7e00000 CR3: 33e3a000 CR4: 000006f0

This is a kernel-cr3, so that is at least not the issue.


Thanks,

	Joerg

[PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

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.

I also pushed these patches to

	git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git pti-x32-v2

for easier testing.

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


Joerg Roedel (31):
  x86/asm-offsets: Move TSS_sp0 and TSS_sp1 to asm-offsets.c
  x86/entry/32: Rename TSS_sysenter_sp0 to TSS_entry_stack
  x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler
  x86/entry/32: Put ESPFIX code into a macro
  x86/entry/32: Unshare NMI return path
  x86/entry/32: Split off return-to-kernel path
  x86/entry/32: Restore segments before int registers
  x86/entry/32: Enter the kernel via trampoline stack
  x86/entry/32: Leave the kernel via trampoline stack
  x86/entry/32: Introduce SAVE_ALL_NMI and RESTORE_ALL_NMI
  x86/entry/32: Add PTI cr3 switches to NMI handler code
  x86/entry/32: Add PTI cr3 switch to non-NMI entry/exit points
  x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack
  x86/pgtable/pae: Unshare kernel PMDs when PTI is enabled
  x86/pgtable/32: Allocate 8k page-tables when PTI is enabled
  x86/pgtable: Move pgdp kernel/user conversion functions to pgtable.h
  x86/pgtable: Move pti_set_user_pgd() to pgtable.h
  x86/pgtable: Move two more functions from pgtable_64.h to pgtable.h
  x86/mm/pae: Populate valid user PGD entries
  x86/mm/pae: Populate the user page-table with user pgd's
  x86/mm/legacy: Populate the user page-table with user pgd's
  x86/mm/pti: Add an overflow check to pti_clone_pmds()
  x86/mm/pti: Define X86_CR3_PTI_PCID_USER_BIT on x86_32
  x86/mm/pti: Clone CPU_ENTRY_AREA on PMD level on x86_32
  x86/mm/dump_pagetables: Define INIT_PGD
  x86/pgtable/pae: Use separate kernel PMDs for user page-table
  x86/ldt: Reserve address-space range on 32 bit for the LDT
  x86/ldt: Define LDT_END_ADDR
  x86/ldt: Split out sanity check in map_ldt_struct()
  x86/ldt: Enable LDT user-mapping for PAE
  x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32

 arch/x86/entry/entry_32.S                   | 581 ++++++++++++++++++++++------
 arch/x86/include/asm/mmu_context.h          |   4 -
 arch/x86/include/asm/pgtable-2level.h       |   9 +
 arch/x86/include/asm/pgtable-2level_types.h |   3 +
 arch/x86/include/asm/pgtable-3level.h       |   7 +
 arch/x86/include/asm/pgtable-3level_types.h |   6 +-
 arch/x86/include/asm/pgtable.h              |  88 +++++
 arch/x86/include/asm/pgtable_32_types.h     |   9 +-
 arch/x86/include/asm/pgtable_64.h           |  85 ----
 arch/x86/include/asm/pgtable_64_types.h     |   4 +
 arch/x86/include/asm/pgtable_types.h        |  26 +-
 arch/x86/include/asm/processor-flags.h      |   8 +-
 arch/x86/include/asm/switch_to.h            |   6 +-
 arch/x86/kernel/asm-offsets.c               |   5 +
 arch/x86/kernel/asm-offsets_32.c            |   2 +-
 arch/x86/kernel/asm-offsets_64.c            |   2 -
 arch/x86/kernel/cpu/common.c                |   5 +-
 arch/x86/kernel/head_32.S                   |  20 +-
 arch/x86/kernel/ldt.c                       | 137 +++++--
 arch/x86/kernel/process.c                   |   2 -
 arch/x86/kernel/process_32.c                |  10 +-
 arch/x86/mm/dump_pagetables.c               |  21 +-
 arch/x86/mm/pgtable.c                       | 105 ++++-
 arch/x86/mm/pti.c                           |  24 ++
 security/Kconfig                            |   2 +-
 25 files changed, 888 insertions(+), 283 deletions(-)

-- 
2.7.4

[PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

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.

I also pushed these patches to

	git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git pti-x32-v2

for easier testing.

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


Joerg Roedel (31):
  x86/asm-offsets: Move TSS_sp0 and TSS_sp1 to asm-offsets.c
  x86/entry/32: Rename TSS_sysenter_sp0 to TSS_entry_stack
  x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler
  x86/entry/32: Put ESPFIX code into a macro
  x86/entry/32: Unshare NMI return path
  x86/entry/32: Split off return-to-kernel path
  x86/entry/32: Restore segments before int registers
  x86/entry/32: Enter the kernel via trampoline stack
  x86/entry/32: Leave the kernel via trampoline stack
  x86/entry/32: Introduce SAVE_ALL_NMI and RESTORE_ALL_NMI
  x86/entry/32: Add PTI cr3 switches to NMI handler code
  x86/entry/32: Add PTI cr3 switch to non-NMI entry/exit points
  x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack
  x86/pgtable/pae: Unshare kernel PMDs when PTI is enabled
  x86/pgtable/32: Allocate 8k page-tables when PTI is enabled
  x86/pgtable: Move pgdp kernel/user conversion functions to pgtable.h
  x86/pgtable: Move pti_set_user_pgd() to pgtable.h
  x86/pgtable: Move two more functions from pgtable_64.h to pgtable.h
  x86/mm/pae: Populate valid user PGD entries
  x86/mm/pae: Populate the user page-table with user pgd's
  x86/mm/legacy: Populate the user page-table with user pgd's
  x86/mm/pti: Add an overflow check to pti_clone_pmds()
  x86/mm/pti: Define X86_CR3_PTI_PCID_USER_BIT on x86_32
  x86/mm/pti: Clone CPU_ENTRY_AREA on PMD level on x86_32
  x86/mm/dump_pagetables: Define INIT_PGD
  x86/pgtable/pae: Use separate kernel PMDs for user page-table
  x86/ldt: Reserve address-space range on 32 bit for the LDT
  x86/ldt: Define LDT_END_ADDR
  x86/ldt: Split out sanity check in map_ldt_struct()
  x86/ldt: Enable LDT user-mapping for PAE
  x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32

 arch/x86/entry/entry_32.S                   | 581 ++++++++++++++++++++++------
 arch/x86/include/asm/mmu_context.h          |   4 -
 arch/x86/include/asm/pgtable-2level.h       |   9 +
 arch/x86/include/asm/pgtable-2level_types.h |   3 +
 arch/x86/include/asm/pgtable-3level.h       |   7 +
 arch/x86/include/asm/pgtable-3level_types.h |   6 +-
 arch/x86/include/asm/pgtable.h              |  88 +++++
 arch/x86/include/asm/pgtable_32_types.h     |   9 +-
 arch/x86/include/asm/pgtable_64.h           |  85 ----
 arch/x86/include/asm/pgtable_64_types.h     |   4 +
 arch/x86/include/asm/pgtable_types.h        |  26 +-
 arch/x86/include/asm/processor-flags.h      |   8 +-
 arch/x86/include/asm/switch_to.h            |   6 +-
 arch/x86/kernel/asm-offsets.c               |   5 +
 arch/x86/kernel/asm-offsets_32.c            |   2 +-
 arch/x86/kernel/asm-offsets_64.c            |   2 -
 arch/x86/kernel/cpu/common.c                |   5 +-
 arch/x86/kernel/head_32.S                   |  20 +-
 arch/x86/kernel/ldt.c                       | 137 +++++--
 arch/x86/kernel/process.c                   |   2 -
 arch/x86/kernel/process_32.c                |  10 +-
 arch/x86/mm/dump_pagetables.c               |  21 +-
 arch/x86/mm/pgtable.c                       | 105 ++++-
 arch/x86/mm/pti.c                           |  24 ++
 security/Kconfig                            |   2 +-
 25 files changed, 888 insertions(+), 283 deletions(-)

-- 
2.7.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Juergen Gross]

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

Re: [PATCH 00/31 v2] PTI support for x86_32

[Juergen Gross]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

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

[Joerg Roedel]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andrew Cooper]

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

[Andrew Cooper]

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.A  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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andy Lutomirski]

On Fri, Feb 9, 2018 at 9:25 AM, Joerg Roedel <joro@8bytes.org> 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

[Andy Lutomirski]

On Fri, Feb 9, 2018 at 9:25 AM, Joerg Roedel <joro@8bytes.org> 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."

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

Hi Andy,

On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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

[Joerg Roedel]

Hi Andy,

On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Adam Borowski]

On Fri, Feb 09, 2018 at 08:11:12PM +0100, Joerg Roedel wrote:
> On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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

[Adam Borowski]

On Fri, Feb 09, 2018 at 08:11:12PM +0100, Joerg Roedel wrote:
> On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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!
-- 
ac?aGBP'a  3/4 a >>ac?aGBP|a ? 
aGBP 3/4 a ?ac?a ?a ?aGBP?a!? Vat kind uf sufficiently advanced technology iz dis!?
ac?a!?a ?a .a ?a ?a ?                                 -- Genghis Ht'rok'din
a ?a 3aGBP?a ?a ?a ?a ? 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Linus Torvalds]

On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski <kilobyte@angband.pl> 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

[Linus Torvalds]

On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski <kilobyte@angband.pl> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Adam Borowski]

On Sat, Feb 10, 2018 at 12:22:59PM -0800, Linus Torvalds wrote:
> On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski <kilobyte@angband.pl> 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

[Adam Borowski]

On Sat, Feb 10, 2018 at 12:22:59PM -0800, Linus Torvalds wrote:
> On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski <kilobyte@angband.pl> 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!
-- 
ac?aGBP'a  3/4 a >>ac?aGBP|a ?
aGBP 3/4 a ?ac?a ?a ?aGBP?a!? Vat kind uf sufficiently advanced technology iz dis!?
ac?a!?a ?a .a ?a ?a ?                                 -- Genghis Ht'rok'din
a ?a 3aGBP?a ?a ?a ?a ?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Mark D Rustad]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

--
Mark Rustad, MRustad@gmail.com


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andy Lutomirski]

On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:

>> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andy Lutomirski]

On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:

>> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Linus Torvalds]

On Sun, Feb 11, 2018 at 11:42 AM, Andy Lutomirski <luto@amacapital.net> 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

[Linus Torvalds]

On Sun, Feb 11, 2018 at 11:42 AM, Andy Lutomirski <luto@amacapital.net> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[James Bottomley]

On Sun, 2018-02-11 at 11:42 -0800, Andy Lutomirski wrote:
> 
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> > 
> > > 
> > > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

James

Re: [PATCH 00/31 v2] PTI support for x86_32

[James Bottomley]

On Sun, 2018-02-11 at 11:42 -0800, Andy Lutomirski wrote:
> 
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> > 
> > > 
> > > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.pl>
> > > wrote:
> > > 
> > > > 
> > > > Does Debian make it easy to upgrade to a 64-bit kernel if you
> > > > have a
> > > > 32-bit install?
> > > 
> > > Quite easy, yeah.A A 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/cpuinfoA 
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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andy Lutomirski]

> On Feb 11, 2018, at 2:12 PM, James Bottomley <James.Bottomley@HansenPartnership.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 <mrustad@gmail.com> wrote:
>>> 
>>> 
>>>> 
>>>> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

> 
> James
> 

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andy Lutomirski]

> On Feb 11, 2018, at 2:12 PM, James Bottomley <James.Bottomley@HansenPartnership.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 <mrustad@gmail.com> wrote:
>>> 
>>> 
>>>> 
>>>> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

> 
> James
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[James Bottomley]

On Sun, 2018-02-11 at 14:30 -0800, Andy Lutomirski wrote:
> 
> > 
> > On Feb 11, 2018, at 2:12 PM, James Bottomley <James.Bottomley@Hanse
> > 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 <mrustad@gmail.com>
> > > > wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.
> > > > > 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

[James Bottomley]

On Sun, 2018-02-11 at 14:30 -0800, Andy Lutomirski wrote:
> 
> > 
> > On Feb 11, 2018, at 2:12 PM, James Bottomley <James.Bottomley@Hanse
> > 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 <mrustad@gmail.com>
> > > > wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.
> > > > > pl>
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Does Debian make it easy to upgrade to a 64-bit kernel if
> > > > > > you
> > > > > > have a
> > > > > > 32-bit install?
> > > > > 
> > > > > Quite easy, yeah.A A 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/cpuinfoA 
> > processorA A A A : 0
> > vendor_idA A A A : GenuineIntel
> > cpu familyA A A A : 15
> > modelA A A A A A A A : 2
> > model nameA A A A : Intel(R) Pentium(R) 4 CPU 2.80GHz
> > steppingA A A A : 9
> > microcodeA A A A : 0x2e
> > cpu MHzA A A A A A A A : 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?A A 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. A I don't doubt it's costing the
hosting provider, but they're keeping my rates low.

James

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Pavel Machek]

On Sun 2018-02-11 11:42:47, Andy Lutomirski wrote:
> 
> 
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.
> > 

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

[Pavel Machek]

On Sun 2018-02-11 11:42:47, Andy Lutomirski wrote:
> 
> 
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.
> > 

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Alan Cox]

On Sun, 11 Feb 2018 11:42:47 -0800
Andy Lutomirski <luto@amacapital.net> wrote:

> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?

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

[Alan Cox]

On Sun, 11 Feb 2018 11:42:47 -0800
Andy Lutomirski <luto@amacapital.net> wrote:

> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Anders Larsen]

On Sunday, 11 February 2018 23:25 Alan Cox wrote:
> On Sun, 11 Feb 2018 11:42:47 -0800
> 
> Andy Lutomirski <luto@amacapital.net> wrote:
> > On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?
> 
> 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)

FWIW the Atom E6xx series (Tunnel Creek) is 32bit only and still in
production; my employer is using those beasts in several devices - and I'm
fighting an uphill battle to have those products ship with a recent kernel
(for certain values of recent)

> 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)

Cheers
Anders

Re: [PATCH 00/31 v2] PTI support for x86_32

[Anders Larsen]

On Sunday, 11 February 2018 23:25 Alan Cox wrote:
> On Sun, 11 Feb 2018 11:42:47 -0800
> 
> Andy Lutomirski <luto@amacapital.net> wrote:
> > On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?
> 
> 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)

FWIW the Atom E6xx series (Tunnel Creek) is 32bit only and still in
production; my employer is using those beasts in several devices - and I'm
fighting an uphill battle to have those products ship with a recent kernel
(for certain values of recent)

> 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)

Cheers
Anders

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Sun 2018-02-11 11:42:47, Andy Lutomirski wrote:
> 
> 
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad <mrustad@gmail.com> wrote:
> 
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 00/31 v2] PTI support for x86_32

[joe.korty]

On Wed, Feb 14, 2018 at 11:43:42AM +0100, Pavel Machek wrote:
> 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.]

Or, future CPU designs introduce shadow caches and shadow
TLBs which only speculation loads and sees and which
become real only if and whend the resultant speculative
calculations become real.

Joe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Wed 2018-02-14 22:44:44, joe.korty@concurrent-rt.com wrote:
> On Wed, Feb 14, 2018 at 11:43:42AM +0100, Pavel Machek wrote:
> > 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.]
> 
> Or, future CPU designs introduce shadow caches and shadow
> TLBs which only speculation loads and sees and which
> become real only if and whend the resultant speculative
> calculations become real.

Yes, that could help.

But there's still sidechannel in the RAM: it has row buffer
or something like that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 00/31 v2] PTI support for x86_32

[Greg KH]

On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
> > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

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

[Greg KH]

On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
> > On Feb 11, 2018, at 2:59 AM, Adam Borowski <kilobyte@angband.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.

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Linus Torvalds]

On Tue, Feb 13, 2018 at 12:54 AM, Greg KH <gregkh@linuxfoundation.org> 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

[Linus Torvalds]

On Tue, Feb 13, 2018 at 12:54 AM, Greg KH <gregkh@linuxfoundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Greg KH]

On Tue, Feb 13, 2018 at 09:25:34AM -0800, Linus Torvalds wrote:
> On Tue, Feb 13, 2018 at 12:54 AM, Greg KH <gregkh@linuxfoundation.org> 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

[Greg KH]

On Tue, Feb 13, 2018 at 09:25:34AM -0800, Linus Torvalds wrote:
> On Tue, Feb 13, 2018 at 12:54 AM, Greg KH <gregkh@linuxfoundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Lorenzo Colitti]

On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

[Lorenzo Colitti]

On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Arnd Bergmann]

On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

[Arnd Bergmann]

On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Greg KH]

On Wed, Feb 21, 2018 at 05:59:34PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

[Greg KH]

On Wed, Feb 21, 2018 at 05:59:34PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 21, 2018 at 11:26 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:10 PM, Greg KH <gregkh@linuxfoundation.org> 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 <lorenzo@google.com> wrote:
>> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:10 PM, Greg KH <gregkh@linuxfoundation.org> 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 <lorenzo@google.com> wrote:
>> > On Wed, Feb 14, 2018 at 5:54 PM, Greg KH <gregkh@linuxfoundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Jason A. Donenfeld]

Hi Linus,

On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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

[Jason A. Donenfeld]

Hi Linus,

On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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

[Jason A. Donenfeld]

Hi Linus,

On Tue, Feb 13, 2018 at 6:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Ingo Molnar]

* Joerg Roedel <jroedel@suse.de> wrote:

> Hi Andy,
> 
> On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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

[Ingo Molnar]

* Joerg Roedel <jroedel@suse.de> wrote:

> Hi Andy,
> 
> On Fri, Feb 09, 2018 at 05:47:43PM +0000, 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Joerg Roedel]

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

[Joerg Roedel]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote:
> On Fri, Feb 9, 2018 at 9:25 AM, Joerg Roedel <joro@8bytes.org> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 00/31 v2] PTI support for x86_32

[Linus Torvalds]

On Fri, Feb 9, 2018 at 1:09 PM, Pavel Machek <pavel@ucw.cz> 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

[Linus Torvalds]

On Fri, Feb 9, 2018 at 1:09 PM, Pavel Machek <pavel@ucw.cz> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 00/31 v2] PTI support for x86_32

[Andrew Cooper]

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

[Andrew Cooper]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>