On 04/18/2017 02:17 PM, Tom Lendacky wrote:
> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from,
> unsigned long vaddr,
> __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
>
> #ifndef __va
> -#define __va(x) ((void *)((unsigned
> long)(
On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> determine if SME is active.
>
> A new directory will be created:
> /sys/kernel/mm/sme/
>
> And two entries within the new directory:
> /sys/kernel/mm/sme/active
> /sys/ke
On 04/24/2017 08:53 AM, Tom Lendacky wrote:
> On 4/21/2017 4:52 PM, Dave Hansen wrote:
>> On 04/18/2017 02:17 PM, Tom Lendacky wrote:
>>> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void
>>> *from, unsigned long vaddr,
>>> __phys_addr_sym
On 04/27/2017 12:25 AM, Dave Young wrote:
> On 04/21/17 at 02:55pm, Dave Hansen wrote:
>> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>>>
>>>
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
> for the iomem resources search interfaces, and in order to make it still
> work after the new descriptor is added, these codes originally related
> to 'IORES_DESC_NONE' have been upd
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
> for the iomem resources search interfaces, and in order to make it still
> work after the new descriptor is added, these codes originally related
> to 'IORES_DESC_NONE' have been upd
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> The upstream kernel can not accurately add the e820 reserved type to> kdump
> krenel e820 table.
^ kernel
> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds
> the matched resource ranges to the e820 table for kdump kernel. But
On 11/27/18 2:04 AM, lijiang wrote:
> What happens if we don't modify this functions
> __ioremap_check_desc_other()? -When SEV is active, it might map these
> reserved regions with the encryption mask. That is incorrect.
This is missing another sentence or two to "connect the dots".
SEV uses dat
On 11/27/18 7:51 PM, lijiang wrote:
> But now, the 'E820_TYPE_RESERVED' type is converted to the descriptor
> 'IORES_DESC_RESERVED'
> instead of 'IORES_DESC_NONE', it has been changed and the value of
> 'mem_flags.desc_other'
> is equal to 'true'. This is wrong.
Thanks for the improved descripti
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
> On 04/12/2013 07:31 AM, Vivek Goyal wrote:
>>> I also have to admit that I don't see the difference between /dev/mem
>>> and /dev/oldmem, as the former allows access to memory ranges outside
>>> the ones used by the current kernel, which is what the o
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
> This sounds like there's no such issue on x86 cache mechanism. Is it
> correct? If so, what is the difference between ia64 and x86 cache
> mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
> /*
>
On Thu, 2011-10-27 at 09:30 +0200, Heiko Carstens wrote:
> > Are any events generated for memory add?
>
> Looks like uevents are only genereted when memory gets registered and
> unregistered, but not when when it gets set online or offline.
> To achieve that you would need to add similar code to
>
On Fri, 2011-10-28 at 15:41 -0700, Andrew Morton wrote:
> > + } else if (!strncmp(buf, "offline", min((int)count, 7))) {
> > ret = memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE);
> > -
> > + if (ret == 0)
> > + kobject_uevent(&dev->kobj, KO
On 5/30/22 01:40, Jonathan McDowell wrote:
> Borislav,
>
> I don't think there are any outstanding review comments for me to deal
> with on this, so is it safe to assume it'll get picked up at some point
> once the merge window calms down?
Nothing here looks too crazy, but it's still been _very_
... adding kexec folks
On 6/14/22 05:02, Kirill A. Shutemov wrote:
> On kexec, the target kernel has to know what memory has been accepted.
> Information in EFI map is out of date and cannot be used.
>
> boot_params.unaccepted_memory can be used to pass the bitmap between two
> kernels on kexec,
On 6/28/22 16:51, Kirill A. Shutemov wrote:
> On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote:
>>> If there is some deep and fundamental why this can not be supported
>>> then it probably makes sense to put some code in the arch_kexec_load
>>> hook that verifies that deep and fun
On 11/4/22 04:29, Coiby Xu wrote:
> + if (kexec_crash_image->luks_volume_key_addr) {
> + start = kexec_crash_image->luks_volume_key_addr;
> + end = start + kexec_crash_image->luks_volume_key_sz - 1;
> + page = pfn_to_page(start >> PAGE_SHIFT);
> +
On 1/3/23 19:21, Baoquan He wrote:
>> Since it cleans up the last arch specific version of
>> arch_kexec_kernel_image_load in x86, maybe this patchset can go into x86
>> branch?
> Could you consider picking this patchset into x86 branch? This is a
> clean up on kexec, while the last ARCH using it i
On 2/13/23 15:48, Kirill A. Shutemov wrote:
> The patch brings basic enabling of kexec in TDX guests.
>
> By "basic enabling" I mean, kexec in the guests with a single CPU.
> TDX guests use ACPI MADT MPWK to bring up secondary CPUs. The mechanism
> doesn't allow to put a CPU back offline if it has
On 2/16/23 10:12, Kirill A. Shutemov wrote:
> On Thu, Feb 16, 2023 at 09:50:32AM -0800, Dave Hansen wrote:
>> On 2/13/23 15:48, Kirill A. Shutemov wrote:
>>> The patch brings basic enabling of kexec in TDX guests.
>>>
>>> By "basic enabling" I mean,
On 2/24/23 06:30, Kirill A. Shutemov wrote:
> Ideally, it has to be addressed on BIOS level: it has to provide a way to
> offline CPUs, putting it back to pre-wakeup state.
Is there anything stopping us from just parking the CPUs in a loop
looking at 'acpi_mp_wake_mailbox_paddr'? Basically park t
On 3/25/23 09:01, Kirill A. Shutemov wrote:
> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
> secondary CPUs. The mechanism doesn't allow to put a CPU back offline if
> it has woken up.
...
> +int arch_kexec_load(void)
> +{
> + if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)
On 3/25/23 12:25, Kirill A. Shutemov wrote:
> On Sat, Mar 25, 2023 at 09:25:36AM -0700, Dave Hansen wrote:
>> On 3/25/23 09:01, Kirill A. Shutemov wrote:
>>> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
>>> secondary CPUs. The mechanism doesn't
On 3/25/23 09:01, Kirill A. Shutemov wrote:
> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
> secondary CPUs. The mechanism doesn't allow to put a CPU back offline if
> it has woken up.
I'm not sure I like this approach.
TDX uses the MADT exclusively.
MADT-based systems can'
On 9/6/23 00:39, Adrian Hunter wrote:
> Support for unaccepted memory was added recently, refer commit
> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
> a virtual machine may need to accept memory before it can be used.
>
> Do not map unaccepted memory because it can cause the gu
On 9/7/23 07:25, Kirill A. Shutemov wrote:
> On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
>> On 9/6/23 00:39, Adrian Hunter wrote:
>>> Support for unaccepted memory was added recently, refer commit
>>> dcdfdd40fa82 ("mm: Add support for unaccepted
On 9/7/23 07:46, Dave Hansen wrote:
> Can a line of code in this patch even run in the face of IO_STRICT_DEVMEM=y?
Gah, I meant plain old STRICT_DEVMEM=y.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listi
On 9/6/23 00:39, Adrian Hunter wrote:
> +static bool pfn_is_unaccepted_memory(unsigned long pfn)
> +{
> + phys_addr_t paddr = pfn << PAGE_SHIFT;
> +
> + return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE);
> +}
Please just add this as an inline helper to common code rather th
On 9/6/23 00:39, Adrian Hunter wrote:
> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct vm_area_struct
> *vma,
>* pages without a reason.
>*/
> idx = srcu_read_lock(&vmcore_cb_srcu);
> - if (!list_empty(&vmcore_cb_list))
> + if (!list_empty(&vmcore_cb_li
On 9/6/23 00:39, Adrian Hunter wrote:
> Do not map unaccepted memory because it can cause the guest to fail.
>
> For /proc/kcore, which is read-only and does not support mmap, this means a
> read of unaccepted memory will return zeros.
I'm confused by this changelog and subject.
What is getting
On 9/7/23 08:44, Adrian Hunter wrote:
> On 7/09/23 18:39, Dave Hansen wrote:
>> On 9/6/23 00:39, Adrian Hunter wrote:
>>> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct
>>> vm_area_struct *vma,
>>> * pages without a reason.
>
On 9/11/23 01:09, David Hildenbrand wrote:
> So, making unaccepted memory similarly depend on "!DEVMEM ||
> STRICT_DEVMEM" does not sound too far off ...
Yeah, considering all of the invasive work folks want to do to "harden"
the kernel for TDX, doing that ^ is just about the best
bang-for-your-bu
On 9/14/23 05:30, Kirill A. Shutemov wrote:
> +/*
> + * Total number of page table kernel_add_identity_map() can allocate,
> + * including page tables consumed by startup_32().
> + */
> +# define BOOT_PGT_SIZE (32*4096)
I agree that needing to know this in advance *exactly* is troubl
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
do a lot of hacking in the crashdump code, this seems
sane to me. As the perpetrator of the "System RAM (kmem)" trick:
Acked-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 9/13/21 8:55 AM, Joerg Roedel wrote:
> This does not work under SEV-ES, because the hypervisor has no access
> to the vCPU registers and can't make modifications to them. So an
> SEV-ES guest needs to reset the vCPU itself and park it using the
> AP-reset-hold protocol. Upon wakeup the guest nee
On 9/13/21 9:14 AM, Joerg Roedel wrote:
> On Mon, Sep 13, 2021 at 09:02:38AM -0700, Dave Hansen wrote:
>> On 9/13/21 8:55 AM, Joerg Roedel wrote:
>>> This does not work under SEV-ES, because the hypervisor has no access
>>> to the vCPU registers and can't make modi
On 2/16/22 19:54, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner. The first area of
> focus has been on the Trusted Computing Group's Dynamic Launch for
> establishing
> a har
On 9/27/23 09:13, Stanislav Kinsburskii wrote:
> Once deposited, these pages can't be accessed by Linux anymore and thus
> must be preserved in "used" state across kexec, as hypervisor state is
> unware of kexec.
If Linux can't access them, they're not RAM any more. I'd much rather
remove them fr
On 9/27/23 16:25, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 06:22:54AM -0700, Dave Hansen wrote:
>> On 9/27/23 09:13, Stanislav Kinsburskii wrote:
>>> Once deposited, these pages can't be accessed by Linux anymore and thus
>>> must be preserved
On 9/28/23 10:35, David Hildenbrand wrote:
> On 28.09.23 15:22, Dave Hansen wrote:
>> On 9/27/23 09:13, Stanislav Kinsburskii wrote:
>>> Once deposited, these pages can't be accessed by Linux anymore and thus
>>> must be preserved in "used" state across k
On 9/27/23 17:02, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 10:29:32AM -0700, Dave Hansen wrote:
...
> Well, not exactly. That's something I'd like to have indeed, but from my
> POV this goal is out of scope of discussion at the moment.
> Let me try to express i
On 9/27/23 17:38, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 11:00:12AM -0700, Dave Hansen wrote:
>> On 9/27/23 17:02, Stanislav Kinsburskii wrote:
>>> On Thu, Sep 28, 2023 at 10:29:32AM -0700, Dave Hansen wrote:
>> ...
>>> Well, not exactly. That&#x
ce to the bools.
Reviewed-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
he's:
Add one more entry into enum pg_level to indicate the size of the VA
covered by one PGD entry in 5-level paging mode.
With that fixed:
Reviewed-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 2/23/24 10:45, Dave Hansen wrote:
> Always filling out the level allows using lookup_address() to
> iterate over kernel page tables.
This doesn't parse very well. How about this instead:
Always filling out the level allows using lookup_address() to
pre
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> The kernel will convert all shared memory back to private during kexec.
> The direct mapping page tables will provide information on which memory
> is shared.
>
> It is extremely important to convert all shared memory. If a page is
> missed, it will ca
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> +static void tdx_kexec_stop_conversion(bool crash)
> +{
> + /* Stop new private<->shared conversions */
> + conversion_allowed = false;
> +
> + /*
> + * Make sure conversion_allowed is cleared before checking
> + * conversions_in_p
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> Despite the name, E820_TYPE_ACPI covers not only ACPI data, but also EFI
> tables and might be required by kernel to function properly.
Lovely. You learn something new every day.
Reviewed-by: Dave
On 2/25/24 07:54, Kirill A. Shutemov wrote:
> Serializing is cumbersome here. I can also just drop the interface.
Just drop it for now. We can come back after the fact and debate how to
do the debugging.
___
kexec mailing list
kexec@lists.infradead.org
On 2/25/24 06:58, Kirill A. Shutemov wrote:
> On Fri, Feb 23, 2024 at 11:39:07AM -0800, Dave Hansen wrote:
...
>> I'd really prefer we find a way to do this with actual locks, especially
>> 'conversion_allowed'.
>>
>> This is _awfully_ close to bei
On 4/24/24 07:35, Kirill A. Shutemov wrote:
>> Also, does this need to go to stable although it is kinda big for
>> stable. If stable, do we need a smaller fix first which is backportable?
> Correct me, if I am wrong, but I believe TDX guest is the only user of
> ACPI MADT wake up method. At least
On 6/4/24 08:32, Kirill A. Shutemov wrote:
> What about the comment below?
>
> /*
>* One possible reason for the failure is if kexec raced
>* with memory conversion. In this case shared bit in
>* page tab
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> Keep track of the number of shared pages. This will allow for
> cross-checking against the shared information in the direct mapping
> and reporting if the shared bit is lost.
It's probably also worth mentioning that conversions are slow and
relatively
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> + x86_platform.guest.enc_kexec_begin(true);
> + x86_platform.guest.enc_kexec_finish();
I really despise the random, unlabeled true/false/0/1 arguments to
functions like this.
I'll bring it up in the non-noop patch though.
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> +/* Stop new private<->shared conversions */
> +static void tdx_kexec_begin(bool crash)
> +{
> + /*
> + * Crash kernel reaches here with interrupts disabled: can't wait for
> + * conversions to finish.
> + *
> + * If race happene
On 6/5/24 05:43, Kirill A. Shutemov wrote:
> Okay fair enough. Check out the fixup below. Is it what you mean?
Yes. Much better.
> One other thing I realized is that these callback are dead code if kernel
> compiled without kexec support. Do we want them to be wrapped with
> #ifdef COFNIG_KEXEC_
On Tue, 2007-10-16 at 18:28 +0200, Bernhard Walle wrote:
>
> @@ -736,7 +736,7 @@ static int __init smp_scan_config (unsig
> smp_found_config = 1;
> printk(KERN_INFO "found SMP MP-table at %08lx\n",
> vi
On Tue, 2007-10-16 at 20:44 +0200, Bernhard Walle wrote:
> * Dave Hansen <[EMAIL PROTECTED]> [2007-10-16 20:08]:
> > On Tue, 2007-10-16 at 18:28 +0200, Bernhard Walle wrote:
> > >
> > > @@ -736,7 +736,7 @@ static int __init smp_scan_config (unsig
> > >
On Fri, 2008-06-27 at 13:12 +0200, Bernhard Walle wrote:
>
> This patch adds /sys/firmware/memmap interface that represents the
> BIOS
> (or Firmware) provided memory map. The tree looks like:
>
> /sys/firmware/memmap/0/start (hex number)
>end (hex number)
>
On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?
Heh, I'm catching up on this thread...
It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on variou
On 11/25/24 09:05, David Woodhouse wrote:
> Not sure I like this very much, but it works, and mirrors what
> arch/x86/boot/compressed/ident_map_64.c already does.
I don't like it much, either.
arch/x86/boot/compressed/ is already on the road to sharing no code with
the core kernel and it's full o
On 11/25/24 10:53, David Woodhouse wrote:
>> I think we have a lot of software-available space in the page table
>> pointer entries. What would folks think if we set a special bit in those
>> p4d entries that said:
>>
>> "I don't need to be propagated to
>> the user portion of the page ta
On 11/26/24 03:42, David Woodhouse wrote:
> I threw this version together and it didn't immediately explode...
It's better than playing #define games. The damage is also pretty
limited and it helps us avoid plumbing a bit through the page table
handling function arguments.
On 12/17/24 04:25, Kirill A. Shutemov wrote:
>> Clear the PGE bit in %cr4 early, before storing data in the control page.
> It worth noting that flipping CR4.PGE triggers TLB flush. I was not sure
> if CR3 write is required to make it happen.
I thought about removing the CR3 write. But I decided a
On 12/17/24 06:56, David Woodhouse wrote:
>> Anyway, I think we can leave the belt-and-suspenders programming in this
>> case. A comment wouldn't hurt I guess.
> I'm a little lost. In this case I don't see belt-and-suspenders
> programming. We're not loading CR3 after clearing CR4.PGE just to be
>
On 12/12/24 13:32, David Woodhouse wrote:
> On 12 December 2024 21:18:10 GMT, Dave Hansen wrote:
>> On 12/12/24 12:11, David Woodhouse wrote:
>>> From: David Woodhouse
>>>
>>> The virtual mapping of the control page may have been _PAGE_GLOBAL and
>>>
On 12/12/24 12:11, David Woodhouse wrote:
> From: David Woodhouse
>
> The virtual mapping of the control page may have been _PAGE_GLOBAL and
> thus its PTE might not have been flushed on the %cr3 switch and it might
> effectively still be read-only. Move the writes to it down into the
> identity_
On 4/10/25 22:37, Changyuan Lyu wrote:
> From: Alexander Graf
>
> We now have all bits in place to support KHO kexecs. This patch adds
Please use imperative voice and also avoid the "this patch" stuff.
...
> +/*
> + * If KHO is active, only process its scratch areas to ensure we are not
> + * s
ations, but it is essential for kexec handover (kho) to know how
> much memory kernel consumes during boot.
>
> Use memblock_reserve_kern() to reserve kernel memory, such as kernel image,
> initrd and setup data.
Acked-by: Dave Hansen
On 4/10/25 22:37, Changyuan Lyu wrote:
> When the actual kexec happens, the fdt is part of the image
> set that we boot into. In addition, we keep "scratch regions" available
> for kexec: physically contiguous memory regions that are guaranteed to
> not have any memory that KHO would preserve. The
have Reviewed-bys from some x86 maintainers. Dave
> Hansen, would you be the right person to take a look at this from an x86
> perspective?
It looks mostly OK.
The one worry is the scratch reservation sizing, how folks will get that
right, and the implications if they get it wrong. If it
On 4/28/25 17:04, Daniel P. Smith wrote:
>> OK, but why do this in Linux as opposed to tboot? Right now, much of the
>> TXT magic is done outside of the kernel. Why do it *IN* the kernel?
>
> There was a patch set submitted to tboot to add AMD support. It was
> rejected as tboot is solely focused
On 4/22/25 11:17, Andrew Cooper wrote:
> On 21/04/2025 9:52 pm, Dave Hansen wrote:
>> Purely from the amount of interest and review tags and the whole "v14"
>> thing, it doesn't look like this is very important to anyone. Not to be
>> to flippant about it, bu
tems that
> support KHO initialize, they introspect the KHO metadata, restore preserved
> memory regions, and retrieve their state stored in the preserved memory.
>
> Enlighten x86 kexec-file and boot path about the KHO metadata and make sure
> it gets passed along to the next kernel.
Acked-by: Dave Hansen
tion of the real-mode trampoline and a few (if any) other
> very early allocations from below 1M forcibly mark the memory below 1M
> as scratch.
>
> After real mode trampoline is allocated, clear that scratch marking.
It's much more clear now, thanks!
Acked-by: Dave Hansen
On 5/1/25 15:54, Changyuan Lyu wrote:
> KHO uses "scratch regions" to bootstrap a kexec'ed kernel. These regions are
> guaranteed to not have any memory that KHO would preserve.
I understand how these changelogs got written. They were written by
someone thinking *only* about KHO and hacking it int
On 5/2/25 14:16, Mike Rapoport wrote:
>>> +/*
>>> + * If KHO is active, only process its scratch areas to ensure we are not
>>> + * stepping onto preserved memory.
>>> + */
>>> +#ifdef CONFIG_KEXEC_HANDOVER
>>> +static bool process_kho_entries(unsigned long minimum, unsigned long
>>> image_size)
>
On 4/21/25 09:26, Ross Philipson wrote:
> This patchset provides detailed documentation of DRTM, the approach used for
> adding the capbility, and relevant API/ABI documentation. In addition to the
> documentation the patch set introduces Intel TXT support as the first platform
> for Linux Secure L
On 4/25/25 03:12, Rich Persaud wrote:
> On Apr 24, 2025, at 2:45 PM, Dave Hansen
> wrote:
>> On 4/21/25 09:26, Ross Philipson wrote:
>>> This patchset provides detailed documentation of DRTM, the
>>> approach used for adding the capbility, and relevant API/ABI
On 4/22/25 14:26, Ard Biesheuvel wrote:
> So if that is true (I'm not a x86 uarch expert by any measure), then
> pushing back on this series on the basis that it is ugly and intrusive
> is not really reasonable. From security pov, I think D-RTM is an
> important feature and it deserves to be upstre
On 4/29/25 08:53, Mike Rapoport wrote:
> On Mon, Apr 28, 2025 at 03:05:55PM -0700, Dave Hansen wrote:
>> On 4/10/25 22:37, Changyuan Lyu wrote:
>>> From: Alexander Graf
>>>
>>> +#ifdef CONFIG_KEXEC_HANDOVER
>>> +static bool process_kho_entries(unsigne
On 4/29/25 01:06, Mike Rapoport wrote:
> On Mon, Apr 28, 2025 at 03:05:55PM -0700, Dave Hansen wrote:
>> On 4/10/25 22:37, Changyuan Lyu wrote:
>>> From: Alexander Graf
>>>
>>> +/*
>>> + * If KHO is active, only process its scratch areas to ensure we a
On 4/21/25 09:26, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner.
Hey Folks,
It isn't immediately apparent what these 5,000 lines of code do which is
new, why they are import
On 4/21/25 09:27, Ross Philipson wrote:
> @@ -788,6 +790,9 @@ static void native_machine_halt(void)
>
> tboot_shutdown(TB_SHUTDOWN_HALT);
>
> + /* SEXIT done after machine_shutdown() to meet TXT requirements */
> + slaunch_finalize(1);
This is the kind of stuff that needs to get
On 4/21/25 09:27, Ross Philipson wrote:
> +static u64 sl_rdmsr(u32 reg)
> +{
> + u64 lo, hi;
> +
> + asm volatile ("rdmsr" : "=a" (lo), "=d" (hi) : "c" (reg));
> +
> + return (hi << 32) | lo;
> +}
Is there a reason this code doesn't just use boot_rdmsr()?
On 3/4/25 10:49, Eric W. Biederman wrote:
> How goes the work to fix this horrifically slow firmware interface?
The firmware interface isn't actually all that slow.
The fundamental requirement is that confidential computing environments
need to be handed memory in a known-benign state. For AMD SE
On 3/4/25 11:16, Dave Hansen wrote:
> On 3/4/25 10:49, Eric W. Biederman wrote:
>> How goes the work to fix this horrifically slow firmware interface?
> The firmware interface isn't actually all that slow.
Hey Eric,
I've noticed a trend on this series. It seems like e
On 1/13/25 06:59, Eric W. Biederman wrote:
...
> I have a new objection. I believe ``unaccepted memory'' and especially
> lazily initialized ``unaccepted memory'' is an information leak that
> could defeat the purpose of encrypted memory. For that reason I have
> Cc'd the security list. I don't
On 12/13/24 01:54, Yan Zhao wrote:
> + /*
> + * The destination addresses are searched from system RAM rather than
> + * being allocated from the buddy allocator, so they are not guaranteed
> + * to be accepted by the current kernel. Accept the destination
> + * addresses b
On 2/14/25 05:46, Kirill A. Shutemov wrote:
>> It sounds like you're advocating for the "slow guest boot" option.
>> Kirill, can you remind us how fast a guest boots to the shell for
>> modestly-sized (say 256GB) memory with "accept_memory=eager" versus
>> "accept_memory=lazy"? IIRC, it was a prett
we've got at least one end user[1] that
seems to think unaccepted memory fits their needs.
This bug can _probably_ be fixed in arch/x86 as well, but having the
solution in general code seems like the right place to me:
Acked-by: Dave Hansen
Andrew, it seems like a lot of kexec work flow
On 6/18/25 01:33, Mowka, Mateusz wrote:
> On 21-Apr-25 6:26 PM, Ross Philipson wrote:
>> From: "Daniel P. Smith"
>>
>> Introduce background, overview and configuration/ABI information
>> for the Secure Launch kernel feature.
>>
>> Signed-off-by: Daniel P. Smith
>> Signed-off-by: Ross Philipson
>
93 matches
Mail list logo
