July 2020 - Linux-stable-mirror

Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

by Lu Baolu

Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: >>> Kernel panic - not syncing: DMAR hardware is malfunctioning >>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 >>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 >>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019 >>> Call Trace: >>> dump_stack+0x59/0x75 >>> panic+0xff/0x2d4 >>> iommu_disable_translation+0x88/0x90 >>> iommu_suspend+0x12f/0x1b0 >>> syscore_suspend+0x6c/0x220 >>> suspend_devices_and_enter+0x313/0x840 >>> pm_suspend+0x30d/0x390 >>> state_store+0x82/0xf0 >>> kobj_attr_store+0x12/0x20 >>> sysfs_kf_write+0x3c/0x50 >>> kernfs_fop_write+0x11d/0x190 >>> __vfs_write+0x1b/0x40 >>> vfs_write+0xc6/0x1d0 >>> ksys_write+0x5e/0xe0 >>> __x64_sys_write+0x1a/0x20 >>> do_syscall_64+0x4d/0x150 >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> RIP: 0033:0x7f97b8080113 >>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 >>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff >>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 >>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 >>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113 >>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004 >>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004 >>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004 >>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700 >>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range: >>> 0xffffffff80000000-0xffffffffbfffffff) >>> ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]--- > Do you mean that system hangs in iommu_disable_translation() without this fix. > [S3 successfully with the patch] And, this failure disappeared after you applied this fix? Best regards, baolu

4 years, 5 months

2
3
0 0

[PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

by Ashok Raj

PASID and PRI capabilities are only enumerated in PF devices. VF devices do not enumerate these capabilites. IOMMU drivers also need to enumerate them before enabling features in the IOMMU. Extending the same support as PASID feature discovery (pci_pasid_features) for PRI. Signed-off-by: Ashok Raj <ashok.raj(a)intel.com> v2: Fixed build failure from lkp when CONFIG_PRI=n Almost all the PRI functions were called only when CONFIG_PASID is set. Except the new pci_pri_supported(). previous version sent in error because i missed dry-run before recompile :-( To: Bjorn Helgaas <bhelgaas(a)google.com> To: Joerg Roedel <joro(a)8bytes.com> To: Lu Baolu <baolu.lu(a)intel.com> Cc: stable(a)vger.kernel.org Cc: linux-pci(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: iommu(a)lists.linux-foundation.org --- drivers/iommu/intel/iommu.c | 2 +- drivers/pci/ats.c | 13 +++++++++++++ include/linux/pci-ats.h | 4 ++++ 3 files changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index d759e7234e98..276452f5e6a7 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2560,7 +2560,7 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, } if (info->ats_supported && ecap_prs(iommu->ecap) && - pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI)) + pci_pri_supported(pdev)) info->pri_supported = 1; } } diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index b761c1f72f67..2e6cf0c700f7 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -325,6 +325,19 @@ int pci_prg_resp_pasid_required(struct pci_dev *pdev) return pdev->pasid_required; } + +/** + * pci_pri_supported - Check if PRI is supported. + * @pdev: PCI device structure + * + * Returns true if PRI capability is present, false otherwise. + */ +bool pci_pri_supported(struct pci_dev *pdev) +{ + /* VFs share the PF PRI configuration */ + return !!(pci_physfn(pdev)->pri_cap); +} +EXPORT_SYMBOL_GPL(pci_pri_supported); #endif /* CONFIG_PCI_PRI */ #ifdef CONFIG_PCI_PASID diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h index f75c307f346d..df54cd5b15db 100644 --- a/include/linux/pci-ats.h +++ b/include/linux/pci-ats.h @@ -28,6 +28,10 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs); void pci_disable_pri(struct pci_dev *pdev); int pci_reset_pri(struct pci_dev *pdev); int pci_prg_resp_pasid_required(struct pci_dev *pdev); +bool pci_pri_supported(struct pci_dev *pdev); +#else +static inline bool pci_pri_supported(struct pci_dev *pdev) +{ return false; } #endif /* CONFIG_PCI_PRI */ #ifdef CONFIG_PCI_PASID -- 2.7.4

