Re: [PATCH v2 3/3] tty: Replace goldfish_tty_line_count with a #define

On Tue, 24 Jul 2018 17:51:33 -0700 r...@google.com wrote: > From: Roman Kiryanov > > The driver never mutates this variable - no benefits of > keeping it mutable. > > Signed-off-by: Roman Kiryanov > --- > Changes in v2: > - Replaced "const u32" with "#define". v1 was IMHO definitely better.

Re: [PATCH v14 20/25] x86/tsc: calibrate tsc only once

> >> If we determined tsc early in boot using one of the quick methods: > >> from cpuid/msr/quick_pit, can we assume that frequencies of all other > >> CPUs will be determined the same way? Or do we still have to fallback Not on 32bit at least. You can have a mixed slot 1 SMP system such as an

Re: [PATCH v14 20/25] x86/tsc: calibrate tsc only once

> >> If we determined tsc early in boot using one of the quick methods: > >> from cpuid/msr/quick_pit, can we assume that frequencies of all other > >> CPUs will be determined the same way? Or do we still have to fallback Not on 32bit at least. You can have a mixed slot 1 SMP system such as an

Re: [PATCH 1/3] tty/serial_core: add ISO7816 infrastructure

> > > > > + if (!port->iso7816_config) > > > + return -ENOIOCTLCMD; > > > > Why this error value? > > > > It was a mimic of RS485. Which is what you want - it means the upper tty layer knows to offer the ioctl to other places and then return appropriately. Alan

Re: [PATCH 1/3] tty/serial_core: add ISO7816 infrastructure

> > > > > + if (!port->iso7816_config) > > > + return -ENOIOCTLCMD; > > > > Why this error value? > > > > It was a mimic of RS485. Which is what you want - it means the upper tty layer knows to offer the ioctl to other places and then return appropriately. Alan

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

On Wed, 18 Jul 2018 05:01:52 +0200 Adam Borowski wrote: > Hi! > Here's a patchset with two entangled improvements: > > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) > allows disabling it, rendering such characters with a bright background > instead. That's a

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

On Wed, 18 Jul 2018 05:01:52 +0200 Adam Borowski wrote: > Hi! > Here's a patchset with two entangled improvements: > > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) > allows disabling it, rendering such characters with a bright background > instead. That's a

Re: cpu_no_speculation omissions?

no_speculation table added by commit > > > fec9434a12f3 > > > to arch/x86/kernel/cpu/common.c. Is this intentional? Would a > > > patch > > > adding it and possibly other omissions be welcome? > > > > Probably. Dave? > > IIRC, Alan Cox was

Re: cpu_no_speculation omissions?

no_speculation table added by commit > > > fec9434a12f3 > > > to arch/x86/kernel/cpu/common.c. Is this intentional? Would a > > > patch > > > adding it and possibly other omissions be welcome? > > > > Probably. Dave? > > IIRC, Alan Cox was

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

> Oops, I was just doing some testing and thought that correct behavior > for crafted FS is to return arbitrary valid error code (like -EIO) or > some arbitrary data, say, not larger than FS (not disclosing the > kernel memory, of course). Please excuse me if I was wrong. If fixing > this would

Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

> Oops, I was just doing some testing and thought that correct behavior > for crafted FS is to return arbitrary valid error code (like -EIO) or > some arbitrary data, say, not larger than FS (not disclosing the > kernel memory, of course). Please excuse me if I was wrong. If fixing > this would

Re: [PATCH 3/3] tty: support CIBAUD without BOTHER

> Ugh, I thought glibc got support for it, I guess everyone just > hand-codes it in their applications for now. Sad. The glibc people actively contributed to its design and then went radio silent on the subject. Alan

Re: [PATCH 3/3] tty: support CIBAUD without BOTHER

> Ugh, I thought glibc got support for it, I guess everyone just > hand-codes it in their applications for now. Sad. The glibc people actively contributed to its design and then went radio silent on the subject. Alan

Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex driver

> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel > framework is a generic, flexible system that supports thin kernel > drivers. Gasket kernel drivers are expected to handle opening and > closing devices, mmap'ing BAR space as requested, a small selection of > ioctls, and

Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex driver

> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel > framework is a generic, flexible system that supports thin kernel > drivers. Gasket kernel drivers are expected to handle opening and > closing devices, mmap'ing BAR space as requested, a small selection of > ioctls, and

