Re: [RFC PATCH 2/7] arm64: kernel: Add a WFI hook.

2021-01-21 Thread Hector Martin 'marcan'
driver (which can come later) just do: - switch to powerdown mode - save state - wfi - restore state - switch to clockgate mode -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-10 Thread Hector Martin
control requests even to devices bound to drivers). Even if it is necessary to unbind it, though, libusb already provides a single function to do that (libusb_detach_kernel_driver). -- Hector Martin (hec...@marcansoft.com) Public Key: https://mrcn.st/pub

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-10 Thread Hector Martin
a device manager, just poll for the VID 0 device too and apply the fix. I can't think of a scenario where this would be difficult to fix in userspace... -- Hector Martin (hec...@marcansoft.com) Public Key: https://mrcn.st/pub

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-10 Thread Hector Martin
uses this particular function. Pretty sure other drivers are littered with stuff like this too, hardware manufacturers love to reinvent checksums. -- Hector Martin (hec...@marcansoft.com) Public Key: https://mrcn.st/pub

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-09 Thread Hector Martin "marcan"
On September 10, 2020 12:46:20 PM GMT+09:00, James Hilliard wrote: >On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan" > wrote: >> >> >> >> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum > wrote: >> >Am Mittwoch

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-09 Thread Hector Martin "marcan"
_probe(struct >usb_serial_port *port) >> ftdi_set_max_packet_size(port); >> if (read_latency_timer(port) < 0) >> priv->latency = 16; >> + vendor_id = >le16_to_cpu(port->serial->dev->descriptor.idVendor); >> + product_id =

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

2020-09-09 Thread Hector Martin "marcan"
priv->latency = orig_latency; >> +if (rv < 0) >> +return -EIO; >> +} > >Do you really want to change this without returning to the original? > > Regards > Oliver -- Hector Martin "marcan" (hec...@marcansoft.com) Public key: https://mrcn.st/pub

Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

2018-01-10 Thread Hector Martin 'marcan'
have made it into any trees or percolated up to mainline yet. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

2018-01-10 Thread Hector Martin 'marcan'
have made it into any trees or percolated up to mainline yet. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [PATCH] [v2] x86/doc: add PTI description

2018-01-04 Thread Hector Martin 'marcan'
setting the NX bit in the top level. This ensures > +that if a kernel->user CR3 switch is missed that userspace will > +crash immediately upon executing its first instruction. "that userspace" -> "then userspace" -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [PATCH] [v2] x86/doc: add PTI description

2018-01-04 Thread Hector Martin 'marcan'
setting the NX bit in the top level. This ensures > +that if a kernel->user CR3 switch is missed that userspace will > +crash immediately upon executing its first instruction. "that userspace" -> "then userspace" -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: Bricked x86 CPU with software?

2018-01-04 Thread Hector Martin 'marcan'
fuse, or causing actual hardware damage, since CPUs have no nonvolatile memory other than fuses. Either way this would be a very interesting result. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: Bricked x86 CPU with software?