4 years, 5 months

1
0
0 0

+ mm-fix-kthread_use_mm-vs-tlb-invalidate.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm: fix kthread_use_mm() vs TLB invalidate has been added to the -mm tree. Its filename is mm-fix-kthread_use_mm-vs-tlb-invalidate.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-kthread_use_mm-vs-tlb-inval… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-kthread_use_mm-vs-tlb-inval… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Peter Zijlstra <peterz(a)infradead.org> Subject: mm: fix kthread_use_mm() vs TLB invalidate For SMP systems using IPI based TLB invalidation, looking at current->active_mm is entirely reasonable. This then presents the following race condition: CPU0 CPU1 flush_tlb_mm(mm) use_mm(mm) <send-IPI> tsk->active_mm = mm; <IPI> if (tsk->active_mm == mm) // flush TLBs </IPI> switch_mm(old_mm,mm,tsk); Where it is possible the IPI flushed the TLBs for @old_mm, not @mm, because the IPI lands before we actually switched. Avoid this by disabling IRQs across changing ->active_mm and switch_mm(). [ There are all sorts of reasons this might be harmless for various architecture specific reasons, but best not leave the door open at all. ] Link: http://lkml.kernel.org/r/20200721154106.GE10769@hirez.programming.kicks-ass… Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reported-by: Andy Lutomirski <luto(a)amacapital.net> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Kees Cook <keescook(a)chromium.org> Cc: Jann Horn <jannh(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kthread.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/kernel/kthread.c~mm-fix-kthread_use_mm-vs-tlb-invalidate +++ a/kernel/kthread.c @@ -1239,13 +1239,15 @@ void kthread_use_mm(struct mm_struct *mm WARN_ON_ONCE(tsk->mm); task_lock(tsk); + local_irq_disable(); active_mm = tsk->active_mm; if (active_mm != mm) { mmgrab(mm); tsk->active_mm = mm; } tsk->mm = mm; - switch_mm(active_mm, mm, tsk); + switch_mm_irqs_off(active_mm, mm, tsk); + local_irq_enable(); task_unlock(tsk); #ifdef finish_arch_post_lock_switch finish_arch_post_lock_switch(); @@ -1274,9 +1276,11 @@ void kthread_unuse_mm(struct mm_struct * task_lock(tsk); sync_mm_rss(mm); + local_irq_disable(); tsk->mm = NULL; /* active_mm is still 'mm' */ enter_lazy_tlb(mm, tsk); + local_irq_enable(); task_unlock(tsk); } EXPORT_SYMBOL_GPL(kthread_unuse_mm); _ Patches currently in -mm which might be from peterz(a)infradead.org are mm-fix-kthread_use_mm-vs-tlb-invalidate.patch

4 years, 5 months

1
0
0 0

+ io-mapping-indicate-mapping-failure.patch added to -mm tree

by Andrew Morton

The patch titled Subject: io-mapping: indicate mapping failure has been added to the -mm tree. Its filename is io-mapping-indicate-mapping-failure.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/io-mapping-indicate-mapping-failur… and later at http://ozlabs.org/~akpm/mmotm/broken-out/io-mapping-indicate-mapping-failur… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Michael J. Ruhl" <michael.j.ruhl(a)intel.com> Subject: io-mapping: indicate mapping failure The !ATOMIC_IOMAP version of io_maping_init_wc will always return success, even when the ioremap fails. Since the ATOMIC_IOMAP version returns NULL when the init fails, and callers check for a NULL return on error this is unexpected. During a device probe, where the ioremap failed, a crash can look like this: BUG: unable to handle page fault for address: 0000000000210000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 177 Comm: RIP: 0010:fill_page_dma [i915] gen8_ppgtt_create [i915] i915_ppgtt_create [i915] intel_gt_init [i915] i915_gem_init [i915] i915_driver_probe [i915] pci_device_probe really_probe driver_probe_device The remap failure occurred much earlier in the probe. If it had been propagated, the driver would have exited with an error. Return NULL on ioremap failure. Link: http://lkml.kernel.org/r/20200721171936.81563-1-michael.j.ruhl@intel.com Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping") Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Mike Rapoport <rppt(a)linux.ibm.com> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/io-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure +++ a/include/linux/io-mapping.h @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *io iomap->prot = pgprot_noncached(PAGE_KERNEL); #endif - return iomap; + return iomap->iomem ? iomap : NULL; } static inline void _ Patches currently in -mm which might be from michael.j.ruhl(a)intel.com are io-mapping-indicate-mapping-failure.patch

