Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level

ith foreground record (starting at different >time) via I2S Master and Slave mode > - Background record with foreground playback (starting at different >time) via I2S Master and Slave mode > * All tests above by hacking offline_config to true in imx51. > > Caleb has tested v1

Re: [PATCH v3 16/17] ASoC: fsl_ssi: Move DT related code to a separate probe()

On 15.01.2018 05:21, Nicolin Chen wrote: > This patch cleans up probe() function by moving all Device Tree > related code into a separate function. It allows the probe() to > be Device Tree independent. This will be very useful for future > integration of imx-ssi driver which has similar

Re: [PATCH v3 14/17] ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()

On 15.01.2018 05:21, Nicolin Chen wrote: > The _fsl_ssi_set_dai_fmt() is a helper function being called from > fsl_ssi_set_dai_fmt() as an ASoC operation and fsl_ssi_hw_init() > mainly for AC97 format initialization. > > This patch cleans the _fsl_ssi_set_dai_fmt() in following ways: > * Removing

Re: [PATCH v2 06/16] ASoC: fsl_ssi: Clean up helper functions of trigger()

On 11.01.2018 07:43, Nicolin Chen wrote: > The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(), > and both of them jump to fsl_ssi_config(). And fsl_ssi_config() > later calls another fsl_ssi_rxtx_config(). > > However, the whole routine, especially fsl_ssi_config() function, > is too

Re: [PATCH v2 13/16] ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()

On 11.01.2018 07:43, Nicolin Chen wrote: > The _fsl_ssi_set_dai_fmt() is a helper function being called from > fsl_ssi_set_dai_fmt() as an ASoC operation and fsl_ssi_hw_init() > mainly for AC97 format initialization. > > This patch cleans the _fsl_ssi_set_dai_fmt() in following ways: > * Removing

Re: [PATCH v2 14/16] ASoC: fsl_ssi: Remove cpu_dai_drv from fsl_ssi structure

On 11.01.2018 07:43, Nicolin Chen wrote: > The cpu_dai_drv is only used for symmetric_rates. So this patch replaces > it with a synchronous boolean flag. You make cpu_dai_drv common to all SSI instances instead of per-instance. What if you have multiple SSIs in the system with different

Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level

