[REGRESSION]: x86/idt: Move early IDT setup out of 32-bit asm
Thomas, I bisected a bug to commit 87e81786b13b267c4355e0d23e33c7e4c08fa63f. On first generation i486 processors it immediately resets the system after the "Booting the kernel" message. - Matthew Whitehead
Re: [REGRESSION]: x86/idt: Move early IDT setup out of 32-bit asm
Thomas On Mon, Oct 16, 2017 at 6:25 AM, Thomas Gleixner wrote: > Matthew, > > On Sat, 14 Oct 2017, tedheadster wrote: > >> I bisected a bug to commit 87e81786b13b267c4355e0d23e33c7e4c08fa63f. >> On first generation i486 processors it immediately resets the system >> after the "Booting the kernel" message. > > Duh. Took me a while to understand whats going on. The patch below should > fix that issue. > > Thanks, > > tglx > I just tested the patch and it worked nicely. - Matthew Whitehead
Disk UUID failing query in 4.14-rc5
There has been some change between the 4.13 and 4.14-rc5 kernel. I am using the same userspace with those two kernels. 4.13 successfully reports the UUID using 'blkid /dev/sdX' for all cases. However, when I switch to the 4.14-rc5 kernel, I can successfully query /dev/sda1 for the UUID. However, /dev/sda2 returns an error code of 2. Very strange that it works for one and not the other. I have ext3 filesystems using e2fsprogs-1.43.3 and util-linux-2.28.2. - Matthew Whitehead
Re: [PATCH] x86: kvm: Restrict X86_FEATURE_VMMCALL to x86_64 platform
> > This shouldn't be necessary; for systems that don't have virtualization > extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe. > > But it is also wrong, because you can run a 32-bit kernel as a guest on > a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because > the processor has the vmmcall instruction and not Intel's vmcall. > Paolo, I'm running this on a bare metal machine (no virtualization) with a 32-bit AMD i486 class cpu. Should the feature be showing up in /proc/cpuinfo under the 'flags' line? It does on my machine, and it looked wrong to me. - Matthew
Re: Can we drop upstream Linux x32 support?
I will also complain. I use the 32 bit x86 environment regularly for
testing. I have found several bugs and worked with upstream developers
to create fixes.
The developers never said anything like "this is a waste of time
because it was found on 32 bit". Instead, they were universally
supportive.
As an example, Thomas Gleixner said that the problem we found would
only show up on older hardware, and he affirmed that it was a bug that
certainly needed to be fixed ("NOHZ: Check for nohz active instead of
nohz enabled").
I actually think this is an _opportunity_ to engage aspiring kernel
programmers. Give them some guidance and have them actively test and
do simple maintenance of 32 bit x86. Yes, I am prepared to take the
lead on this if it is something you want to pursue.
- Matthew Whitehead
sar reporting zero cpu usage for everything
Thomas and Steven, I am running the 4.16 kernel and I found some odd behavior in sar. It shows zero usage time in ALL categories. 12:12:36CPU %user %nice %system %iowait%steal %idle 12:34:10all 0.00 0.00 0.00 0.00 0.00 0.00 12:58:04all 0.00 0.00 0.00 0.00 0.00 0.00 13:06:01all 0.00 0.00 0.00 0.00 0.00 0.00 This is run every two minutes via cron with '/usr/lib/sa/sa1 30 4 -S DISK'. You both helped me before with a similar problem, so I thought I would ask you first for a place to start debugging this. (apologies, had to be re-sent in text-only mode) - Matthew Whitehead
Re: Old platforms: bring out your dead
Arnd, > * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are > indications that 486 have no users either on recent kernels. > There is still the Vortex86 family of SoCs, and the oldest of those were > 486SX-class, but all the modern ones are 586-class. I actively use the i486DX systems for regression testing and they have proven useful for detecting bugs in both the kernel and GCC (see below). I am also about to use them as testing systems for kernel programming students. I would hate to lose this platform as a student learning opportunity. Here are just some of the patches that I have worked on myself: Kernel patches i486 testing uncovered: x86/boot: Fix another __read_cr4() case on 486 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=192d1dccbfc5b901b66527df9df80304693cf06e x86/CPU: Change query logic so CPUID is enabled before testing https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2893cc8ff892fa74972d8dc0e1d0dc65116daaa3 GCC patches i486 contributed to: ibgcc calls __get_cpuid with 0 level breaks on early 486 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a6c78ea30381cc28ea0b2cf8f0bd584a91dda948 ICE in gen_lowpart_general, at rtlhooks.c:63 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=980c8afc0961da4b4567a5abe85b6048d501a1ad So, these systems are _quietly_ being used, and helping to contribute, it's just not glamorous, eye-catching work. - Matthew Whitehead
Re: [PATCH 3/3] x86: drop support for 1995 era EISA based platforms
I too have old EISA systems that I am using with current kernels. They're good for testing, having uncovered a kernel bug previously with Thomas Gleixner: https://lkml.org/lkml/2013/11/13/424 - Matthew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[4.17 Regression]: x86/dma: Use DMA-direct
Christoph, in the 4.17 cycle you submitted the patch "x86/dma: Use DMA-direct". This causes the VGA video on my laptop to stop working, but the system continues to be up and functioning. Video works until about 3/4 the way through boot, when I think it is loading a video driver, and then video hangs. I could ssh to it and the keyboard would respond to alt-sysrq commands. Strangely, it started working again in the 4.20 cycle with the addition of Fenghua's patch "x86/cpufeatures: Enumerate MOVDIRI instruction". This is odd to me because it looks like a very simple patch. I only have CONFIG_VGA_CONSOLE, CONFIG_FRAMEBUFFER_CONSOLE and CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY enabled, with no hardware-specific framebuffer config option set. lspci -nn of my VGA adapter gives the following: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) Your thoughts? How can I help debug this? Reported-by: Matthew Whitehead
[PATCH 3.16] x86/eisa: Add missing include
Ben, please backport Thomas Gleixner's patch to the 3.16 series.
commit ef1d4deab953ecb1dfcf9f167043bda8b3f14a11
Author: Thomas Gleixner
Date: Thu Aug 31 20:08:16 2017 +0200
x86/eisa: Add missing include
The seperation of the EISA init missed to include linux/io.h which breaks
the build with some special configurations.
Reported-by: Ingo Molnar
Fixes: f7eaf6e00fd5 ("x86/boot: Move EISA setup to a separate file")
Signed-off-by: Thomas Gleixner
diff --git a/arch/x86/kernel/eisa.c b/arch/x86/kernel/eisa.c
index 881f9236ebff..f260e452e4f8 100644
--- a/arch/x86/kernel/eisa.c
+++ b/arch/x86/kernel/eisa.c
@@ -5,6 +5,7 @@
*/
#include
#include
+#include
static __init int eisa_bus_probe(void)
{
[REGRESSION 3.16.61] x86/vdso: Fix asm constraints on vDSO syscall fallbacks
I bisected a bug than manifests itself on 32-bit i386 architectures to commit 4f9007359bcd28bc83c63cb9af38d8b2c8c1670d for long term kernel 3.16.61. It appears as one of two cases, varying by cpu architecture. All of them fail with an error message variation of "systemd[1]: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' ". The difference is whether it freezes systemd or causes a kernel panic. I do not see this problem with the upstream kernel, so 3.16 probably needs a missing upstream patch. Below are two representative failure messages. # AMD K5 [3.063769] systemd[1]: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at ../systemd-238/src/basic/time-util.c:69, function now(). Aborting. [3.083821] systemd[1]: Caught , core dump failed (child 40, code=killed, status=6/ABRT). [3.086399] systemd[1]: Freezing execution. # Pentium Pro Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at ../systemd-238/src/basic/time-util.c:69, function now(). Aborting. [ 29.573184] traps: systemd[1] general protection ip:b7153bb7 sp:bfb43d40 error:0 in libc-2.25.so[b7123000+1bc000] [ 29.590392] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 29.590392] [ 29.592863] CPU: 1 PID: 1 Comm: systemd Not tainted 3.16.61.bisect-14.pentiumpro-server #221 [ 29.592863] 0086 f683be28 c1310eb1 f682c860 f682c860 f683be40 c130fa0d [ 29.592863] f682c860 f682c860 f682c860 c14eafd0 f683be88 c1026058 c144b48d 000b [ 29.592863] f682cc1e f683be60 c102e537 f682cc1c 0001 f682c860 c102e896 f682cbc8 [ 29.592863] Call Trace: [ 29.592863] [] dump_stack+0x47/0x5b [ 29.592863] [] panic+0x81/0x190 [ 29.592863] [] do_exit+0x3b2/0x72a [ 29.592863] [] ? __sigqueue_free+0x32/0x35 [ 29.592863] [] ? recalc_sigpending_tsk+0xa/0x61 [ 29.592863] [] do_group_exit+0x37/0x84 [ 29.592863] [] get_signal_to_deliver+0x48c/0x4c6 [ 29.592863] [] do_signal+0x35/0x57d [ 29.592863] [] ? slob_alloc.isra.11+0xb6/0x178 [ 29.592863] [] ? try_to_wake_up+0x194/0x19e [ 29.592863] [] ? __send_signal.constprop.26+0x24c/0x256 [ 29.592863] [] ? force_sig_info+0x96/0xa0 [ 29.592863] [] ? do_alignment_check+0x1a/0x1a [ 29.592863] [] do_notify_resume+0x15/0x3f [ 29.592863] [] work_notifysig+0x1a/0x21 [ 29.592863] [] ? do_alignment_check+0x1a/0x1a [ 29.592863] Kernel Offset: 0x0 from 0xc100 (relocation range: 0xc000-0xf7ffdfff) [ 29.592863] Rebooting in 45 seconds.. - Matthew
RE: x86: Fix AMD K6 indirect call check v2
Andi, I have a K6 regression testing system. I think my K6 is a revision C, but I probably can get an earlier cpu (with the bug) to test on. Do you have any specific tests you would want me to do on the affected cpu? - Matthew Whitehead
PCI: Regression in remove NULL device handling from PCI DMA API
Christoph, I bisected the following kernel panic to the patch "PCI: Remove NULL device handling from PCI DMA API". It seems we still need NULL checking for some older drivers, in my case the 3c59x driver for PCI/EISA cards. I am pretty sure the panic arises in the driver here (drivers/net/ethernet/3com/3c59x.c: vortex_probe1() ): /* Makes sure rings are at least 16 byte aligned. */ vp->rx_ring = pci_alloc_consistent(pdev, sizeof(struct boom_rx_desc) * RX_RING_SIZE + sizeof(struct boom_tx_desc) * TX_RING_SIZE, &vp->rx_ring_dma); Here is the panic backtrace: eisa 00:08: EISA: slot 8: TCM5970 detected 3c59x: Donald Becker and others. 00:08: 3Com EISA 3c597 EISA Fast Demon/Vortex at 4d2ccbd3. BUG: unable to handle kernel NULL pointer dereference at 00e8 IP: get_dma_ops+0x7/0x18 *pde = Oops: [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc4.i486-netinstall-14+ #47 EIP: get_dma_ops+0x7/0x18 EFLAGS: 00010202 CPU: 0 EAX: 0064 EBX: c01844a0 ECX: EDX: 0020 ESI: c0182708 EDI: EBP: c0015cc8 ESP: c0015cc8 DS: 007b ES: 007b FS: GS: SS: 0068 CR0: 80050033 CR2: 00e8 CR3: 01348000 CR4: Call Trace: vortex_probe1+0x31b/0xc6f ? node_tag_clear+0x2f/0x71 ? radix_tree_iter_tag_clear+0x14/0x1a ? idr_alloc_cmn+0x77/0x8d ? slob_page_alloc+0x12b/0x172 ? __kmalloc+0x2e/0x56 ? __request_region+0x82/0xdf ? do_task_dead+0x21/0x21 vortex_eisa_probe+0x6a/0xa1 driver_probe_device+0x18c/0x316 __device_attach_driver+0xa7/0xb6 bus_for_each_drv+0x57/0x63 __device_attach+0x68/0xbb ? driver_allows_async_probing+0xc/0xc device_initial_probe+0xd/0xf bus_probe_device+0x1f/0x5f device_add+0x387/0x442 device_register+0x12/0x15 eisa_register_device+0x12/0x7c eisa_root_register+0x1e8/0x25c ? eisa_root_register+0x25c/0x25c virtual_eisa_root_init+0x2f/0x42 do_one_initcall+0x7c/0x106 ? parse_args+0x1ac/0x2a0 ? kernel_init_freeable+0xba/0x156 kernel_init_freeable+0xda/0x156 ? rest_init+0x70/0x70 kernel_init+0x8/0xc6 ret_from_fork+0x19/0x30 Code: 04 74 17 68 8b b7 2c c1 68 b8 a4 2b c1 68 b8 52 30 c1 e8 a4 4f fa ff 83 c4 0c 89 d8 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 85 c0 74 0a <8b> 80 84 00 00 00 85 c0 75 05 a1 a8 69 2e c1 5d c3 55 89 e5 53 EIP: get_dma_ops+0x7/0x18 SS:ESP: 0068:c0015cc8 CR2: 00e8 ---[ end trace 8d36496943468a6f ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 Kernel Offset: disabled - Matthew Whitehead
Re: PCI: Regression in remove NULL device handling from PCI DMA API
Christoph, that patch fixed the panic. Thank you for the fix. Please submit them to the netdev mailing list. - Matthew
Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")
On Sat, Apr 8, 2017 at 6:23 AM, Francois Romieu wrote: > David Miller : > [...] >> One theory is that the interrupt masking isn't working properly >> and interrupts are still arriving and hitting the NAPI state even >> when we are actively polling NAPI. >> >> And this problem was masked by the locking done here. > > Yes. > > Ville, can you rule out irq sharing between the 8139 and some other > device ? It's a candidate for unexpected interrupt handler invocation > with older pc, even with properly working hardware. > Eric, If napi_complete_done() calls could affect drivers on older hardware, I can test the following: drivers/net/ethernet/3com/typhoon.c drivers/net/ethernet/amd/pcnet32.c drivers/net/ethernet/broadcom/tg3.c drivers/net/ethernet/dec/tulip/interrupt.c drivers/net/ethernet/intel/e100.c drivers/net/ethernet/intel/e1000/e1000_main.c drivers/net/ethernet/smsc/epic100.c drivers/net/ethernet/via/via-rhine.c - Matthew
Re: What was last kernel that booted on hardware XY? database was Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2A
> > BTW... I'd really like to have a database of machine, kernel version, > cpuinfo, config... So that questions like "what is the latest kernel > that is known to be running on this hardware" and "what config should > I start from". > > For example, I have nokia N810 here. It was supported by Linux at some > point, but then we moved to dts, and stuff changed, and I can no > longer figure how to boot it. > > I guess "what was last kernel that worked on Cyrix MII" is also > relevant question. > > Is there such database? If not, would people be interested in > contributing if I create one? > I am interested and will help. I have i486/i586/Pentium Pro/Pentium II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet have Pentium III systems. I think an associated goal would be to fix those broken versions. I think this is a great project for college students to get experience with. Who else is interested? - Matthew Whitehead
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Thu, Feb 8, 2018 at 12:02 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 08 February 2018 15:23 > ... >> The Winchip is what eventually turned into the VIA Nano, which does >> have speculative execution, but I don't think the earlier C3 and C7 did, >> they are much closer to the original Winchip design. > > We had terrible trouble getting (IIRC) the C7 to execute functions > that were called in 16bit mode and returned in 32bit mode and v.v. > (for boot code bios calls). > The problems seemed to imply that it was caching return addresses > and the translation (to uops) of the instructions that followed. > So it would effectively decode the first few bytes in the wrong mode. > So there might be scope for one of these attacks. > > OTOH these devices were so slow that I doubt any are used for anything > serious - and certainly won't get a kernel update even if they are. > > Also worth nothing that the difference between the cpu and memory > speeds is much lower - so far fewer instructions could be speculatively > executed while waiting a cache miss. > > Tempting to disable everything. > > David You might think this absolutely crazy, but I would be willing to test such systems if I can get my hands on the needed hardware that I lack. I am already doing sanity testing on Intel i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the clone cpus (Cyrix, etc). While few people are using the 32bit kernel, I don't think we want to kill it completely just yet. - Matthew
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Thu, Feb 8, 2018 at 12:02 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 08 February 2018 15:23 > ... >> The Winchip is what eventually turned into the VIA Nano, which does >> have speculative execution, but I don't think the earlier C3 and C7 did, >> they are much closer to the original Winchip design. > > We had terrible trouble getting (IIRC) the C7 to execute functions > that were called in 16bit mode and returned in 32bit mode and v.v. > (for boot code bios calls). > The problems seemed to imply that it was caching return addresses > and the translation (to uops) of the instructions that followed. > So it would effectively decode the first few bytes in the wrong mode. > So there might be scope for one of these attacks. > > OTOH these devices were so slow that I doubt any are used for anything > serious - and certainly won't get a kernel update even if they are. > > Also worth nothing that the difference between the cpu and memory > speeds is much lower - so far fewer instructions could be speculatively > executed while waiting a cache miss. > > Tempting to disable everything. > > David You might think this absolutely crazy, but I would be willing to test such systems if I can get my hands on the needed hardware that I lack. I am already doing sanity testing on Intel i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the clone cpus (Cyrix, etc). While few people are using the 32bit kernel, I don't think we want to kill it completely just yet. - Matthew
[BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
I just tested the 4.15 kernel and it is reporting that my old i486 (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, Spectre V1, and Spectre V2. I find this to be _unlikely_. /sys/devices/system/cpu/vulnerabilities/* reports the following: meltdown: "Vulnerable" spectre_v1: "Vulnerable" spectre_v2: "Vulnerable: Minimal generic ASM retpoline" The output of dmesg includes: "Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline" "Spectre V2 mitigation: Filling RSB on context switch" Also, /proc/cpuinfo reports the following: cpuid level: -1 flags: fpu retpoline rsb_ctxsw bugs: cpu_meltdown spectre_v1 spectre_v2 I have the hardware to test on. Send me your patches. - Matthew Whitehead
Re: [PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group
Andy On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko wrote: > On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead > wrote: >> Several i586-class cpus supporting this instruction are missing from >> the X86_CMPXCHG64 config group. > > What about Intel Quark? MinuteIA core which is currently set as M586TSC. > I am unsure what you are asking here. I do not see any option for Intel Quark processor types in arch/x86/Kconfig.cpu. Are you saying there should be one? Or perhaps you are saying that Intel Quark is currently set for M586TSC and it lacks the CMPXCHG64 instruction? If so, I would change my config option from M586TSC to M586. >> Using a configuration with either M586TSC or M586MMX currently sets >> X86_MINIMUM_CPU_FAMILY=4 instead of the correct value 5. > > Are you sure about this? See above. > Yes I am sure of this, I tested it very well. A similar problem happens with an M686 configuration for a different reason. - Matthew
Re: What was last kernel that booted on hardware XY? database was Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2A
On Sat, Feb 17, 2018 at 4:16 PM, Pavel Machek wrote: > Hi! > >> > BTW... I'd really like to have a database of machine, kernel version, >> > cpuinfo, config... So that questions like "what is the latest kernel >> > that is known to be running on this hardware" and "what config should >> > I start from". >> > >> > For example, I have nokia N810 here. It was supported by Linux at some >> > point, but then we moved to dts, and stuff changed, and I can no >> > longer figure how to boot it. >> > >> > I guess "what was last kernel that worked on Cyrix MII" is also >> > relevant question. >> > >> > Is there such database? If not, would people be interested in >> > contributing if I create one? >> > >> >> I am interested and will help. I have i486/i586/Pentium Pro/Pentium >> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet >> have Pentium III systems. >> >> I think an associated goal would be to fix those broken versions. >> >> I think this is a great project for college students to get experience >> with. Who else is interested? > > Ok, I started something: > > https://github.com/pavelmachek/missy > This is a good start. Could we start to create a hierarchy of major architectures next? I propose the following: i486->Intel->i486 i486->Cyrix->Cx486 i486->AMD->Am486 i486->UMC->Green CPU i586->Intel->Pentium Classic i586->Intel->Pentium MMX i586->Intel->Atom i586->AMD->K5 i586->AMD->K6 i586->AMD->K6 II i586->AMD->K6 III i586->Cyrix->5x86 i586->Cyrix->6x86 i586->Cyrix->6x86MX i586->Cyrix->Cyrix III i686->Intel->Pentium Pro i686->Intel->Pentium II i686->Intel->Pentium III i686->Intel->Pentium 4 i686->Intel->Pentium M i686->Intel->Core 2 i686->AMD->K7 i686->AMD->K8 You would put the computer you tested it on inside one of these directories. This will need to be edited if you choose to use it. I left out items I know little about, such as Geode GX1, Geode LX, VIA C3-2, VIA C7, Transmeta Crusoe and Efficeon, Winchip-2, Winchip-C6, and certainly others. - Matthew
Re: move stack-protector availability out of Kconfig
Kees, I have a question about this patch. When I configure a kernel for ARCH=i386 it sets these Kconfig variables this way: HAVE_CC_STACKPROTECTOR=y CC_STACKPROTECTOR_AUTO=y CC_STACKPROTECTOR_NONE=n CC_STACKPROTECTOR_REGULAR=n CC_STACKPROTECTOR_STRONG=n It seems to me that at least _one_ of the last _three_ variables should be set to 'y' with the defaults that are being set, probably CC_STACKPOINTER_NONE=y. All of them being 'n' doesn't make sense to me. As a side note, these defaults set X86_32_LAZY_GS=n (depends on X86_32 [=y] && CC_STACKPROTECTOR_NONE [=n]) which causes the x86_32 kernels to hang. I'll discuss that in a different email thread, but just wanted to say how I came upon this. - Matthew Whitehead
Re: x86/stack protector: X86_32_LAZY_GS=n hangs kernel on old processors
> On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote: >> in your patch "x86: make lazy %gs optional on x86_32" were you able >> to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got >> toggled from 'y' to 'n' in my default config because of changes to the >> stack protector code. It hangs my ancient i486 test machine right >> after 'Booting the kernel'. > > I didn't have access to an i486 at the time or ever since, so it > wasn't tested there. If this is specific to i486, flagging it so in > the config probably isn't the end of the world at this point. Tejun, I will be able to test this on other 32bit hardware at the end of the week. Hopefully I'll be able to identify which processors it does not work on (i486/i586/i686). - Matthew
Re: x86/stack protector: X86_32_LAZY_GS=n hangs kernel on old processors
On Tue, Feb 13, 2018 at 4:37 PM, Kees Cook wrote: > On Tue, Feb 13, 2018 at 8:57 AM, tedheadster wrote: >> Changing X86_32_LAZY_GS to 'y' does not cause the kernel to hang. >> >>> On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote: >>>> in your patch "x86: make lazy %gs optional on x86_32" were you able >>>> to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got >>>> toggled from 'y' to 'n' in my default config because of changes to the >>>> stack protector code. It hangs my ancient i486 test machine right >>>> after 'Booting the kernel'. >>> >>> I didn't have access to an i486 at the time or ever since, so it >>> wasn't tested there. If this is specific to i486, flagging it so in >>> the config probably isn't the end of the world at this point. >> >> Tejun, >> I will be able to test this on other 32bit hardware at the end of >> the week. Hopefully I'll be able to identify which processors it does >> not work on (i486/i586/i686). > > So, this is the exact opposite of my tests: if I had X86_32_LAZY_GS=y > and stack protector enabled (via _AUTO), the boot would hang. This > change solved that for me: > > config X86_32_LAZY_GS > def_bool y > - depends on X86_32 && !CC_STACKPROTECTOR > + depends on X86_32 && CC_STACKPROTECTOR_NONE > > since stack-protector in _AUTO mode had to reorganize that logic. It > seemed LAZY_GS isn't compatible with stack-protector, so I made sure > to retain that. What are your other configs? > Kees, I am running the 4.16-rc1 release. My arch/x86/Kconfig has this logic: config X86_32_LAZY_GS def_bool y depends on X86_32 && CC_STACKPROTECTOR_NONE I get a hang on i486 when I choose any of these configuration options: CONFIG_CC_STACKPROTECTOR_AUTO=y CONFIG_CC_STACKPROTECTOR_REGULAR=y CONFIG_CC_STACKPROTECTOR_STRONG=y Also, CONFIG_X86_32_LAZY_GS does not appear in any of these config files, not even as "# CONFIG_X86_32_LAZY_GS is not set", which I thought was strange. The only configuration that works on i486 is: CONFIG_CC_STACKPROTECTOR_NONE=y CONFIG_X86_32_LAZY_GS=y Now it gets interesting. All four of these configurations boots successfully when compiled for, and run on, a Pentium 4 M (CONFIG_PENTIUM4). So it certainly is related to what version of the processor you use. I will continue to try other configuration combinations and report back. - Matthew
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Sat, Feb 3, 2018 at 2:37 AM, David Woodhouse wrote:
> On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
>> I just tested the 4.15 kernel and it is reporting that my old i486
>> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
>> Spectre V1, and Spectre V2.
>>
>> I find this to be _unlikely_.
>
> This should be fixed in Linus' tree already by commit fec9434a1
> ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
> Meltdown").
>
> We'll make sure it ends up in the stable tree too, if it hasn't
> already.
David
I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
Pull x86/pti updates from Thomas Gleixner: "Another set of melted
spectrum related changes"
(commit 6304672b7f0a5c010002e63a075160856dc4f88d).
Unfortunately, the symptoms I reported remain on at least the i486 and i686.
- Matthew
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse wrote:
> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>> On Tue, Feb 06, 2018 at 07:10:27PM +, David Woodhouse wrote:
>> >
>> >
>> >
>> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
>> > >
>> > > .
>> > > >
>> > > >
>> > > > David
>> > > >I believe I got the patch(es) you mention in in the stable 4.15.1
>> > > > kernel:
>> > > >
>> > > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
>> > > > spectrum related changes"
>> > > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
>> > > >
>> > > > Unfortunately, the symptoms I reported remain on at least the i486 and
>> > > > i686.
>> > > Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
>> > > was a lot of spectrum patches merged just this week that were not in
>> > > 4.15.1.
>> > No, for the 486 it *should* have worked. The interesting commit
>> > is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
>> > vulnerable to Meltdown") which is indeed pulled in with the merge
>> > commit that Matthew mentions.
>> >
>> I disagree.
>>
>> $ git describe
>> v4.15.1-61-g7ab5513e4cbc
>> $ git log --oneline v4.15.1.. | grep Melt
>> 3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to
>> Meltdown
>
> Ah right, for 4.15.1 perhaps yes. I was looking at Matthew's 'commit
> 6304672b7f0a5c010002e63a075160856dc4f88d' which isn't in 4.15.1 at all;
> that's the commit in Linus' tree where he pulled in the fix. So *that*
> one should have had it.
I think Guenter is correct and I mixed up my linux versus linux-stable
git repository directories. I am recompiling now Linus' tree and will
report back my results.
Apologies for the incorrect information.
- Matthew
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Tue, Feb 6, 2018 at 2:24 PM, tedheadster wrote:
> On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse wrote:
>> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>>> On Tue, Feb 06, 2018 at 07:10:27PM +, David Woodhouse wrote:
>>> >
>>> >
>>> >
>>> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
>>> > >
>>> > > .
>>> > > >
>>> > > >
>>> > > > David
>>> > > >I believe I got the patch(es) you mention in in the stable 4.15.1
>>> > > > kernel:
>>> > > >
>>> > > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
>>> > > > spectrum related changes"
>>> > > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
>>> > > >
>>> > > > Unfortunately, the symptoms I reported remain on at least the i486
>>> > > > and i686.
>>> > > Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
>>> > > was a lot of spectrum patches merged just this week that were not in
>>> > > 4.15.1.
>>> > No, for the 486 it *should* have worked. The interesting commit
>>> > is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
>>> > vulnerable to Meltdown") which is indeed pulled in with the merge
>>> > commit that Matthew mentions.
>>> >
>>> I disagree.
>>>
>>> $ git describe
>>> v4.15.1-61-g7ab5513e4cbc
>>> $ git log --oneline v4.15.1.. | grep Melt
>>> 3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to
>>> Meltdown
>>
>> Ah right, for 4.15.1 perhaps yes. I was looking at Matthew's 'commit
>> 6304672b7f0a5c010002e63a075160856dc4f88d' which isn't in 4.15.1 at all;
>> that's the commit in Linus' tree where he pulled in the fix. So *that*
>> one should have had it.
>
Okay, I did a 'git pull' from Linus' tree and rebuilt. I _believe_ I
have the correct patches from this information:
localhost /usr/src/linux # git log | grep "Do not enable PTI on CPUs
which are not vulnerable to Meltdown"
Fixes: fec9434a12f3 ("x86/pti: Do not enable PTI on CPUs which are
not vulnerable to Meltdown")
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
localhost /usr/src/linux # git log | grep -A8
6304672b7f0a5c010002e63a075160856dc4f88d
commit 6304672b7f0a5c010002e63a075160856dc4f88d
Merge: 942633523cde 64e16720ea08
Author: Linus Torvalds
Date: Mon Jan 29 19:08:02 2018 -0800
Merge branch 'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86/pti updates from Thomas Gleixner:
"Another set of melted spectrum related changes:
If that is correct (and I might be wrong), then I am up to date and I
am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
bugs : cpu_meltdown spectre_v1 spectre_v2
- Matthew
Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2
On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse wrote:
> On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
>>
>> If that is correct (and I might be wrong), then I am up to date and I
>> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
>>
>> bugs : cpu_meltdown spectre_v1 spectre_v2
>
> That's expected for now. The CPUs we exempt are as follows:
>
> static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW,
> X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
> X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
> X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL,
> X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW,
> X86_FEATURE_ANY },
> { X86_VENDOR_CENTAUR, 5 },
> { X86_VENDOR_INTEL, 5 },
> { X86_VENDOR_NSC, 5 },
> { X86_VENDOR_ANY, 4 },
> {}
> };
>
> Alan is going to improve that list, but your Pentium 4 isn't on it yet.
>
> The bugs went away on the 486 though, right?
Okay, recompiled for the i486 and it reports no bugs.
As for the i686, it is really a "Mobile Pentium 4 HT" Prescott series
(https://ark.intel.com/products/27368/Mobile-Intel-Pentium-4-Processor-532-supporting-HT-Technology-1M-Cache-3_06-GHz-533-MHz-FSB).
Does that make it a 'speculative execution' processor?
Thank you for the help and I'll test more of the museum pieces.
- Matthew
Re: Disk UUID failing query in 4.14-rc5
On Fri, Nov 17, 2017 at 11:14 PM, Randy Dunlap wrote: > On 10/24/2017 08:14 AM, tedheadster wrote: >> There has been some change between the 4.13 and 4.14-rc5 kernel. I am >> using the same userspace with those two kernels. 4.13 successfully >> reports the UUID using 'blkid /dev/sdX' for all cases. >> >> However, when I switch to the 4.14-rc5 kernel, I can successfully >> query /dev/sda1 for the UUID. However, /dev/sda2 returns an error code >> of 2. Very strange that it works for one and not the other. >> >> I have ext3 filesystems using e2fsprogs-1.43.3 and util-linux-2.28.2. > > Hi, > Is this still a problem? > > If so, what CPU (arch/) are you using? > What type of block device(s) for /dev/sda? > > Could you do a git bisect? > > Any boot logs available? > Randy, this problem went away with the final 4.14.0 release. I did not bisect it. - Matthew