Re: [RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

On Tue, 26 Jun 2018 11:05:21 +0200 Peter Zijlstra wrote: > On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote: > > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote: > > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote: > > > > Fir

Re: [RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

On Tue, 26 Jun 2018 11:05:21 +0200 Peter Zijlstra wrote: > On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote: > > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote: > > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote: > > > > Fir

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Fri, 22 Jun 2018 12:28:17 -0400 (EDT) Nicolas Pitre wrote: > On Fri, 22 Jun 2018, Alan Cox wrote: > > > > The other point is a quite pointless assumption that existing scrollback > > > is > > > "optimized". Even vgacon mostly uses software scroll

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Fri, 22 Jun 2018 12:28:17 -0400 (EDT) Nicolas Pitre wrote: > On Fri, 22 Jun 2018, Alan Cox wrote: > > > > The other point is a quite pointless assumption that existing scrollback > > > is > > > "optimized". Even vgacon mostly uses software scroll

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

On Wed, 20 Jun 2018 11:44:13 +0900 Linus Torvalds wrote: > On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote: > > > > Perhaps we should do an audit of the console drivers and remove all > > printk, pr_* , WARN*, BUG* from them. > > Only the actual _printing_ parts. No because they are

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

On Wed, 20 Jun 2018 11:44:13 +0900 Linus Torvalds wrote: > On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote: > > > > Perhaps we should do an audit of the console drivers and remove all > > printk, pr_* , WARN*, BUG* from them. > > Only the actual _printing_ parts. No because they are

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

> The other point is a quite pointless assumption that existing scrollback is > "optimized". Even vgacon mostly uses software scrollback these days, as the > amount of VGA display memory is really small. All of our console driver code is horribly unoptimized for most of todays hardware. Long ago

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

> The other point is a quite pointless assumption that existing scrollback is > "optimized". Even vgacon mostly uses software scrollback these days, as the > amount of VGA display memory is really small. All of our console driver code is horribly unoptimized for most of todays hardware. Long ago

Re: [RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote: > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote: > > Firmware may contain split locked instructions. > > I think that's the wrong attitude. You should mandate in your BIOS > development guide that Firmware _MUST_NOT_ contain

Re: [RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote: > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote: > > Firmware may contain split locked instructions. > > I think that's the wrong attitude. You should mandate in your BIOS > development guide that Firmware _MUST_NOT_ contain

Re: what trees/branches to test on syzbot

> But forward bisection (when bug is fixed) unfortunately won't work > because these commits are not connected to HEAD. And forward bisection > is very important, otherwise who will bring order to all these > hundreds of open bugs? > https://syzkaller.appspot.com/ Bisection isn't so important

Re: what trees/branches to test on syzbot

> But forward bisection (when bug is fixed) unfortunately won't work > because these commits are not connected to HEAD. And forward bisection > is very important, otherwise who will bring order to all these > hundreds of open bugs? > https://syzkaller.appspot.com/ Bisection isn't so important

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

> It doesn't come as a surprise that recursive printk() calls are not the > only way for us to deadlock in printk() and we still have a whole bunch > of other printk() deadlock scenarios. For instance, those that involve > TTY port->lock spin_lock and UART port->lock spin_lock. The tty layer code

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

> It doesn't come as a surprise that recursive printk() calls are not the > only way for us to deadlock in printk() and we still have a whole bunch > of other printk() deadlock scenarios. For instance, those that involve > TTY port->lock spin_lock and UART port->lock spin_lock. The tty layer code

Re: [PATCH 3/4] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.

> + } else { > + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) { > + lsr = serial_in(p, UART_LSR); > + cpu_relax(); > + } > + } This still needs a timeout in case some kind of

Re: [PATCH 3/4] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.

> + } else { > + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) { > + lsr = serial_in(p, UART_LSR); > + cpu_relax(); > + } > + } This still needs a timeout in case some kind of

Re: Spectre mitigation doesn't seem to work at all?!

> A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any >

Re: Spectre mitigation doesn't seem to work at all?!

> A malicious program most probably won't care about that. Therefore, my > next question is: which memory regions can be exploited by a malicious > program? The complete physical memory or only the memory provided to the > malicious program? Should be the latter if this approach should have any >

Re: [PATCH 0/15] x86/split_lock: Enable #AC exception for split locked accesses

> Could you describe the performance degradation? Why is this not a > "doctor it hurts when I do that" situation? They already know it hurts - the question is why and where. Alan

