Add maintainer Kazu to CC.
On 02/23/24 at 11:23am, Aditya Gupta wrote:
> Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
> symbol to get the current MMU type on PowerPC64.
>
> The disadvantage with this approach was that it depends on bit '0x40'
> ('MMU_FTR_TYPE_RADIX') being
Hello Hari,
Build failure detected.
On 13/02/24 17:01, Hari Bathini wrote:
Remove CONFIG_CRASH_DUMP dependency on CONFIG_KEXEC. CONFIG_KEXEC_CORE
was used at places where CONFIG_CRASH_DUMP or CONFIG_CRASH_RESERVE was
appropriate. Replace with appropriate #ifdefs to support CONFIG_KEXEC
and
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be
On 23/02/24 2:59 am, Andrew Morton wrote:
On Thu, 22 Feb 2024 10:47:29 +0530 Hari Bathini wrote:
On 22/02/24 2:27 am, Andrew Morton wrote:
On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini wrote:
On 04/02/24 8:56 am, Baoquan He wrote:
Hope Hari and Pingfan can help have a look, see if
On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> TDX guests are not allowed to clear CR4.MCE. Attempt to clear it leads
> to #VE.
>
> Use alternatives to keep the flag during kexec for TDX guests.
>
> The change doesn't affect non-TDX-guest environments.
>
> Signed-off-by: Kirill A.
On Thu, 22 Feb 2024 10:47:29 +0530 Hari Bathini wrote:
>
>
> On 22/02/24 2:27 am, Andrew Morton wrote:
> > On Wed, 21 Feb 2024 11:15:00 +0530 Hari Bathini
> > wrote:
> >
> >> On 04/02/24 8:56 am, Baoquan He wrote:
> > Hope Hari and Pingfan can help have a look, see if
> > it's
On 2/15/24 12:08 AM, Ard Biesheuvel wrote:
On Wed, 14 Feb 2024 at 23:31, Ross Philipson wrote:
Introduce the Secure Launch Resource Table which forms the formal
interface between the pre and post launch code.
Signed-off-by: Ross Philipson
---
include/linux/slr_table.h | 270
> > @@ -176,6 +195,19 @@ int ima_add_template_entry(struct ima_template_entry
> > *entry, int violation,
> > }
> > }
> >
> > + /*
> > +* suspend_ima_measurements will be set if the system is
> > +* undergoing kexec soft boot to a new kernel.
> > +* suspending
On 02/22/24 at 04:04pm, Kirill A. Shutemov wrote:
> On Thu, Feb 22, 2024 at 07:01:41PM +0800, Baoquan He wrote:
> > On 02/21/24 at 04:15pm, Kirill A. Shutemov wrote:
> > > On Wed, Feb 21, 2024 at 10:37:29AM +0800, Baoquan He wrote:
> > > > > diff --git a/arch/x86/mm/pat/set_memory.c
> > > > >
Hi Tushar,
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> New measurements added to the IMA log while the log is being copied
> during the kexec 'execute' may not get copied over.
As long as there is enough memory for the additional records, isn't the problem
"after" copying the
Hi Tushar,
On Wed, 2024-02-14 at 07:38 -0800, Tushar Sugandhi wrote:
> The extra memory allocated for carrying the IMA measurement list across
> kexec is hard-coded as half a PAGE. Make it configurable.
>
> Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
> extra memory (in
On Thu, Feb 22, 2024 at 07:01:41PM +0800, Baoquan He wrote:
> On 02/21/24 at 04:15pm, Kirill A. Shutemov wrote:
> > On Wed, Feb 21, 2024 at 10:37:29AM +0800, Baoquan He wrote:
> > > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > > > index 3612e3167147..425ff6e192e6
On 2/22/24 04:50, Kirill A. Shutemov wrote:
On Wed, Feb 21, 2024 at 02:35:13PM -0600, Tom Lendacky wrote:
@@ -906,6 +917,206 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t end)
set_pages_state(vaddr, npages, SNP_PAGE_STATE_PRIVATE);
}
+static inline bool pte_decrypted(pte_t
On 2/15/24 03:40, Ard Biesheuvel wrote:
On Wed, 14 Feb 2024 at 23:32, Ross Philipson wrote:
From: "Daniel P. Smith"
The Secure Launch platform module is a late init module. During the
init call, the TPM event log is read and measurements taken in the
early boot stub code are located. These
On 22/02/2024 9:34 am, Ard Biesheuvel wrote:
> On Thu, 22 Feb 2024 at 04:05, Andrew Cooper wrote:
>> On 15/02/2024 8:17 am, Ard Biesheuvel wrote:
>>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson
>>> wrote:
From: "Daniel P. Smith"
The SHA algorithms are necessary to measure
On 02/21/24 at 04:15pm, Kirill A. Shutemov wrote:
> On Wed, Feb 21, 2024 at 10:37:29AM +0800, Baoquan He wrote:
> > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > > index 3612e3167147..425ff6e192e6 100644
> > > --- a/arch/x86/mm/pat/set_memory.c
> > > +++
On Wed, Feb 21, 2024 at 02:35:13PM -0600, Tom Lendacky wrote:
> > @@ -906,6 +917,206 @@ void snp_accept_memory(phys_addr_t start, phys_addr_t
> > end)
> > set_pages_state(vaddr, npages, SNP_PAGE_STATE_PRIVATE);
> > }
> > +static inline bool pte_decrypted(pte_t pte)
> > +{
> > + return
On Thu, 22 Feb 2024 at 04:05, Andrew Cooper wrote:
>
> On 15/02/2024 8:17 am, Ard Biesheuvel wrote:
> > On Wed, 14 Feb 2024 at 23:31, Ross Philipson
> > wrote:
> >> From: "Daniel P. Smith"
> >>
> >> The SHA algorithms are necessary to measure configuration information into
> >> the TPM as
At 2024-02-22 15:45:38, "Baoquan He" wrote:
>On 02/20/24 at 10:11am, yang.zhang wrote:
>> From: "yang.zhang"
>>
>> When load segments, all of the copying and the rest
>> only happens before uchunk goes to zero.
>
>The code change looks good, while the log can be improved with more
>details so
From: "yang.zhang"
When loading segments, ubytes is <= mbytes. When ubytes is exhausted,
there could be remaining mbytes. Then in the while loop, the buf pointer
advancing with mchunk will causing meaningless reading even though it
doesn't harm.
So let's change to make sure that all of the
Hello,
I would like to reach out to the decision-maker in the IT environment within
your company.
We are a well-established digital agency in the European market. Our solutions
eliminate the need to build and maintain in-house IT and programming
departments, hire interface designers, or
21 matches
Mail list logo