On 17.01.2018 21:02, Nicolin Chen wrote: > On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote: > >> However, I have a small nitpick regarding a comment newly added in >> this version of patch 16: >> +/* >> + * Do not set SSI d

Re: [PATCH v2 03/16] ASoC: fsl_ssi: Maintain a mask of active streams

On 11.01.2018 07:43, Nicolin Chen wrote: > Checking TE and RE bits in SCR register doesn't work for AC97 mode > which enables SSIEN, TE and RE in the fsl_ssi_setup_ac97() that's > called during probe(). > > So when running into the trigger(), it will always get the result > of both TE and RE

Re: [PATCH v2 04/16] ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro

On 11.01.2018 07:43, Nicolin Chen wrote: > The define of fsl_ssi_disable_val is not so clear as it mixes two > steps of calculations together. And those parameter names are also > a bit long to read. > > Since it just tries to exclude the shared bits from the regvals of > current stream while the

[PATCH v2 3/5] ALSA: emu10k1: add optional debug printouts with DMA addresses

printouts are only enabled on an explicit request via the kernel dynamic debug mechanism. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: Fix a sparse warning by changing a variable type in __{get,set}_ptb_entry from u32 to __le32, don't open code EMUPA

[PATCH v2 1/5] ALSA: emu10k1: remove reserved_page

to remove the reserved_page allocation is a trivial change to the page allocation logic to ignore the first page entry and start its allocations from the second entry (index 1). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: None in this patch. include

[PATCH v2 5/5] ALSA: emu10k1: add a IOMMU workaround

it looks like the device tries to accesses up to 256 extra bytes. As a workaround let's widen these DMA allocations by an extra page if we detect that the device is behind a non-passthrough IOMMU (the DMA memory should be relatively plenty on IOMMU systems). Signed-off-by: Maciej S. Szmigiero &l

[PATCH v2 2/5] ALSA: emu10k1: use dma_set_mask_and_coherent()

We have been calling dma_set_mask() and then dma_set_coherent_mask() with the same value, but there is a dma_set_mask_and_coherent() function that does exactly that so let's use it instead. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: None in this

[PATCH v2 4/5] ALSA: emu10k1: make sure synth DMA pages are allocated with DMA functions

as the CPU physical address space which is not true for a system with a IOMMU. Since this made the synth part of the driver non-functional on such systems let's effectively revert that commit. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: None in this pa

Re: [PATCH v2 5/5] ALSA: emu10k1: add a IOMMU workaround

On 12.02.2018 13:56, Takashi Iwai wrote: > On Sat, 27 Jan 2018 15:42:59 +0100, > Maciej S. Szmigiero wrote: >> >> The Audigy 2 CA0102 chip (but most likely others from the emu10k1 family, >> too) has a problem that from time to time it likes to do few DMA reads a

Re: [PATCH v2 4/5] ALSA: emu10k1: make sure synth DMA pages are allocated with DMA functions

On 12.02.2018 13:44, Takashi Iwai wrote: > On Sat, 27 Jan 2018 15:42:47 +0100, > Maciej S. Szmigiero wrote: >> >> Commit a5003fc04113 ("[ALSA] emu10k1 - simplify page allocation for synth") >> switched from using the DMA allocator for synth DMA pages

[PATCH v3 4/5] ALSA: emu10k1: make sure synth DMA pages are allocated with DMA functions

as the CPU physical address space which is not true for a system with a IOMMU. Since this made the synth part of the driver non-functional on such systems let's effectively revert that commit (while keeping the __synth_free_pages() simplification). Signed-off-by: Maciej S. Szmigiero <m...@maciej.s

Re: [PATCH v2 5/5] ALSA: emu10k1: add a IOMMU workaround

On 13.02.2018 06:00, Takashi Iwai wrote: > On Mon, 12 Feb 2018 23:13:13 +0100, > Maciej S. Szmigiero wrote: >> >> On 12.02.2018 13:56, Takashi Iwai wrote: >>> On Sat, 27 Jan 2018 15:42:59 +0100, >>> Maciej S. Szmigiero wrote: >>>> >>&g

[PATCH v3 2/5] ALSA: emu10k1: use dma_set_mask_and_coherent()

We have been calling dma_set_mask() and then dma_set_coherent_mask() with the same value, but there is a dma_set_mask_and_coherent() function that does exactly that so let's use it instead. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1, v2: None in this

[PATCH v3 1/5] ALSA: emu10k1: remove reserved_page

to remove the reserved_page allocation is a trivial change to the page allocation logic to ignore the first page entry and start its allocations from the second entry (index 1). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1, v2: None in this patch. include

[PATCH v3 3/5] ALSA: emu10k1: add optional debug printouts with DMA addresses

printouts are only enabled on an explicit request via the kernel dynamic debug mechanism. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: Fix a sparse warning by changing a variable type in __{get,set}_ptb_entry from u32 to __le32, don't open code EMUPA

[PATCH v3 5/5] ALSA: emu10k1: add a IOMMU workaround

it looks like the device tries to accesses up to 256 extra bytes. As a workaround let's widen these DMA allocations by an extra page if we detect that the device is behind a non-passthrough IOMMU (the DMA memory should be relatively plenty on IOMMU systems). Signed-off-by: Maciej S. Szmigiero &l

RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On 18.11.2017 06:14, Kees Cook wrote: > On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: >> On 2017-11-17 04:55 PM, Linus Torvalds wrote: >>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: I am still getting the crash at

Re: [PATCH v2 0/5] Change ISA_BUS_API dependency to selection

Hi all, On 31.01.2018 03:22, William Breathitt Gray wrote: > On Tue, Jan 02, 2018 at 10:29:30AM +0100, Linus Walleij wrote: >> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray >> wrote: >> >>> Linus, please pickup this entire patchset through your GPIO subsystem

Re: [PATCH v2] kconfig.h: Include compiler types to avoid missed struct attributes

ck McLean <chutz...@gentoo.org> > Root-caused-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> > Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization") > Suggested-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by:

Re: [PATCH v2 3/5] gpio: Change ISA_BUS_API dependency to selection

Hi William, Hi Linus, On 22.02.2018 21:30, William Breathitt Gray wrote: > On Thu, Feb 22, 2018 at 04:16:17PM +0100, Linus Walleij wrote: >> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray >> wrote: >> >>> The ISA_BUS_API Kconfig option enables the compilation of

[PATCH 1/3] X.509: unpack RSA signatureValue field from BIT STRING

is a problem for RSA implementations that need it to be exactly correct (like AMD CCP). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates") Cc: sta...@vger.kernel.org --- crypto

[PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

to CCP even for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd() tried to copy this large input buffer into a RSA key length-sized hardware input buffer. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> Fixes: ceeec0afd684 ("crypto: ccp - Add supp

[PATCH 3/3] crypto: ccp - protect RSA implementation from too large input data

has been a case when this has happened let's better reject such oversized input data and log an error message in this case so we know what is going on. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/crypto/ccp/ccp-ops.c | 24 1 file chang

Re: [PATCH v2 3/5] gpio: Change ISA_BUS_API dependency to selection

On 22.02.2018 21:44, Maciej S. Szmigiero wrote: > Hi William, > Hi Linus, > > On 22.02.2018 21:30, William Breathitt Gray wrote: >> On Thu, Feb 22, 2018 at 04:16:17PM +0100, Linus Walleij wrote: >>> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray >>

[PATCH] Revert "gpio: winbond: fix ISA_BUS_API dependency"

This reverts commit 92a8046c9d952a2a7d21dfcd3afadc72a0bc0f72. Now that the patch series changing ISA_BUS_API dependency to selection was merged this reversion will do the same for gpio-winbond driver to make it consistent with other ISA bus gpio drivers. Signed-off-by: Maciej S. Szmigiero &l

Re: [PATCH v2] gpio: winbond: add driver

On 28.12.2017 05:58, William Breathitt Gray wrote: > On Wed, Dec 27, 2017 at 07:42:21PM +0100, Maciej S. Szmigiero wrote: >> On 27.12.2017 01:24, William Breathitt Gray wrote: >>> On Mon, Dec 25, 2017 at 03:48:16PM +0100, Maciej S. Szmigiero wrote: >> (..) >>>&

Re: [PATCH 0/3] Change ISA_BUS_API dependency to selection

On 28.12.2017 17:01, William Breathitt Gray wrote: (..) > > Linus, please pickup this entire patchset through your GPIO subsystem > tree; a recursive dependency error is present if these patches are > cherry-picked (see https://lkml.org/lkml/2017/12/26/235), so they should > be merged together in

Re: [PATCH v2] gpio: winbond: add driver

On 28.12.2017 16:12, Andy Shevchenko wrote: > On Fri, 2017-12-22 at 19:58 +0100, Maciej S. Szmigiero wrote: >> This commit adds GPIO driver for Winbond Super I/Os. >> >> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is >> supported but in the future

[PATCH v2] gpio: winbond: add driver

r I/O chip. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: * Added SPDX license tag, * Removed gpiobase parameter, * Changed uint{8,16}_t types to u{8,16}, * Added kerneldoc descriptions of driver structures, * Reformatted winbond_gpio_infos

Re: [PATCH v4 6/6] [media] cxusb: add analog mode support for Medion MD95700

On 19.12.2017 13:53, Mauro Carvalho Chehab wrote: > Em Sun, 17 Dec 2017 19:47:25 +0100 > "Maciej S. Szmigiero" <m...@maciej.szmigiero.name> escreveu: > >> This patch adds support for analog part of Medion 95700 in the cxusb >> driver. >> >>

[PATCH v5 4/6] tuner-simple: allow setting mono radio mode

a FMD1216ME tuner. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/tuners/tuner-simple.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/tuners/tuner-simple.c b/drivers/media/tuners/tuner-simple.c index cf44d3

[PATCH v5 0/6] [media] Add analog mode support for Medion MD95700

of a newly added "cxusb-analog.c" file, * Don't print errors on memory allocation failures, * Get rid of the driver MODULE_VERSION(), * Small formating fix of a one line. Maciej S. Szmigiero (6): ivtv: zero-initialize cx25840 platform data cx25840: add kernel-doc description of

[PATCH v5 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

time due to hardware limitations. Actual implementation of the analog mode will be provided by the next commit. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/usb/dvb-usb/cxusb.c| 452 +++ drivers/media/usb/dvb-usb/c

[PATCH v5 2/6] cx25840: add kernel-doc description of struct cx25840_state

This commit describes a device instance private data of the driver (struct cx25840_state) in a kernel-doc style comment. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/i2c/cx25840/cx25840-core.h | 33 ++-- 1 file chang

[PATCH v5 6/6] [media] cxusb: add analog mode support for Medion MD95700

/ mono), * Unplugging while capturing, * DVB / analog coexistence, * Raw BT.656 stream support. What does not work yet: * Audio, * VBI, * Picture controls. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/usb/dvb-usb/Kconfig| 16 +- drivers/media/u

[PATCH v5 3/6] cx25840: add pin to pad mapping and output format configuration

ut risking compatibility problems. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/i2c/cx25840/cx25840-core.c | 396 ++- drivers/media/i2c/cx25840/cx25840-core.h | 13 + drivers/media/i2c/cx25840/cx25840-vbi.c | 3 + includ

[PATCH v5 1/6] ivtv: zero-initialize cx25840 platform data

We need to zero-initialize cx25840 platform data structure to make sure that its future members do not contain random stack garbage. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- drivers/media/pci/ivtv/ivtv-i2c.c | 1 + 1 file changed, 1 insertion(+) diff --git a/d

Re: [PATCH] gpio: winbond: add driver

On 20.12.2017 13:06, Linus Walleij wrote: > On Tue, Dec 19, 2017 at 12:07 AM, Maciej S. Szmigiero > <m...@maciej.szmigiero.name> wrote: >> On 18.12.2017 22:22, Linus Walleij wrote: > (..) >>>> +static void winbond_gpio_warn_conflict(unsigned in

Re: [PATCH v3] gpio: winbond: add driver

On 03.01.2018 20:05, Andy Shevchenko wrote: > On Sat, 2017-12-30 at 22:02 +0100, Maciej S. Szmigiero wrote: >> This commit adds GPIO driver for Winbond Super I/Os. >> >> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is >> supported but in the future

Re: [PATCH v1 05/15] ASoC: fsl_ssi: Clean up helper functions of trigger()

On 19.12.2017 18:00, Nicolin Chen wrote: > The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(), > and both of them jump to fsl_ssi_config(). And fsl_ssi_config() > later calls another fsl_ssi_rxtx_config(). > > However, the whole routine, especially fsl_ssi_config() function, > is too

Re: [PATCH v1 03/15] ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro

On 19.12.2017 18:00, Nicolin Chen wrote: > The define of fsl_ssi_disable_val is not so clear as it mixes two > steps of calculations together. And those parameter names are also > a bit long to read. > > Since it just tries to exclude the shared bits from the regvals of > current stream while the

Re: [PATCH v1 01/15] ASoC: fsl_ssi: Clean up set_dai_tdm_slot()

On 19.12.2017 18:00, Nicolin Chen wrote: > This patch replaces the register read with ssi->i2s_net for > simplification. It also removes masking SSIEN from scr value > since it's handled later by regmap_update_bits() to set this > scr value back. > > Signed-off-by: Nicolin Chen

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On 19.12.2017 18:00, Nicolin Chen wrote: > AC97 configures some registers earlier to start a communication > with CODECs, so this patch moves those register settings to the > dai_probe() as well, along with other register configurations. > > It also applies _fsl_ssi_set_dai_fmt() to AC97 only

[PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges

esn't work correctly unless the CLKRUN protocol is disabled. Let's also make it clear in its description that the "disable_clkrun" module parameter only works on these two previously mentioned brands of CardBus bridges. Signed-off-by: Maciej S. Szmigiero --- drivers/pcmcia

[PATCH 5/5] ALSA: emu10k1: add a IOMMU workaround

to accesses up to 256 extra bytes. As a workaround let's widen these DMA allocations by an extra page if we detect that the device is behind a non-passthrough IOMMU (the DMA memory should be relatively plenty on IOMMU systems). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.n

[PATCH 1/5] ALSA: emu10k1: remove reserved_page

to remove the reserved_page allocation is a trivial change to the page allocation logic to ignore the first page entry and start its allocations from the second entry (index 1). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- include/sound/emu10k1.h | 1 - s

[PATCH 3/5] ALSA: emu10k1: add optional debug printouts with DMA addresses

printouts are only enabled on an explicit request via the kernel dynamic debug mechanism. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- sound/pci/emu10k1/emu10k1_main.c | 8 sound/pci/emu10k1/memory.c | 11 +-- 2 files changed, 17 insertions

[PATCH 4/5] ALSA: emu10k1: make sure synth DMA pages are allocated with DMA functions

as the CPU physical address space which is not true for a system with a IOMMU. Since this made the synth part of the driver non-functional on such systems let's effectively revert that commit. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- sound/pci/emu10

[PATCH 2/5] ALSA: emu10k1: use dma_set_mask_and_coherent()

We have been calling dma_set_mask() and then dma_set_coherent_mask() with the same value, but there is a dma_set_mask_and_coherent() function that does exactly that so let's use it instead. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- sound/pci/emu10k1/emu10k1_main

Re: [alsa-devel] [PATCH] sound: emu10k1: Replace GFP_ATOMIC with GFP_KERNEL in synth_alloc_pages

On 23.01.2018 10:37, Jia-Ju Bai wrote: > The function synth_alloc_pages is not called in atomic context. > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. > > Signed-off-by: Jia-Ju Bai > --- > sound/pci/emu10k1/memory.c |2 +- > 1 file

Re: [PATCH] X.509: unpack RSA signatureValue field from BIT STRING

On 07.03.2018 16:44, David Howells wrote: > Maciej S. Szmigiero <m...@maciej.szmigiero.name> wrote: > >> +if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) { > > I'm going to change this to '== 0' rather than '!'. No problem. > David > Thanks, Maciej

[PATCH] X.509: unpack RSA signatureValue field from BIT STRING

is a problem for RSA implementations that need it to be exactly correct (like AMD CCP). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates") Cc: sta...@vger.kernel.org --- This is a resend

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 11.03.2018 10:59, Ingo Molnar wrote: > > * Maciej S. Szmigiero <m...@maciej.szmigiero.name> wrote: > >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode file since it does very little >> consist

[PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it

are (hopefully) correctly rejected instead. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Changes from v1: Capitalize a comment, rename 'eqsize' and 'bufsize' to 'eq_size' and 'buf_size', respectively, attach a comment about checking the equivalence table header to its firs

Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it

On 12.03.2018 10:53, Borislav Petkov wrote: > On Sun, Mar 11, 2018 at 04:27:03PM +0100, Maciej S. Szmigiero wrote: >> +/* 4k */ >> +#define UCODE_EQUIV_CPU_TABLE_MAX_SIZE (256 * sizeof(struct >> equiv_cpu_entry)) > > And you came up with that max size how exactl

Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it

