Hi Stefan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on 03c765b0e3b4cb5063276b086c76f7a612856a9a]
url:
https://github.com/intel-lab-lkp/linux/commits/Stefan-Berger/tpm-Preserve-TPM-measurement-log-across-kexec-ppc64/20220706-232658
base
I think the header file could avoid redefinition errors.
at compile time by adding macro definitions.
Signed-off-by: Li zeming
---
drivers/macintosh/windfarm_pid.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/macintosh/windfarm_pid.h b/drivers/macintosh/windfarm_pid.h
index
Add header file macro definition.
Signed-off-by: Li zeming
---
drivers/macintosh/ams/ams.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/macintosh/ams/ams.h b/drivers/macintosh/ams/ams.h
index 935bdd9cd9a6..5ec5547f151b 100644
--- a/drivers/macintosh/ams/ams.h
+++
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
ieu.desnoy...@efficios.com>, Frederic Weisbecker , Len
Brown , linux-xte...@linux-xtensa.org, Sascha Hauer
, Vasily Gorbik , linux-arm-msm
, linux-al...@vger.kernel.org, linux-m68k
, Stafford Horne , Linux ARM
, Chris Zankel ,
Stephen Boyd , dingu...@kernel.org, Daniel Bristot de
Oliveira ,
snps-...@lists.infradead.org, mgor...@suse.de, jacob.jun@linux.intel.com,
Arnd Bergmann , Hans Ulli Kroll ,
Vineet Gupta , linux-...@vger.kernel.org,
j...@joshtriplett.org, rost...@goodmis.org, r...@vger.kernel.org,
b...@alien8.de, bc...@quicinc.com, tsbog...@alpha.franken.de,
On July 6, 2022 5:23:31 AM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 04:11:45PM -0700, H. Peter Anvin wrote:
>> What I'm wondering is if we shouldn't be simply instrument *every*
>> invocation, and set the trust to zero if we ever trip it.
>
>I guess you can add some logic to
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Nathan Lynch
[ Upstream commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe ]
kasan detects access beyond the end of the xibm->bitmap allocation:
BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
Read of size 8 at addr c0001d1d0118 by task swapper/0/1
CPU: 0 PID: 1 Comm:
From: Liang He
[ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ]
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
Signed-off-by: Liang He
Signed-off-by: Viresh
From: Nathan Lynch
[ Upstream commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe ]
kasan detects access beyond the end of the xibm->bitmap allocation:
BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
Read of size 8 at addr c0001d1d0118 by task swapper/0/1
CPU: 0 PID: 1 Comm:
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
---
v5:
- Rebased on Jonathan McDowell's commit "b69a2afd5afc x86/kexec: Carry
forward IMA measurement log on
From: Vaibhav Jain
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the
The memory area of the TPM measurement log is currently not properly
duplicated for carrying it across kexec when an Open Firmware
Devicetree is used. Therefore, the contents of the log get corrupted.
Fix this for the kexec_file_load() syscall by allocating a buffer and
copying the contents of the
The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
series fixes this for the kexec_file_load() syscall using the flattened
device tree (fdt) to carry the TPM measurement log's buffer across kexec.
Stefan
Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.
Signed-off-by: Stefan Berger
Cc: Jarkko Sakkinen
From: Jonathan McDowell
On kexec file load, the Integrity Measurement Architecture (IMA)
subsystem may verify the IMA signature of the kernel and initramfs, and
measure it. The command line parameters passed to the kernel in the
kexec call may also be measured by IMA.
A remote attestation
From: Palmer Dabbelt
RISC-V recently added kexec_file() support, which uses enables kexec
IMA. We're the first 32-bit platform to support this, so we found a
build bug.
Acked-by: Rob Herring
Signed-off-by: Palmer Dabbelt
Reviewed-by: Mimi Zohar
---
drivers/of/kexec.c | 4 ++--
1 file
On 7/6/22 10:00, Jonathan McDowell wrote:
On Tue, Jul 05, 2022 at 06:46:54PM -0400, Mimi Zohar wrote:
[Cc'ing Borislav Petkov , Jonathan McDowell
]
Hi Stefan,
On Thu, 2022-06-30 at 22:26 -0400, Stefan Berger wrote:
Refactor IMA buffer related functions to make them reusable for carrying
On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote:
> Later the thinking evolved. With a properly designed RNG, using RDRAND
> values alone won't harm anything, even if the outputs are malicious.
I personally think it's totally fine to remove nordrand. However, the
reason why it
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed
Le 04/07/2022 à 09:55, Christophe Leroy a écrit :
Le 04/07/2022 à 09:45, Aneesh Kumar K V a écrit :
On 7/4/22 12:43 PM, Christophe Leroy wrote:
Le 04/07/2022 à 08:39, Aneesh Kumar K.V a écrit :
Instead of high_memory use is_vmalloc_addr to validate that the
address is
not in the
On 7/6/22 15:33, Geert Uytterhoeven wrote:
> Hi Anshuman,
>
> On Thu, Jun 30, 2022 at 7:19 AM Anshuman Khandual
> wrote:
>> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
>> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
>> up a
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed
Function pci_create_OF_bus_map() is used only in chrp code.
So hide it from all other platforms as it is unsed.
Signed-off-by: Pali Rohár
---
arch/powerpc/include/asm/pci-bridge.h | 2 ++
arch/powerpc/kernel/pci_32.c | 2 ++
2 files changed, 4 insertions(+)
diff --git
By default on PPC32 are PCI bus numbers unique across all PCI domains.
So system could have only 256 PCI buses independently of available
PCI domains.
This is due to filling DT property pci-OF-bus-map which does not reflect
multi-domain setup.
On all powerpc platforms except chrp and powermac
Function pcibios_make_OF_bus_map() is used only in pci_32.c file.
So make it static and do not export out of pci_32.o unit.
Signed-off-by: Pali Rohár
---
arch/powerpc/kernel/pci_32.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c
Creating or filling pci-OF-bus-map property in the device-tree is
deprecated since May 2006 [1] and was used only in old platforms like
PowerMac.
Currently kernel code handles it only for chrp and powermac code. So
completely disable filling pci-OF-bus-map property for non-chrp and
non-powermac
Function pci_device_from_OF_node() is used only in powermac code.
So hide it from all other platforms as it is unsed.
Signed-off-by: Pali Rohár
---
arch/powerpc/include/asm/pci-bridge.h | 2 ++
arch/powerpc/kernel/pci_32.c | 2 ++
arch/powerpc/kernel/pci_64.c | 2 ++
3 files
This patch series cleanup unused code by eliminating it at compile time
and then enable usage of all 256 PCI buses per every PCI domain as
currently PCI bus numbers have to be unique across all PCI domains.
So first bus number of each PCI domain would be zero and not the bus
number of the previous
On Friday 10 June 2022 17:33:32 Michael Ellerman wrote:
> Pali Rohár writes:
> > Since commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on
> > device-tree properties"), powerpc kernel always fallback to PCI domain
> > assignment from OF / Device Tree 'reg' property of the PCI
Other Linux architectures use DT property 'linux,pci-domain' for specifying
fixed PCI domain of PCI controller specified in Device-Tree.
And lot of Freescale powerpc boards have defined numbered pci alias in
Device-Tree for every PCIe controller which number specify preferred PCI
domain.
So
Since commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on
device-tree properties"), powerpc kernel always fallback to PCI domain
assignment from OF / Device Tree 'reg' property of the PCI controller.
In most cases 'reg' property is not zero and therefore there it cause that
PCI
By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class
Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020
board which has this pre-3.0 controller:
$ lspci -bvnn
00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev
21)
On Thu, Jun 30, 2022 at 7:20 AM Anshuman Khandual
wrote:
> Now all the platforms enable ARCH_HAS_GET_PAGE_PROT. They define and export
> own vm_get_page_prot() whether custom or standard DECLARE_VM_GET_PAGE_PROT.
> Hence there is no need for default generic fallback for vm_get_page_prot().
> Just
Hi Anshuman,
On Thu, Jun 30, 2022 at 7:19 AM Anshuman Khandual
wrote:
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] array. Subsequently all
On Wed, Jul 06, 2022 at 12:13:15PM +0300, Vladimir Oltean wrote:
> On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
> > (Only an error message is printed if the value is
On Tue, Jun 28, 2022 at 04:03:12PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the
On Wed, Jul 06, 2022 at 02:32:25AM +0200, Jason A. Donenfeld wrote:
> When RDRAND was introduced, there was much discussion on whether it
> should be trusted and how the kernel should handle that. Initially, two
> mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
> "nordrand",
On 7/6/22 12:34, Arnd Bergmann wrote:
> On Wed, Jul 6, 2022 at 8:33 AM Christophe Leroy
> wrote:
>
>> As far as I can see in Kconfig, CONFIG_MMU is user selectable on the
>> following architectures:
>> - ARM
>> - M68K
>> - RISCV
>> - SH
>>
>> And is disabled by default on XTENSA.
>
> Right,
On Wed, Jul 6, 2022 at 8:33 AM Christophe Leroy
wrote:
> As far as I can see in Kconfig, CONFIG_MMU is user selectable on the
> following architectures:
> - ARM
> - M68K
> - RISCV
> - SH
>
> And is disabled by default on XTENSA.
Right, the list is complete, though it's also default-enabled for
On Wed, Jul 06, 2022 at 02:32:25AM +0200, Jason A. Donenfeld wrote:
> When RDRAND was introduced, there was much discussion on whether it
> should be trusted and how the kernel should handle that. Initially, two
> mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
> "nordrand",
Le 06/07/2022 à 07:57, Anshuman Khandual a écrit :
>
>
> On 6/30/22 10:46, Anshuman Khandual wrote:
>> __SXXX/__PXXX macros is an unnecessary abstraction layer in creating the
>> generic protection_map[] array which is used for vm_get_page_prot(). This
>> abstraction layer can be avoided, if
52 matches
Mail list logo