4 years, 5 months

1
0
0 0

+ fork-silence-a-false-postive-warning-in-__mmdrop.patch added to -mm tree

by Andrew Morton

The patch titled Subject: fork: silence a false postive warning in __mmdrop has been added to the -mm tree. Its filename is fork-silence-a-false-postive-warning-in-__mmdrop.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/fork-silence-a-false-postive-warni… and later at http://ozlabs.org/~akpm/mmotm/broken-out/fork-silence-a-false-postive-warni… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Qian Cai <cai(a)lca.pw> Subject: fork: silence a false postive warning in __mmdrop commit bf2c59fce407 ("sched/core: Fix illegal RCU from offline CPUs") delayed, idle->active_mm = &init_mm; into finish_cpu() instead of idle_task_exit() which results in a false positive warning that was originally designed in the commit 3eda69c92d47 ("kernel/fork.c: detect early free of a live mm"). WARNING: CPU: 127 PID: 72976 at kernel/fork.c:697 __mmdrop+0x230/0x2c0 do_exit+0x424/0xfa0 Call Trace: do_exit+0x424/0xfa0 do_group_exit+0x64/0xd0 sys_exit_group+0x24/0x30 system_call_exception+0x108/0x1d0 system_call_common+0xf0/0x278 Link: http://lkml.kernel.org/r/20200604150344.1796-1-cai@lca.pw Fixes: bf2c59fce407 ("sched/core: Fix illegal RCU from offline CPUs") Signed-off-by: Qian Cai <cai(a)lca.pw> Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> (powerpc) Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/fork.c | 1 - 1 file changed, 1 deletion(-) --- a/kernel/fork.c~fork-silence-a-false-postive-warning-in-__mmdrop +++ a/kernel/fork.c @@ -694,7 +694,6 @@ void __mmdrop(struct mm_struct *mm) { BUG_ON(mm == &init_mm); WARN_ON_ONCE(mm == current->mm); - WARN_ON_ONCE(mm == current->active_mm); mm_free_pgd(mm); destroy_context(mm); mmu_notifier_subscriptions_destroy(mm); _ Patches currently in -mm which might be from cai(a)lca.pw are fork-silence-a-false-postive-warning-in-__mmdrop.patch mm-page_alloc-silence-a-kasan-false-positive.patch mm-kmemleak-silence-kcsan-splats-in-checksum.patch mm-frontswap-mark-various-intentional-data-races.patch mm-page_io-mark-various-intentional-data-races.patch mm-page_io-mark-various-intentional-data-races-v2.patch mm-swap_state-mark-various-intentional-data-races.patch mm-swapfile-fix-and-annotate-various-data-races.patch mm-swapfile-fix-and-annotate-various-data-races-v2.patch mm-page_counter-fix-various-data-races-at-memsw.patch mm-memcontrol-fix-a-data-race-in-scan-count.patch mm-list_lru-fix-a-data-race-in-list_lru_count_one.patch mm-mempool-fix-a-data-race-in-mempool_free.patch mm-rmap-annotate-a-data-race-at-tlb_flush_batched.patch mm-swap-annotate-data-races-for-lru_rotate_pvecs.patch mm-annotate-a-data-race-in-page_zonenum.patch