Re: [PATCH 0/15] x86/split_lock: Enable #AC exception for split locked accesses

> Could you describe the performance degradation? Why is this not a > "doctor it hurts when I do that" situation? They already know it hurts - the question is why and where. Alan

Re: serial: custom baud rate

On Thu, 3 May 2018 18:27:14 + (UTC) Grant Edwards wrote: > On 2018-05-03, Muni Sekhar wrote: > > > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does > > Linux serial framework has any supporting method? > > Sure,

Re: serial: custom baud rate

On Thu, 3 May 2018 18:27:14 + (UTC) Grant Edwards wrote: > On 2018-05-03, Muni Sekhar wrote: > > > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does > > Linux serial framework has any supporting method? > > Sure, use the termios2 structure instead of the termios

Re: [PATCH 2/3] media: staging: atomisp: Fix an error handling path in 'lm3554_probe()'

On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote: > > On Fri, 11 May 2018, Christophe JAILLET wrote: > > > The use of 'fail1' and 'fail2' is not correct. Reorder these calls > > to > > branch at the right place of the error handling path. > > Maybe it would be good to improve the names at

Re: [PATCH 2/3] media: staging: atomisp: Fix an error handling path in 'lm3554_probe()'

On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote: > > On Fri, 11 May 2018, Christophe JAILLET wrote: > > > The use of 'fail1' and 'fail2' is not correct. Reorder these calls > > to > > branch at the right place of the error handling path. > > Maybe it would be good to improve the names at

Re: DOS by unprivileged user

> > I think memory allocation and io waits can't be decoupled from > > scheduling as they are now. > > The scheduler is not decoupled from either, it is intimately involved > in both. However, none of the decision making smarts for either reside > in the scheduler, nor should they. It belongs

Re: DOS by unprivileged user

> > I think memory allocation and io waits can't be decoupled from > > scheduling as they are now. > > The scheduler is not decoupled from either, it is intimately involved > in both. However, none of the decision making smarts for either reside > in the scheduler, nor should they. It belongs

Re: Smatch check for Spectre stuff

> 2) Compiler transformations can elide binary operations, so we cannot >rely on source level AND (&) or MOD (%) operations to narrow the >range of an expression, regardless of the types of either operand. > >This means that source-level AND and MOD operations cannot be relied >

Re: Smatch check for Spectre stuff

> 2) Compiler transformations can elide binary operations, so we cannot >rely on source level AND (&) or MOD (%) operations to narrow the >range of an expression, regardless of the types of either operand. > >This means that source-level AND and MOD operations cannot be relied >

Re: [PATCH] tty: Fix data race in tty_insert_flip_string_fixed_flag

On Wed, 25 Apr 2018 22:20:50 +0900 DaeRyong Jeong wrote: > tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated > by th->used and updates tb->used. > But tty_insert_flip_string_fixed_flag() can be executed concurrently and > tb->used can be updated

Re: [PATCH] tty: Fix data race in tty_insert_flip_string_fixed_flag

On Wed, 25 Apr 2018 22:20:50 +0900 DaeRyong Jeong wrote: > tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated > by th->used and updates tb->used. > But tty_insert_flip_string_fixed_flag() can be executed concurrently and > tb->used can be updated improperly. The tty input

Re: Looking for way to program external MMU from userspace (or viable alternative)

> The current kernel driver code looks up the physical address of a page of > user-allocated memory by traversing the page table, and then writing the > physical address to the external MMU. If we were to move the driver to > userspace, this procedure would require exposing the physical address to

Re: Looking for way to program external MMU from userspace (or viable alternative)

> The current kernel driver code looks up the physical address of a page of > user-allocated memory by traversing the page table, and then writing the > physical address to the external MMU. If we were to move the driver to > userspace, this procedure would require exposing the physical address to

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

> But we don't have the full ACPI interpreter up in the early part of > the kernel. All these 'early' devices have their own setup/config > which is the source of the issue. Or maybe I am wrong about the full > interpreter and the early drivers are just not taking advantage of the > ACPI device

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

> But we don't have the full ACPI interpreter up in the early part of > the kernel. All these 'early' devices have their own setup/config > which is the source of the issue. Or maybe I am wrong about the full > interpreter and the early drivers are just not taking advantage of the > ACPI device

Re: uart throughput

> The primary factor affecting UART throughput is the baud rate, apart > from this any other factors affect the UART throughput? UART CPU power interrupt latency all the usual suspects. > > For 400 bps uart baud rate, what should be the theoretical peak > data throughput? > Depends