On 12.03.2018 14:48, Borislav Petkov wrote: > On Mon, Mar 12, 2018 at 02:32:30PM +0100, Maciej S. Szmigiero wrote: >> "microcode_amd.bin" in linux-firmware. > > That is the microcode container for all families < 0x15. And it > *happens* to have 18 en

Re: [PATCH v2] x86/microcode/AMD: check microcode file sanity before loading it

On 12.03.2018 14:06, Borislav Petkov wrote: > On Mon, Mar 12, 2018 at 01:56:59PM +0100, Maciej S. Szmigiero wrote: (..) >> Since the maximum entry count in current microcode files is 18 the > > Where did you dream up that 18? "microcode_amd.bin" in linux-firmware. >

[PATCH v3 4/9] x86/microcode/AMD: automatically compute the PATCH_MAX_SIZE macro

as an expression) and we have a static array using this macro value as its length. This macro is specific to amd.c file so let's move it there (the max sizes for families are in this file already). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/inclu

[PATCH v3 5/9] x86/microcode/AMD: check patch size in verify_and_add_patch()

the PATCH_MAX_SIZE check in parse_container() function. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kern

[PATCH v3 2/9] x86/microcode/AMD: check whether the equivalence table fits in the file

the equivalence table anyway. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 54 ++--- 1 file changed, 38 insertions(+), 16 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kern