4 years, 5 months

1
0
0 0

[PATCH v2] Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation

by Fangrui Song

When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6…) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Reported-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Fangrui Song <maskray(a)google.com> Reviewed-by: Nathan Chancellor <natechancellor(a)gmail.com> Tested-by: Nathan Chancellor <natechancellor(a)gmail.com> Tested-by: Nick Desaulniers <ndesaulniers(a)google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 --- Changes in v2: * Updated description to add tags and the llvm-project commit link. * Fixed a typo. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 0b5f8538bde5..3ac83e375b61 100644 --- a/Makefile +++ b/Makefile @@ -567,7 +567,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),) ifneq ($(CROSS_COMPILE),) CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) -CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR) +CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) endif ifneq ($(GCC_TOOLCHAIN),) -- 2.28.0.rc0.105.gf9edc3c819-goog

4 years, 5 months

4
4
0 0

[PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

by Ashok Raj

PASID and PRI capabilities are only enumerated in PF devices. VF devices do not enumerate these capabilites. IOMMU drivers also need to enumerate them before enabling features in the IOMMU. Extending the same support as PASID feature discovery (pci_pasid_features) for PRI. Signed-off-by: Ashok Raj <ashok.raj(a)intel.com> v2: Fixed build failure from lkp when CONFIG_PRI=n Almost all the PRI functions were called only when CONFIG_PASID is set. Except the new pci_pri_supported(). To: Bjorn Helgaas <bhelgaas(a)google.com> To: Joerg Roedel <joro(a)8bytes.com> To: Lu Baolu <baolu.lu(a)intel.com> Cc: stable(a)vger.kernel.org Cc: linux-pci(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: iommu(a)lists.linux-foundation.org --- drivers/iommu/intel/iommu.c | 2 +- drivers/pci/ats.c | 14 ++++++++++++++ include/linux/pci-ats.h | 4 ++++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index d759e7234e98..276452f5e6a7 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2560,7 +2560,7 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu, } if (info->ats_supported && ecap_prs(iommu->ecap) && - pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI)) + pci_pri_supported(pdev)) info->pri_supported = 1; } } diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index b761c1f72f67..ffb4de8c5a77 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -461,6 +461,20 @@ int pci_pasid_features(struct pci_dev *pdev) } EXPORT_SYMBOL_GPL(pci_pasid_features); +/** + * pci_pri_supported - Check if PRI is supported. + * @pdev: PCI device structure + * + * Returns false when no PRI capability is present. + * Returns true if PRI feature is supported and enabled + */ +bool pci_pri_supported(struct pci_dev *pdev) +{ + /* VFs share the PF PRI configuration */ + return !!(pci_physfn(pdev)->pri_cap); +} +EXPORT_SYMBOL_GPL(pci_pri_supported); + #define PASID_NUMBER_SHIFT 8 #define PASID_NUMBER_MASK (0x1f << PASID_NUMBER_SHIFT) /** diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h index f75c307f346d..fc989295daf3 100644 --- a/include/linux/pci-ats.h +++ b/include/linux/pci-ats.h @@ -28,6 +28,10 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs); void pci_disable_pri(struct pci_dev *pdev); int pci_reset_pri(struct pci_dev *pdev); int pci_prg_resp_pasid_required(struct pci_dev *pdev); +bool pci_pri_supported(struct pci_dev *pdev); +#else +bool pci_pri_supported(struct pci_dev *pdev) +{ return false; } #endif /* CONFIG_PCI_PRI */ #ifdef CONFIG_PCI_PASID -- 2.7.4

4 years, 5 months

1
0
0 0

[PATCH v6] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime

by Bruno Meneguele