Re: uart throughput

> The primary factor affecting UART throughput is the baud rate, apart > from this any other factors affect the UART throughput? UART CPU power interrupt latency all the usual suspects. > > For 400 bps uart baud rate, what should be the theoretical peak > data throughput? > Depends

Re: [PATCH] gup: return -EFAULT on access_ok failure

> so an error on the 1st page gets propagated to the caller, > and that get_user_pages_unlocked eventually calls __get_user_pages > so it does return an error sometimes. > > Would it be correct to apply the second part of the patch then > (pasted below for reference) or should get_user_pages_fast

Re: [PATCH] gup: return -EFAULT on access_ok failure

> so an error on the 1st page gets propagated to the caller, > and that get_user_pages_unlocked eventually calls __get_user_pages > so it does return an error sometimes. > > Would it be correct to apply the second part of the patch then > (pasted below for reference) or should get_user_pages_fast

Re: [GIT PULL] Kernel lockdown for secure boot

> How? When there are random DMA-capable PCI devices that are driven by > userland tools that are mmap()ing the BARs out of sysfs, how do we > simultaneously avoid breaking those devices while also preventing the > majority of users from being vulnerable to an attacker just DMAing over the >

Re: [GIT PULL] Kernel lockdown for secure boot

> How? When there are random DMA-capable PCI devices that are driven by > userland tools that are mmap()ing the BARs out of sysfs, how do we > simultaneously avoid breaking those devices while also preventing the > majority of users from being vulnerable to an attacker just DMAing over the >

Re: [GIT PULL] Kernel lockdown for secure boot

> Furthermore, there is a fundamental deviation from common security > sense here, where things like command line parameters and other > lockdown specific tunables are blacklisted rather than whitelisted, I've been complaining about this from the start but it appears to be a write only authorship

Re: [GIT PULL] Kernel lockdown for secure boot

> Furthermore, there is a fundamental deviation from common security > sense here, where things like command line parameters and other > lockdown specific tunables are blacklisted rather than whitelisted, I've been complaining about this from the start but it appears to be a write only authorship

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, 04 Apr 2018 00:12:04 + Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds > > wrote: > > Still better than telling them to disable/enable secure boot, which > > they may or may not even be able to to. > > Users

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, 04 Apr 2018 00:12:04 + Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds > > wrote: > > Still better than telling them to disable/enable secure boot, which > > they may or may not even be able to to. > > Users who can boot a non-vendor Linux distribution on

Re: Decrease boot time with AHCI drives?

> But more importantly, it takes roughly half a second to set up the > device. I understand, that the probing is part of AHCI(?), and in this > case the Crucial m4 SSD drive/firmware is especially slow. So, I assume > it will be hard to improve anything in the code to decrease the time.

Re: Decrease boot time with AHCI drives?

> But more importantly, it takes roughly half a second to set up the > device. I understand, that the probing is part of AHCI(?), and in this > case the Crucial m4 SSD drive/firmware is especially slow. So, I assume > it will be hard to improve anything in the code to decrease the time.

Re: WARNING in tty_set_ldisc

<penguin-ker...@i-love.sakura.ne.jp> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Jiri Slaby <jsl...@suse.com> > Cc: Dmitry Vyukov <dvyu...@google.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Alan Cox <alan@llwyncelyn.cymru> > Cc: Christoph Hellwig <h...@lst.de> > Cc: Michal Hocko <mho...@suse.com> Seems reasonable to me Alan

Re: WARNING in tty_set_ldisc

; Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: Dmitry Vyukov > Cc: Johannes Weiner > Cc: Alan Cox > Cc: Christoph Hellwig > Cc: Michal Hocko Seems reasonable to me Alan

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

On Tue, 27 Mar 2018 12:05:23 -0400 Mathieu Desnoyers wrote: > Expose a new system call allowing each thread to register one userspace > memory area to be used as an ABI between kernel and user-space for two > purposes: user-space restartable sequences and quick

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

On Tue, 27 Mar 2018 12:05:23 -0400 Mathieu Desnoyers wrote: > Expose a new system call allowing each thread to register one userspace > memory area to be used as an ABI between kernel and user-space for two > purposes: user-space restartable sequences and quick access to read the > current CPU

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Mon, 26 Mar 2018 20:56:45 -0600 Aaron Durbin <adur...@chromium.org> wrote: > On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > >> Sadly, this situation > >> is not unique to this hardware. There is hardware all over that does >

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Mon, 26 Mar 2018 20:56:45 -0600 Aaron Durbin wrote: > On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote: > >> Sadly, this situation > >> is not unique to this hardware. There is hardware all over that does > >> not meet the current assumptions being made in the