[PATCH v3 0/9] x86/microcode/AMD: check microcode file sanity before loading it

Currently, it is very easy to make the AMD microcode update driver crash or spin on a malformed microcode container file since it does very little consistency checking on data loaded from such file. This series introduces various checks, mostly on length-type fields, so all corrupted microcode

[PATCH v3 7/9] x86/microcode/AMD: check microcode container file size before accessing it

enough to contain the header magic value. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c

[PATCH v3 8/9] x86/microcode/AMD: check the equivalence table size when scanning it

Currently, the code scanning the CPU equivalence table read from a microcode container file assumes that it actually contains a terminating zero entry. Let's check also the size of this table to make sure that we don't read past it in case it actually doesn't. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 6/9] x86/microcode/AMD: verify patch section type for every such section

We should check whether the patch section currently being processed is actually a patch section for each of them (not just the first one) in the late loader verify_and_add_patch() function, just like the early loader already does in parse_container() function. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

returned by this function are of no use anyway, since they are all normalized to UCODE_ERROR by its caller (__load_microcode_amd()). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 21 +++-- 1 file changed, 11 insertions(

[PATCH v3 1/9] x86/microcode/AMD: subtract SECTION_HDR_SIZE from file leftover length

from the leftover file length before passing this value to verify_patch_size(). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c

[PATCH v3 9/9] x86/microcode/AMD: be more tolerant of late parse failures in late loader

patches. Note that we already do silently skip patches in the late loader for smaller issues like lack of an equivalence table entry, family-size mismatch or an unsupported chipset match type. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd

[PATCH v4 07/10] x86/microcode/AMD: Verify patch section type for every such section

We should check whether the patch section currently being processed is actually a patch section for each of them (not just the first one) in the late loader verify_and_add_patch() function, just like the early loader already does in parse_container() function. Signed-off-by: Maciej S. Szmigiero

[PATCH v4 05/10] x86/microcode/AMD: Add a reminder about PATCH_MAX_SIZE macro

. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/include/asm/microcode_amd.h | 1 + arch/x86/kernel/cpu/microcode/amd.c | 4 2 files changed, 5 insertions(+) diff --git a/arch/x86/include/asm/microcode_amd.h b/arch/x86/include/asm/microcode_amd.h index 209492

Re: [PATCH v4 00/10] x86/microcode/AMD: Check microcode file sanity before loading it

On 16.03.2018 00:23, Borislav Petkov wrote: > On Fri, Mar 16, 2018 at 12:07:34AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode container file since it does very little >>

[PATCH v4 02/10] x86/microcode/AMD: Check equivalence table length in the early loader

the equivalence table anyway. This patch adds these checks to the early loader. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/ar

[PATCH v4 04/10] x86/microcode/AMD: install_equiv_cpu_table() should not return a signed int

codes returned by install_equiv_cpu_table() are of no use anyway, since they are all normalized to UCODE_ERROR by its caller. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 27 --- 1 file changed, 16 inse

[PATCH v4 03/10] x86/microcode/AMD: Check equivalence table length in the late loader

the equivalence table anyway. This patch adds these checks to the late loader. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 32 ++-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/arch/x86/

[PATCH v4 00/10] x86/microcode/AMD: Check microcode file sanity before loading it

Currently, it is very easy to make the AMD microcode update driver crash or spin on a malformed microcode container file since it does very little consistency checking on data loaded from such file. This series introduces various checks, mostly on length-type fields, so all corrupted microcode

[PATCH v4 01/10] x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length

from the leftover file length before passing this value to verify_patch_size(). Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode

[PATCH v4 08/10] x86/microcode/AMD: Check microcode container file size before accessing it

enough to contain the header magic value. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c

[PATCH v4 09/10] x86/microcode/AMD: Check the equivalence table size when scanning it

Currently, the code scanning the CPU equivalence table read from a microcode container file assumes that it actually contains a terminating zero entry. Let's check also the size of this table to make sure that we don't read past it in case it actually doesn't. Signed-off-by: Maciej S. Szmigiero

[PATCH v4 10/10] x86/microcode/AMD: Be more tolerant of late parse failures in late loader

patches. Note that we already do silently skip patches in the late loader for smaller issues like lack of an equivalence table entry, family-size mismatch or an unsupported chipset match type. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd

[PATCH v4 06/10] x86/microcode/AMD: Check patch size in verify_and_add_patch()

check in parse_container() function. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- arch/x86/kernel/cpu/microcode/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/mic

[PATCH] x86/microcode/AMD: check microcode file sanity before loading it

are (hopefully) correctly rejected instead. Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> --- Test files are at https://pastebin.com/XkKUSmMp One has to enable KASAN in the kernel config and rename a particular test file to name appropriate to the running CPU family to test its l

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 01:34, Maciej S. Szmigiero wrote: > Currently, it is very easy to make the AMD microcode update driver crash > or spin on a malformed microcode file since it does very little > consistency checking on data loaded from such file. > > This commit introduces various

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 14:12, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: >> Without them, it is easy to crash the driver when just playing with >> microcode files > > You're not supposed to play with the microcode files. If you do a

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 10:18, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode file since it does very little >> consistency ch

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 17:46, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 05:16:40PM +0100, Maciej S. Szmigiero wrote: (..) >> There is no container file at all for family 17h (Zen) so >> distributions like OpenSUSE that include this file must have gotten it >> from some other

Re: [PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

On 15.03.2018 00:58, Borislav Petkov wrote: > On Thu, Mar 15, 2018 at 12:46:05AM +0100, Maciej S. Szmigiero wrote: >> The maximum possible value returned by install_equiv_cpu_table() of >> UINT_MAX + CONTAINER_HDR_SZ comes from the maximum value of this 'size' >> variable (t

Re: [PATCH v3 4/9] x86/microcode/AMD: automatically compute the PATCH_MAX_SIZE macro

On 14.03.2018 19:02, Borislav Petkov wrote: > On Tue, Mar 13, 2018 at 10:06:48PM +0100, Maciej S. Szmigiero wrote: >> +/* Maximum of all the above families */ >> +#define PATCH_MAX_SIZE SIMPLE_MAX3(F1XH_MPB_MAX_SIZE, F14H_MPB_MAX_SIZE, \ > > Nope, it should be > > #d

Re: [PATCH v3 2/9] x86/microcode/AMD: check whether the equivalence table fits in the file

On 14.03.2018 18:04, Borislav Petkov wrote: > On Tue, Mar 13, 2018 at 10:06:23PM +0100, Maciej S. Szmigiero wrote: (..) >> --- a/arch/x86/kernel/cpu/microcode/amd.c >> +++ b/arch/x86/kernel/cpu/microcode/amd.c >> @@ -80,20 +80,29 @@ static u16 find_equiv_id(struct equiv_cpu_e

Re: [PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

On 15.03.2018 01:56, Borislav Petkov wrote: > On Thu, Mar 15, 2018 at 01:13:07AM +0100, Maciej S. Szmigiero wrote: >> This can be done if this function is modified to return only the CPU >> equivalence table length (without the container header length), leaving >> its

Re: [PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

On 14.03.2018 18:58, Borislav Petkov wrote: > On Tue, Mar 13, 2018 at 10:06:34PM +0100, Maciej S. Szmigiero wrote: >> The maximum possible value returned by install_equiv_cpu_table() is >> UINT_MAX + CONTAINER_HDR_SZ (on a 64-bit kernel). >> This is more than (signed) int ty

Re: x86/retpoline: Fill RSB on context switch for affected CPUs

On 12.01.2018 18:49, Woodhouse, David wrote: > When we context switch from a shallow call stack to a deeper one, as we > 'ret' up the deeper side we may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. This is > problematic if we have neither

Re: x86/retpoline: Fill RSB on context switch for affected CPUs

On 09.03.2018 16:14, Andi Kleen wrote: >> Shouldn't the RSB filling on context switch also be done on non-IBPB >> CPUs to protect (retpolined) user space tasks from other user space >> tasks? > > The comment is actually incorrect. There's no risk to hit user space > addresses if we have KPTI and

Re: [PATCH v4 01/10] x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length

On 18.03.2018 17:12, Borislav Petkov wrote: > On Fri, Mar 16, 2018 at 12:07:42AM +0100, Maciej S. Szmigiero wrote: >> verify_patch_size() function verifies whether the microcode container file >> remaining size is large enough to contain a patch of the indicated size. >> &g

Re: [PATCH v2] X.509: unpack RSA signatureValue field from BIT STRING

On 17.04.2018 17:07, Kamil Konieczny wrote: > > > On 17.04.2018 15:39, Maciej S. Szmigiero wrote: >> The signatureValue field of a X.509 certificate is encoded as a BIT STRING. >> For RSA signatures this BIT STRING is of so-called primitive subtype, which >> cont

Re: [PATCH v4 01/10] x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length

On 18.04.2018 15:53, Borislav Petkov wrote: > On Wed, Apr 18, 2018 at 02:39:27PM +0200, Maciej S. Szmigiero wrote: >> Can't really find this commit in any tree I have looked at (bp.git and >> tip.git at kernel.org). >> Was it pushed somewhere else? > > No. Still w

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