The IMA_APPRAISE_BOOTPARAM config allows enabling different "ima_appraise=" modes - log, fix, enforce - at run time, but not when IMA architecture specific policies are enabled. This prevents properly labeling the filesystem on systems where secure boot is supported, but not enabled on the platform. Only when secure boot is actually enabled should these IMA appraise modes be disabled. This patch removes the compile time dependency and makes it a runtime decision, based on the secure boot state of that platform. Test results as follows: -> x86-64 with secure boot enabled [ 0.015637] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix [ 0.015668] ima: Secure boot enabled: ignoring ima_appraise=fix boot parameter option -> powerpc with secure boot disabled [ 0.000000] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix [ 0.000000] Secure boot mode disabled -> Running the system without secure boot and with both options set: CONFIG_IMA_APPRAISE_BOOTPARAM=y CONFIG_IMA_ARCH_POLICY=y Audit prompts "missing-hash" but still allow execution and, consequently, filesystem labeling: type=INTEGRITY_DATA msg=audit(07/09/2020 12:30:27.778:1691) : pid=4976 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data cause=missing-hash comm=bash name=/usr/bin/evmctl dev="dm-0" ino=493150 res=no Cc: stable(a)vger.kernel.org Fixes: d958083a8f64 ("x86/ima: define arch_get_ima_policy() for x86") Signed-off-by: Bruno Meneguele <bmeneg(a)redhat.com> --- v6: - explictly print the bootparam being ignored to the user (Mimi) v5: - add pr_info() to inform user the ima_appraise= boot param is being ignored due to secure boot enabled (Nayna) - add some testing results to commit log v4: - instead of change arch_policy loading code, check secure boot state at "ima_appraise=" parameter handler (Mimi) v3: - extend secure boot arch checker to also consider trusted boot - enforce IMA appraisal when secure boot is effectively enabled (Nayna) - fix ima_appraise flag assignment by or'ing it (Mimi) v2: - pr_info() message prefix correction security/integrity/ima/Kconfig | 2 +- security/integrity/ima/ima_appraise.c | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig index edde88dbe576..62dc11a5af01 100644 --- a/security/integrity/ima/Kconfig +++ b/security/integrity/ima/Kconfig @@ -232,7 +232,7 @@ config IMA_APPRAISE_REQUIRE_POLICY_SIGS config IMA_APPRAISE_BOOTPARAM bool "ima_appraise boot parameter" - depends on IMA_APPRAISE && !IMA_ARCH_POLICY + depends on IMA_APPRAISE default y help This option enables the different "ima_appraise=" modes diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c index a9649b04b9f1..28a59508c6bd 100644 --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -19,6 +19,12 @@ static int __init default_appraise_setup(char *str) { #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM + if (arch_ima_get_secureboot()) { + pr_info("Secure boot enabled: ignoring ima_appraise=%s boot parameter option", + str); + return 1; + } + if (strncmp(str, "off", 3) == 0) ima_appraise = 0; else if (strncmp(str, "log", 3) == 0) -- 2.26.2

4 years, 5 months

3
6
0 0

patch "serial: 8250_mtk: Fix high-speed baud rates clamping" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_mtk: Fix high-speed baud rates clamping to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 551e553f0d4ab623e2a6f424ab5834f9c7b5229c Mon Sep 17 00:00:00 2001 From: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Date: Tue, 14 Jul 2020 15:41:12 +0300 Subject: serial: 8250_mtk: Fix high-speed baud rates clamping Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler… Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler <danielwinkler(a)google.com> Signed-off-by: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Cc: stable <stable(a)vger.kernel.org> Tested-by: Claire Chang <tientzu(a)chromium.org> Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectro… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_mtk.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c index f839380c2f4c..98b8a3e30733 100644 --- a/drivers/tty/serial/8250/8250_mtk.c +++ b/drivers/tty/serial/8250/8250_mtk.c @@ -306,8 +306,21 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios, } #endif + /* + * Store the requested baud rate before calling the generic 8250 + * set_termios method. Standard 8250 port expects bauds to be + * no higher than (uartclk / 16) so the baud will be clamped if it + * gets out of that bound. Mediatek 8250 port supports speed + * higher than that, therefore we'll get original baud rate back + * after calling the generic set_termios method and recalculate + * the speed later in this method. + */ + baud = tty_termios_baud_rate(termios); + serial8250_do_set_termios(port, termios, old); + tty_termios_encode_baud_rate(termios, baud, baud); + /* * Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS) * @@ -339,6 +352,11 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios, */ spin_lock_irqsave(&port->lock, flags); + /* + * Update the per-port timeout. + */ + uart_update_timeout(port, termios->c_cflag, baud); + /* set DLAB we have cval saved in up->lcr from the call to the core */ serial_port_out(port, UART_LCR, up->lcr | UART_LCR_DLAB); serial_dl_write(up, quot); -- 2.27.0

