From: David Woodhouse
There's no need to swap pages (which involves three memcopies for each
page) in the plain kexec case. Just do a single copy from source to
destination page.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 4
1 file changed, 4 insertions(+)
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 110 +++
1 file changed, 110 insertions(+)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 2af4ce593645..2a2a6e693e18 100644
-
Page faults in relocate_kernel() are extremely painful to debug. Provide a
basic exception handler which will just dump the exception information and
registers to a serial port.
It's disabled by default and has to be enabled with #define DEBUG.
While I was at it, I also stopped swap_pages from ac
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 1c18cffe5229..bba37db6d437 100644
--- a/arch/x86/kernel/reloca
From: David Woodhouse
There are some failure modes which lead to triple-faults in the
relocate_kernel function, which is fairly much undebuggable for normal
mortals.
Adding a GDT in the relocate_kernel environment is step 1 towards being
able to catch faults and do something more useful.
Signed
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 80 ++--
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocate_kernel_64.S
index 2a2a6e693e18..1c18cf
From: David Woodhouse
Add more comments explaining what each register contains, and save the
preserve_context flag to a non-clobbered register sooner, to keep things
simpler.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 17 +
1 file changed, 13 inse
From: David Woodhouse
Make the code a little more readable.
Signed-off-by: David Woodhouse
---
arch/x86/kernel/relocate_kernel_64.S | 30 ++--
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/relocate_kernel_64.S
b/arch/x86/kernel/relocat
On Sat, 2024-11-02 at 10:53 -0400, Daniel P. Smith wrote:
> Hi Luto,
>
> My apologies, I missed this response and the active on v11 cause me
> to
> get an inquiry why I hadn't responded.
>
> On 9/21/24 18:40, Andy Lutomirski wrote:
[...]
> > I assumed that "deliberately cap" meant that there was
Hi Luto,
My apologies, I missed this response and the active on v11 cause me to
get an inquiry why I hadn't responded.
On 9/21/24 18:40, Andy Lutomirski wrote:
On Sat, Sep 21, 2024 at 11:37 AM Daniel P. Smith
wrote:
On 9/13/24 23:57, Andy Lutomirski wrote:
On Thu, Sep 12, 2024 at 5:34 PM
On Sat Nov 2, 2024 at 3:39 PM EET, Jarkko Sakkinen wrote:
> int tpm_chip_set_locality(struct tpm_chip *chip, u8 locality)
> {
> int ret;
>
> if (locality >= TPM_MAX_LOCALITY)
> return false;
>
> ret = tpm_try_get_ops(chip);
> if (ret)
> return ret
On Fri Sep 13, 2024 at 11:05 PM EEST, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> The function tpm_tis_request_locality() is expected to return the locality
> value that was requested, or a negative error code upon failure. If it is
> called
> while locality_count of struct tis_data is no
On Fri Sep 13, 2024 at 11:05 PM EEST, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> When tis_tis_core initializes, it assumes all localities are closed. There
> are cases when this may not be the case. This commit addresses this by
> ensuring all localities are closed before initializing beg
On Sat Nov 2, 2024 at 12:52 PM EET, Ard Biesheuvel wrote:
> > Short answer: I have no idea. I would not mind that but neither
> > the commit message for TPM give a clue on this. Actually, I *do
> > not care* if it is RO and RW but I'm neither good at guessing
> > random shit.
> >
>
> You were cc'ed
On Sat, Nov 02, 2024 at 08:23:33AM +0800, Baoquan He wrote:
> Yeah, it should be added to stable. Distros may get both SME/IMA set not
> as early as the bug introduced, while anyone doing so in an earlier kernel
> will see the problem.
Ok, I'll take your 2/2 next week and you can then send the cle
On Sat, 2 Nov 2024 at 11:38, Jarkko Sakkinen wrote:
>
> On Sat Nov 2, 2024 at 11:02 AM EET, Ard Biesheuvel wrote:
> > Same for the ioctl() [as well as the read-write sysfs node]: looking
> > at the code (patch 19/20) it doesn't seem like user space needs to be
> > able to modify this at all, at le
On Sat Nov 2, 2024 at 12:38 PM EET, Jarkko Sakkinen wrote:
> On Sat Nov 2, 2024 at 11:02 AM EET, Ard Biesheuvel wrote:
> > Same for the ioctl() [as well as the read-write sysfs node]: looking
> > at the code (patch 19/20) it doesn't seem like user space needs to be
> > able to modify this at all, a
On Sat Nov 2, 2024 at 11:02 AM EET, Ard Biesheuvel wrote:
> Same for the ioctl() [as well as the read-write sysfs node]: looking
> at the code (patch 19/20) it doesn't seem like user space needs to be
> able to modify this at all, at least not for the patch set as
> presented. So for now, can we ju
On Sat, 2 Nov 2024 at 07:29, Jarkko Sakkinen wrote:
>
> On Sat Nov 2, 2024 at 8:22 AM EET, Jarkko Sakkinen wrote:
> > DRTM needs to be able to set the locality used by kernel. Provide
> > TPM_IOC_SET_LOCALITY operation for this purpose. It is enabled only if
> > the kernel command-line has 'tpm.se
19 matches
Mail list logo