2018-01-04 Thread Hector Martin 'marcan'
fuse, or causing actual hardware damage, since CPUs have no nonvolatile memory other than fuses. Either way this would be a very interesting result. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-11 Thread Hector Martin 'marcan'
he only thing you have to worry about; more options to limit stack frame size, and perhaps code changes to inline everything, might be appropriate. [1] https://bugs.gentoo.org/637152 -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-11 Thread Hector Martin 'marcan'
he only thing you have to worry about; more options to limit stack frame size, and perhaps code changes to inline everything, might be appropriate. [1] https://bugs.gentoo.org/637152 -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
On 2017-11-11 07:04, Andy Lutomirski wrote: >> On Nov 10, 2017, at 8:36 AM, Hector Martin 'marcan' <mar...@marcan.st> wrote: >> >>> On 2017-11-11 01:02, Hector Martin 'marcan' wrote: >>> Not entirely sure what's going on here. >> >> Actually, if you

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
On 2017-11-11 07:04, Andy Lutomirski wrote: >> On Nov 10, 2017, at 8:36 AM, Hector Martin 'marcan' wrote: >> >>> On 2017-11-11 01:02, Hector Martin 'marcan' wrote: >>> Not entirely sure what's going on here. >> >> Actually, if you think about it, it does

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
On 2017-11-11 01:02, Hector Martin 'marcan' wrote: > Not entirely sure what's going on here. Actually, if you think about it, it doesn't matter that it skips the first page, since it's probing one page more. That just means the caller will have probed the previous page. So ultimately you're j

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
On 2017-11-11 01:02, Hector Martin 'marcan' wrote: > Not entirely sure what's going on here. Actually, if you think about it, it doesn't matter that it skips the first page, since it's probing one page more. That just means the caller will have probed the previous page. So ultimately you're j

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
configuration like this. Well, the original point still stands. Even if what GCC is doing is stupid here, it's not illegal (it's just eating stack space), and the kernel still currently makes no guarantees about that. So I think the conversation regarding vDSO stack usage guarantees is still wo

Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
configuration like this. Well, the original point still stands. Even if what GCC is doing is stupid here, it's not illegal (it's just eating stack space), and the kernel still currently makes no guarantees about that. So I think the conversation regarding vDSO stack usage guarantees is still wo

vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
the stack probes? [1] https://github.com/golang/go/issues/20427#issuecomment-343255844 [2] https://marcan.st/paste/HCVuLG6T.txt -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

vDSO maximum stack usage, stack probes, and -fstack-check

2017-11-10 Thread Hector Martin 'marcan'
the stack probes? [1] https://github.com/golang/go/issues/20427#issuecomment-343255844 [2] https://marcan.st/paste/HCVuLG6T.txt -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub

[PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

2017-11-03 Thread Hector Martin
to do unconditionally for controllers in case others have the same behavior. Signed-off-by: Hector Martin <mar...@marcan.st> --- drivers/firewire/ohci.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 8bf892

[PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

2017-11-03 Thread Hector Martin
to do unconditionally for controllers in case others have the same behavior. Signed-off-by: Hector Martin --- drivers/firewire/ohci.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 8bf89267dc25..d731b413cb2c 100644

[PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

2017-08-01 Thread Hector Martin
Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin <mar...@marcan.st> --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 5894e3c9468f..ff6f39fe6c00 100644 --- a/drivers/net/usb/qmi_wwan.c

[PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

2017-08-01 Thread Hector Martin
Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 5894e3c9468f..ff6f39fe6c00 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb

[PATCH 1/2] usb: option: add D-Link DWM-222 device ID

2017-08-01 Thread Hector Martin
Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin <mar...@marcan.st> --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index ebe51f11105d..fe123153b1a5 100644 --- a/drivers/usb/serial/op

[PATCH 1/2] usb: option: add D-Link DWM-222 device ID

2017-08-01 Thread Hector Martin
Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index ebe51f11105d..fe123153b1a5 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-30 Thread Hector Martin "marcan"
On 2016-05-31 00:40, Kees Cook wrote: > On Sun, May 29, 2016 at 8:46 PM, Hector Martin "marcan" > <mar...@marcan.st> wrote: >> On 2016-05-30 11:16, Kees Cook wrote: >>> On Sun, May 29, 2016 at 10:59 AM, Hector Martin <mar...@marcan.st> wrote: >&g

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-30 Thread Hector Martin "marcan"
On 2016-05-31 00:40, Kees Cook wrote: > On Sun, May 29, 2016 at 8:46 PM, Hector Martin "marcan" > wrote: >> On 2016-05-30 11:16, Kees Cook wrote: >>> On Sun, May 29, 2016 at 10:59 AM, Hector Martin wrote: >>>> On Mon, May 23, 2016 at 3:15 PM, Emese

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-29 Thread Hector Martin "marcan"
On 2016-05-30 11:16, Kees Cook wrote: > On Sun, May 29, 2016 at 10:59 AM, Hector Martin <mar...@marcan.st> wrote: >> On Mon, May 23, 2016 at 3:15 PM, Emese Revfy <re.em...@gmail.com> wrote: >>> +/* >>> + * Copyright 2012-2016 by the PaX Team <pagee...@fr

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-29 Thread Hector Martin "marcan"
On 2016-05-30 11:16, Kees Cook wrote: > On Sun, May 29, 2016 at 10:59 AM, Hector Martin wrote: >> On Mon, May 23, 2016 at 3:15 PM, Emese Revfy wrote: >>> +/* >>> + * Copyright 2012-2016 by the PaX Team >>> + * Copyright 2016 by Emese Revfy >>> + * L

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-29 Thread Hector Martin
r not. (Also, don't some arches link against libgcc, further complicating this? Trying to use this compiler plugin with those arches would wind up with non-redistributable kernels, this time due to the exception.) -- Hector Martin (mar...@marcan.st) Public Key: https://marcan.st/marcan.asc

Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

2016-05-29 Thread Hector Martin
to use this compiler plugin with those arches would wind up with non-redistributable kernels, this time due to the exception.) -- Hector Martin (mar...@marcan.st) Public Key: https://marcan.st/marcan.asc

Re: [PATCH] usb: serial: Perform verification for FTDI FT232R devices

2014-10-23 Thread Hector Martin
On 23/10/14 23:14, Russ Dill wrote: > On Thu, Oct 23, 2014 at 5:44 AM, Hector Martin wrote: >> + write_eeprom(port, 0, eeprom_data[0]); >> + write_eeprom(port, 1, 0); >> + write_eeprom(port, eeprom_size - 2, eeprom_data[eeprom_size - 2]); >>

Re: [PATCH] usb: serial: Perform verification for FTDI FT232R devices

2014-10-23 Thread Hector Martin
eeprom_data[eeprom_size - 2]); + write_eeprom(port, eeprom_size - 1, checksum); This will correctly set the Vendor ID to zero on all devices, counterfeit or not. -- Hector Martin (hec...@marcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc -- To unsubscribe from this list: send

Re: [PATCH] usb: serial: Perform verification for FTDI FT232R devices

2014-10-23 Thread Hector Martin
]); + write_eeprom(port, eeprom_size - 1, checksum); This will correctly set the Vendor ID to zero on all devices, counterfeit or not. -- Hector Martin (hec...@marcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH] usb: serial: Perform verification for FTDI FT232R devices

2014-10-23 Thread Hector Martin
On 23/10/14 23:14, Russ Dill wrote: On Thu, Oct 23, 2014 at 5:44 AM, Hector Martin hec...@marcansoft.com wrote: + write_eeprom(port, 0, eeprom_data[0]); + write_eeprom(port, 1, 0); + write_eeprom(port, eeprom_size - 2, eeprom_data[eeprom_size - 2]); + write_eeprom(port

Re: Coding FATX support for 2.6

2007-09-23 Thread Hector Martin
Diego Calleja wrote: > FUSE could be an acceptable solution. Not really. Booting Xbox-Linux from an image file on a FATX partition is common. I don't think FUSE would work very well there. -- Hector Martin ([EMAIL PROTECTED]) Public Key: http://www.marcansoft.com/marcan.asc - To unsubscr

Coding FATX support for 2.6

2007-09-23 Thread Hector Martin
want to cause a regression. However, much of the code (allocation strategies, FAT handling, etc) should be the same or very similar, so it seems stupid to start from scratch. Comments? -- Hector Martin ([EMAIL PROTECTED]) Public Key: http://www.marcansoft.com/marcan.asc - To unsubscribe from

Coding FATX support for 2.6

2007-09-23 Thread Hector Martin
want to cause a regression. However, much of the code (allocation strategies, FAT handling, etc) should be the same or very similar, so it seems stupid to start from scratch. Comments? -- Hector Martin ([EMAIL PROTECTED]) Public Key: http://www.marcansoft.com/marcan.asc - To unsubscribe from

Re: Coding FATX support for 2.6

2007-09-23 Thread Hector Martin
Diego Calleja wrote: FUSE could be an acceptable solution. Not really. Booting Xbox-Linux from an image file on a FATX partition is common. I don't think FUSE would work very well there. -- Hector Martin ([EMAIL PROTECTED]) Public Key: http://www.marcansoft.com/marcan.asc - To unsubscribe

<    1   2   3