4 years, 5 months

1
0
0 0

patch "serial: 8250: fix null-ptr-deref in serial8250_start_tx()" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250: fix null-ptr-deref in serial8250_start_tx() to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From f4c23a140d80ef5e6d3d1f8f57007649014b60fa Mon Sep 17 00:00:00 2001 From: Yang Yingliang <yangyingliang(a)huawei.com> Date: Tue, 21 Jul 2020 14:38:52 +0000 Subject: serial: 8250: fix null-ptr-deref in serial8250_start_tx() I got null-ptr-deref in serial8250_start_tx(): [ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 78.123778] Mem abort info: [ 78.126560] ESR = 0x86000007 [ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits [ 78.134891] SET = 0, FnV = 0 [ 78.137933] EA = 0, S1PTW = 0 [ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600 [ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000 [ 78.160029] Internal error: Oops: 86000007 [#1] SMP [ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd [ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48 [ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020 [ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 78.228435] pc : 0x0 [ 78.230618] lr : serial8250_start_tx+0x160/0x260 [ 78.235215] sp : ffff800062eefb80 [ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff [ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000 [ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000 [ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002 [ 78.259679] x21: 0000000000000001 x20: 0000000000000000 [ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000 [ 78.270259] x17: 0000000000000000 x16: 0000000000000000 [ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6 [ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539 [ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0 [ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88 [ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000 [ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8 [ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002 [ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8 [ 78.317873] Call trace: [ 78.320312] 0x0 [ 78.322147] __uart_start.isra.9+0x64/0x78 [ 78.326229] uart_start+0xb8/0x1c8 [ 78.329620] uart_flush_chars+0x24/0x30 [ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30 [ 78.338128] n_tty_receive_buf+0x44/0x2c8 [ 78.342122] tty_ioctl+0x348/0x11f8 [ 78.345599] ksys_ioctl+0xd8/0xf8 [ 78.348903] __arm64_sys_ioctl+0x2c/0xc8 [ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0 [ 78.357583] do_el0_svc+0x44/0xd0 [ 78.360887] el0_sync_handler+0x14c/0x1d0 [ 78.364880] el0_sync+0x140/0x180 [ 78.368185] Code: bad PC value SERIAL_PORT_DFNS is not defined on each arch, if it's not defined, serial8250_set_defaults() won't be called in serial8250_isa_init_ports(), so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref. Fix this problem by calling serial8250_set_defaults() after init uart port. Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index fc118f649887..cae61d1ebec5 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -524,6 +524,7 @@ static void __init serial8250_isa_init_ports(void) */ up->mcr_mask = ~ALPHA_KLUDGE_MCR; up->mcr_force = ALPHA_KLUDGE_MCR; + serial8250_set_defaults(up); } /* chain base port ops to support Remote Supervisor Adapter */ @@ -547,7 +548,6 @@ static void __init serial8250_isa_init_ports(void) port->membase = old_serial_port[i].iomem_base; port->iotype = old_serial_port[i].io_type; port->regshift = old_serial_port[i].iomem_reg_shift; - serial8250_set_defaults(up); port->irqflags |= irqflag; if (serial8250_isa_config != NULL) -- 2.27.0

4 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2020