Re: HELP PLEASE: Without ugly hacks, no interrupt delivery at all to our driver; 3.10.0 kernel (RHEL7.4) on Intel 82X38/X48 chipset, Shuttle (SX38/FX38, Core 2 Duo)

> I suspect a large part of the problem is that our device isn't really > a PCIe device. It's a PCI device retrofitted with a TI > XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge. Large numbers of this That really shouldn't be an issue. Just about every PC up to a few years ago has something that

Re: HELP PLEASE: Without ugly hacks, no interrupt delivery at all to our driver; 3.10.0 kernel (RHEL7.4) on Intel 82X38/X48 chipset, Shuttle (SX38/FX38, Core 2 Duo)

> I suspect a large part of the problem is that our device isn't really > a PCIe device. It's a PCI device retrofitted with a TI > XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge. Large numbers of this That really shouldn't be an issue. Just about every PC up to a few years ago has something that

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

> Sadly, this situation > is not unique to this hardware. There is hardware all over that does > not meet the current assumptions being made in the early uart drivers > within the kernel. Is there any fundamental reason you can't just embed dt entries in the ACPI table to describe the other

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

> Sadly, this situation > is not unique to this hardware. There is hardware all over that does > not meet the current assumptions being made in the early uart drivers > within the kernel. Is there any fundamental reason you can't just embed dt entries in the ACPI table to describe the other

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

> Can we probe safely for this device? 99% of the time yes the inb gives us a straight answer. However (and we've hit this with port 0x81 for real) there are concerns that some systems will trap those addresses into SMM and do weirdness that makes the 0xFF check fail. Alan

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

> Can we probe safely for this device? 99% of the time yes the inb gives us a straight answer. However (and we've hit this with port 0x81 for real) there are concerns that some systems will trap those addresses into SMM and do weirdness that makes the 0xFF check fail. Alan

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

> Please explain WHY 2017 is the cut-off date. I still have no clue how > that > is decided aside of being a random number. Because if it's prior to 2017 then it'll almost certainly have those registers even if the firmware says otherwise. After that point we think the firmware is going to give

Re: [PATCH v3] x86: i8237: Register based on FADT legacy boot flag

> Please explain WHY 2017 is the cut-off date. I still have no clue how > that > is decided aside of being a random number. Because if it's prior to 2017 then it'll almost certainly have those registers even if the firmware says otherwise. After that point we think the firmware is going to give

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, 07 Mar 2018 13:46:24 -0800 Dave Hansen wrote: > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > >We prefer to fully disclose the bug as soon as

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, 07 Mar 2018 13:46:24 -0800 Dave Hansen wrote: > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > >We prefer to fully disclose the bug as soon as possible. > > which is not really the case. Linus says: > >

Re: Removing architectures without upstream gcc support

> FWIW, alpha and m68k are known boot with qemu (even though m68k > generates a warning traceback with the mainline kernel). M68K works - people actively use it. Crazy people true 8). Alpha I believe one or two people boot. I just need to track down some discs for my Alpha 8) Alan

Re: Removing architectures without upstream gcc support

> FWIW, alpha and m68k are known boot with qemu (even though m68k > generates a warning traceback with the mainline kernel). M68K works - people actively use it. Crazy people true 8). Alpha I believe one or two people boot. I just need to track down some discs for my Alpha 8) Alan

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Wed, 21 Feb 2018 09:03:00 + > The thing I like about rate limiting (for everyone including root) is > that it does not break anybody's workflow (unless EFI variable access > occurs on a hot path, in which case you're either a) asking for it, or > b) the guy trying to DoS us), and that it

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Wed, 21 Feb 2018 09:03:00 + > The thing I like about rate limiting (for everyone including root) is > that it does not break anybody's workflow (unless EFI variable access > occurs on a hot path, in which case you're either a) asking for it, or > b) the guy trying to DoS us), and that it

Re: Removing architectures without upstream gcc support

> Regarding the older architectures I mentioned (m32r, frv, mn10300), > the situation is a bit different as they don't have the problems with > build testing but they do have problems with using less of the > standard interfaces (syscall, timer, gpio, rtc, ...), so they do add > more to the

Re: Removing architectures without upstream gcc support

> Regarding the older architectures I mentioned (m32r, frv, mn10300), > the situation is a bit different as they don't have the problems with > build testing but they do have problems with using less of the > standard interfaces (syscall, timer, gpio, rtc, ...), so they do add > more to the

Re: Reasoning about memory ordering

> Given this is the current state of the code (it's part of btrfs) I believe > the following could/should be done: Is there benchmarking data to show that a custom lock is justified (especiaally given it's going to mean btrfs and rtlinux don't play together nicely since it won't be able to see

Re: Reasoning about memory ordering

> Given this is the current state of the code (it's part of btrfs) I believe > the following could/should be done: Is there benchmarking data to show that a custom lock is justified (especiaally given it's going to mean btrfs and rtlinux don't play together nicely since it won't be able to see

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Mon, 19 Feb 2018 16:43:50 -0800 Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > > > > In theory there's nothing stopping a guest getting a 'you are about to > > gain/lose I

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Mon, 19 Feb 2018 16:43:50 -0800 Linus Torvalds wrote: > On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox wrote: > > > > In theory there's nothing stopping a guest getting a 'you are about to > > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one &g

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 20 Feb 2018 00:00:23 + "Van De Ven, Arjan" wrote: > > On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said: > > > > > the guest is not the problem; guests obviously will already honor if > > > Enhanced > > > IBRS is enumerated. The problem is

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 20 Feb 2018 00:00:23 + "Van De Ven, Arjan" wrote: > > On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said: > > > > > the guest is not the problem; guests obviously will already honor if > > > Enhanced > > > IBRS is enumerated. The problem is mixed migration pools where

Re: Read-protected UEFI variables

> If the UEFI is as secure as storing an unencrypted file on a hard > drive, I am satisfied. Or do you have a better idea where to store the > SSH keys for a diskless system that boots via network? Store them in the TPM ? If you are booting over a network and not doing some kind of TPM based

Re: Read-protected UEFI variables

> If the UEFI is as secure as storing an unencrypted file on a hard > drive, I am satisfied. Or do you have a better idea where to store the > SSH keys for a diskless system that boots via network? Store them in the TPM ? If you are booting over a network and not doing some kind of TPM based

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 13 Feb 2018 22:04:48 +0100 Pavel Machek <pa...@ucw.cz> wrote: > On Thu 2018-02-08 20:52:40, Alan Cox wrote: > > > > Also worth nothing that the difference between the cpu and memory > > > > speeds is much lower - so far fewer instructions could be spe

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 13 Feb 2018 22:04:48 +0100 Pavel Machek wrote: > On Thu 2018-02-08 20:52:40, Alan Cox wrote: > > > > Also worth nothing that the difference between the cpu and memory > > > > speeds is much lower - so far fewer instructions could be speculatively > > &

Re: [PATCH] x86/microcode/intel: Use 64-bit arithmetic instead of 32-bit

> if (c->x86_cache_size >= 0) > seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size); > > which is silly, because that really can be done with: > > if (c->x86_cache_size) > > as there is no point in printing 'cache size 0KB', which means > x86_cache_size can be

Re: [PATCH] x86/microcode/intel: Use 64-bit arithmetic instead of 32-bit

> if (c->x86_cache_size >= 0) > seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size); > > which is silly, because that really can be done with: > > if (c->x86_cache_size) > > as there is no point in printing 'cache size 0KB', which means > x86_cache_size can be

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

On Sun, 11 Feb 2018 11:42:47 -0800 Andy Lutomirski wrote: > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> > >>> Does Debian make it easy to upgrade to a 64-bit

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

On Sun, 11 Feb 2018 11:42:47 -0800 Andy Lutomirski wrote: > On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote: > > >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote: > >> > >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a > >>> 32-bit install? > >> > >> Quite

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Thu, 8 Feb 2018 16:22:40 +0100 Arnd Bergmann <a...@arndb.de> wrote: > On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium > >> MMX). I've tried a spectre

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Thu, 8 Feb 2018 16:22:40 +0100 Arnd Bergmann wrote: > On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox wrote: > >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium > >> MMX). I've tried a spectre test before and it wasn't reading anything > >>

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

> > 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. But they also have more instructions that take a lot of clocks and are easier to stall - eg by doing things

<    1   2   3   4   5   6   7   8   9   10   >