Re: [PATCH v5 0/4] arch/x86: Remove unnecessary dependencies on bootparam.h

On Mon, Jan 15, 2024 at 11:55:36AM +0100, Ard Biesheuvel wrote: > But please be aware that we are in the middle of the merge window Yes, and the merge window has been suspended too: https://lore.kernel.org/r/CAHk-=wjmwpmxtkein__vnno4tcttzr-8dvvd_obq%2bhjessw...@mail.gmail.com > right now, and I

Re: [RFC PATCH v2 0/9] Use ERST for persistent storage of MCE and APEI errors

On Sat, Oct 07, 2023 at 03:15:45PM +0800, Shuai Xue wrote: > So, IMHO, it's better to add a way to retrieve MCE records through switching > to the new generation rasdaemon solution. rasdaemon already collects errors and even saves them in a database of sorts. No kernel changes needed. > Sorry

Re: [RFC PATCH v2 0/9] Use ERST for persistent storage of MCE and APEI errors

On Mon, Sep 25, 2023 at 03:44:17PM +0800, Shuai Xue wrote: > After /dev/mcelog character device deprecated by commit 5de97c9f6d85 > ("x86/mce: Factor out and deprecate the /dev/mcelog driver"), the > serialized MCE error record, of previous boot in persistent storage is not > collected via APEI

Re: [PATCH v4] x86, efi: never relocate kernel below lowest acceptable address

On Tue, Oct 22, 2019 at 08:13:56AM +0200, Ard Biesheuvel wrote: > On Thu, 17 Oct 2019 at 11:30, Kairui Song wrote: > > > > Currently, kernel fails to boot on some HyperV VMs when using EFI. > > And it's a potential issue on all platforms. > > > > It's caused by broken kernel relocation on EFI

Re: [PATCH v3] x86, efi: never relocate kernel below lowest acceptable address

On Wed, Oct 16, 2019 at 08:23:56AM -0700, Joe Perches wrote: > ? examples please. >From this very thread: \sEfi\s, \sefi\s, \seFI\s etc should be "EFI" I'm thinking perhaps start conservatively and catch the most often misspelled ones in commit messages or comments. "CPU", "SMT", "MCE", "MCA",

Re: [PATCH v3] x86, efi: never relocate kernel below lowest acceptable address

On Mon, Oct 14, 2019 at 11:21:11PM +0300, Jarkko Sakkinen wrote: > Was there a section in the patch submission documentation to point out > when people send patches with all the possible twists for an acronym? I don't think so. > This is giving me constantly gray hairs with TPM patches. Well,

Re: [PATCH v3] x86, efi: never relocate kernel below lowest acceptable address

On Sat, Oct 12, 2019 at 11:44:21AM +0800, Kairui Song wrote: > Currently, kernel fails to boot on some HyperV VMs when using EFI. > And it's a potential issue on all platforms. > > It's caused a broken kernel relocation on EFI systems, when below three > conditions are met: > > 1. Kernel image

Re: [PATCH v2] x86, efi: never relocate kernel below lowest acceptable address

On Fri, Sep 20, 2019 at 12:05:21AM +0800, Kairui Song wrote: > Currently, kernel fails to boot on some HyperV VMs when using EFI. > And it's a potential issue on all platforms. > > It's caused a broken kernel relocation on EFI systems, when below three > conditions are met: > > 1. Kernel image

Re: [PATCH v2 0/2] Fix crash in cper_estatus_check()

On Tue, Feb 19, 2019 at 11:00:49AM +0100, Rafael J. Wysocki wrote: > Boris, any comments here? For both: Acked-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Tue, Feb 05, 2019 at 10:05:16AM -0500, Masayoshi Mizuma wrote: > From: Masayoshi Mizuma > Date: Tue, 5 Feb 2019 10:00:59 -0500 > Subject: [PATCH] x86/mm: Introduce adjustment the padding size for KASLR "Adjust the padding size for KASLR" > If the physical memory

Re: [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block

On Tue, Jan 22, 2019 at 04:09:12PM +, Ross Lagerwall wrote: > When checking a generic status block, we iterate over all the generic > data blocks. The loop condition only checks that the start of the > generic data block is valid (within estatus->data_length) but not the > whole block. Because

Re: [PATCH efi-urgent] Revert "efi: Align 'efi_guid_t' to 64 bits"

arguments since UEFI's view > of the type has implicit 32-bit alignment. > > Let's sort this out for the next release, and revert the change > for now. > > Fixes: 793423cf07e5 ("efi: Align 'efi_guid_t' to 64 bits") > Reported-by: Heinrich Schuchardt > Cc: Ingo Molnar &g

Re: [PATCH 1/2 v8] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'

On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote: > I have noticed the changes on x86, but for IA64, i'm not sure whether it > should do the same > thing, so keep it as before. > > If IA64 people would like to give any comment, that will be appreciated. I think you should not touch ia64

Re: [tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Mon, Dec 03, 2018 at 11:08:41PM +0100, Borislav Petkov wrote: > On Mon, Dec 03, 2018 at 10:12:19PM +0100, Ard Biesheuvel wrote: > > > + * Using the FPU in hardirq is not allowed. > > > > According to the documentation in x86/kernel/fpu/core.c, this is not > >

Re: [tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Mon, Dec 03, 2018 at 10:12:19PM +0100, Ard Biesheuvel wrote: > > + * Using the FPU in hardirq is not allowed. > > According to the documentation in x86/kernel/fpu/core.c, this is not > true. So which one is accurate? I think you mean the irq from user mode... Yap, we do allow that.

Re: [PATCH 0/2 RESEND v7] add reserved e820 ranges to the kdump kernel e820 table

On Mon, Nov 26, 2018 at 09:44:46AM -0800, Dave Hansen wrote: > 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

Re: [PATCH v11 5/5] x86/boot/KASLR: Walk srat tables to filter immovable memory

Subject: Re: [PATCH v11 5/5] x86/boot/KASLR: Walk srat tables to filter immovable memory s/srat/SRAT/g On Mon, Nov 12, 2018 at 05:46:45PM +0800, Chao Fan wrote: > KASLR may randomly chooses some positions which are located in movable choose > memory regions. This will

Re: [PATCH v11 4/5] x86/boot: Dig out SRAT table from RSDP and find immovable memory

On Mon, Nov 12, 2018 at 05:46:44PM +0800, Chao Fan wrote: > To avoid KASLR extracting kernel on movable memory, slove the ^ Please introduce a spellchecker into your patch creation workflow. > conflict between KASLR and movable_node

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Wed, Nov 14, 2018 at 09:54:50AM +0800, Chao Fan wrote: > CONFIG_KEXEC is only needed in this function. > > When searching RSDP, there are three methods in order: > 1. When booting from KEXEC, 'acpi_rsdp' is added to cmdline by KEXEC, >so it can be parsed and used. CONFIG_KEXEC is needed

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Wed, Nov 14, 2018 at 02:12:16PM +0800, Chao Fan wrote: > But isdigit() would be redefine, so: > > diff --git a/include/linux/ctype.h b/include/linux/ctype.h > index 363b004426db..aba01c385232 100644 > --- a/include/linux/ctype.h > +++ b/include/linux/ctype.h > @@ -23,10 +23,12 @@ extern const

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Tue, Nov 13, 2018 at 03:06:16PM -0500, Masayoshi Mizuma wrote: > I just felt the BOOT_STRING thing in lib/kstrtox.c confuses... > I'm OK for now if it's applied your below comment. Well, actually, upon a second look, I don't think that including a .c file into a header is ok: diff --git

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Tue, Nov 13, 2018 at 11:11:11AM -0500, Masayoshi Mizuma wrote: > I think it's not very good idea to use kstrtoull() in > arch/x86/boot/compressed/* because some tricks are needed to > use the function, looks like Chao is trying... Ok, I had a look at the patch. And frankly, I don't see

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Mon, Nov 12, 2018 at 05:46:43PM +0800, Chao Fan wrote: > Imitate setup_acpi_rsdp() for the early_param of 'acpi_rsdp'. > KEXEC writes the RSDP pointer to cmdline for EFI booting. > So if 'acpi_rsdp' found in cmdline, use it directely. > > Since function kstrtoull() is needed, include it in >

Re: [PATCH v11 3/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdlien from kexec

On Tue, Nov 13, 2018 at 11:11:11AM -0500, Masayoshi Mizuma wrote: > I know checkpatch.pl says an warning about simple_strtoull(), > however, I believe the warning is for simple_strtoull() defined > in lib/vsprintf.c. simple_strtoull is deprecated for various reasons. I'll take a look at Chao's

Re: [PATCH v11 2/5] x86/boot: Add bios_get_rsdp_addr() to search RSDP in memory

On Tue, Nov 13, 2018 at 10:10:16AM +0800, Chao Fan wrote: > The 'rover' was named as 'mem_rover', but the length of this line is too > long. So shorten it as 'rever' so that they can keep in one line. I still have no clue what "rover" or "rever" means... > This name came from ACPI driver code,

Re: [PATCH v11 2/5] x86/boot: Add bios_get_rsdp_addr() to search RSDP in memory

On Mon, Nov 12, 2018 at 05:46:42PM +0800, Chao Fan wrote: > Imitate ACPI code to search RSDP pointer from memory. > Walk memory and check the signature until get the RSDP signature. > Based on acpi_tb_scan_memory_for_rsdp() and acpi_find_root_pointer(). > If didn't get RSDP from EFI table, will

Re: [PATCH v11 1/5] x86/boot: Add efi_get_rsdp_addr() to dig out RSDP from EFI table

On Mon, Nov 12, 2018 at 05:46:41PM +0800, Chao Fan wrote: > In order to parse SRAT table and get memory information, RSDP pointer > should be found. In kernel, there are three methods to get RSDP: > EFI condition, BIOS condition and KEXEC condition. The first works > for EFI condition.

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Thu, Nov 08, 2018 at 11:51:29AM +0100, Borislav Petkov wrote: > A global definition which doesn't need allocation? > > Maybe hpa would have another, better idea... ...and he has: just put that address in a new field in struct boot_params by converting one of the padding arrays ther

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Tue, Nov 06, 2018 at 05:21:34PM -0500, Masayoshi Mizuma wrote: > On Tue, Nov 06, 2018 at 09:45:11PM +0100, Borislav Petkov wrote: > > On Tue, Nov 06, 2018 at 02:36:38PM -0500, Masayoshi Mizuma wrote: > > > Yes, I think I can see what you are saying. However, I'm not su

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Tue, Nov 06, 2018 at 02:36:38PM -0500, Masayoshi Mizuma wrote: > Yes, I think I can see what you are saying. However, I'm not sure how > I use the setup_data in legacy BIOS environment. What is "legacy BIOS environment" and what does that have to do with setup_data? -- Regards/Gruss,

Re: [PATCH v10 2/7] x86/boot: Copy kstrtoull() to compressed period

On Mon, Oct 22, 2018 at 05:37:15PM +0800, Chao Fan wrote: > kstrtoull() lives in 'uncompressed' period, used to > convert a string to an unsigned long long. > Copy to 'compressed' so that we can use it to > convert the memory address from sting to unsigned sting? > long long in 'compressed'

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Thu, Oct 25, 2018 at 09:40:51AM -0400, Masayoshi Mizuma wrote: > I have another idea to solve this issue. Adding a SRAT parsing code > to arch/x86/mm/kaslr.c. It is useful for both EFI and BIOS and > also we don't need a new kernel parameter... > Dose the idea make sense? Ok, having swapped

Re: [PATCH v10 1/7] x86/boot: Introduce cmdline_find_option_arg()to detect if option=arg in cmdline

On Mon, Oct 22, 2018 at 05:37:14PM +0800, Chao Fan wrote: > Now, there are cmdline_find_option() and cmdline_find_option_bool() in > cmdline.c. Sometimes, when detecting such as whether 'acpi=off' is > in cmdline, we need to cmdline_find_option() first, then compare > the argument. Now splite the

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Thu, Oct 25, 2018 at 09:40:51AM -0400, Masayoshi Mizuma wrote: > My actual use case is for EFI boxes, however, I think it's better to useful > for legacy BIOS as well because memory hot-plug affinity in SRAT and KASLR > are available on legacy BIOS. > Actually, we can create such environment in

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Mon, Oct 22, 2018 at 11:42:05AM -0400, Masayoshi Mizuma wrote: > I'm trying to store the SRAT info and pass it to kernel_randomize_memory(), > looks like add_e820ext()/parse_setup_data(). > > Is the approach useful only EFI environment? I'm not sure how I Does it matter for non-EFI even? I

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Tue, Oct 16, 2018 at 03:54:30PM -0400, Masayoshi Mizuma wrote: > Ah, sorry, I misunderstood your suggetion... > In parse_setup_data(), the data is picked up from boot_params, Yes, this is the pointer to the setup_data linked list head. See Documentation/ABI/testing/sysfs-kernel-boot_params

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Tue, Oct 16, 2018 at 11:13:54AM -0400, Masayoshi Mizuma wrote: > Hi Boris, Baoquan and all, > > I have created a RFC patch for adjust KASLR padding size. > This patch is based on Can's v8 patch [1/3], and the Can's patch > will be changed in the future, so this patch is just RFC. > > Welcome

Re: [PATCH v8 1/3] x86/boot: Add acpitb.c to parse acpi tables

On Tue, Oct 16, 2018 at 10:48:44AM +0800, Chao Fan wrote: > Sorry for disturbing you again, I want to make sure this detail with you. > You mean that I need splite this as a function and put it to > cmdline.c, right? Extract that functionality into a generic helper so that handle_mem_options()

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Sat, Oct 13, 2018 at 05:45:51PM -0400, Masayoshi Mizuma wrote: > Yes, but I think we need to arrange the Chao's SRAT parsing to be used > from kernel_randomize_memory() because Chao's approach needs the SRAT > parsing before extract kernel and the padding size calculation needs > the parsing in

Re: [PATCH v8 1/3] x86/boot: Add acpitb.c to parse acpi tables

On Fri, Oct 12, 2018 at 05:36:38PM +0800, Chao Fan wrote: > Prefer to compile out entire functions, rather than portions of functions or > portions of expressions. Rather than putting an ifdef in an expression, > factor > out part or all of the expression into a separate helper function and

Re: [PATCH v8 1/3] x86/boot: Add acpitb.c to parse acpi tables

On Wed, Oct 10, 2018 at 04:41:17PM +0800, Chao Fan wrote: > There is a bug that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature and make the movable memory chosen by KASLR can't be > removed. So dig SRAT table from

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote: > In the earliest time, I tried to dig ACPI tabls to solve this problem. > But I didn't splite the code in 'compressed/' and ACPI code, so the patch > is hard to follow so refused by community. > Somebody suggest to add a kernel parameter

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Wed, Oct 10, 2018 at 11:14:26AM +0200, Thomas Gleixner wrote: > Yes, it's different, but if the SRAT information is available early, then > the command line parameter can go away because then the required > information for Masa's problem is available as well. Exactly. And I'd prefer we delayed

Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory

On Wed, Oct 10, 2018 at 04:41:16PM +0800, Chao Fan wrote: > ***Background: > People reported that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature and make the movable memory chosen by KASLR can't be > removed. > >

Re: [PATCH V2 2/6] x86/efi: Remove __init attribute from memory mapping functions

On Mon, Sep 03, 2018 at 05:03:56AM +, Prakhya, Sai Praneeth wrote: > Hmm.. thought that __efi_init might be confusing with the normal __init > attribute How would that be confusing? It has "__efi" prepended?! All I'm saying is, if you're going to define your own function attributes, do them

Re: [PATCH V2 2/6] x86/efi: Remove __init attribute from memory mapping functions

On Sun, Sep 02, 2018 at 02:46:30AM -0700, Sai Praneeth Prakhya wrote: > In order to not keep these functions needlessly when > "CONFIG_EFI_WARN_ON_ILLEGAL_ACCESS" is not selected, add a new > __efi_init_fixup attribute whose value changes based on whether the Why not just __efi_init{,data} ? --

Re: [PATCH] x86/efi: Access EFI MMIO data as unencrypted when SEV is active

On Tue, Jul 03, 2018 at 04:16:57PM -0500, Brijesh Singh wrote: > I agree with Ard,  it may be good idea to extend the UEFI spec to > include encryption information. Having this information may be helpful > in some cases, e.g if we ever need to map a specific non IO memory as > unencrypted. So far

Re: [PATCH] x86/efi: Access EFI MMIO data as unencrypted when SEV is active

(dropping stable@ as this is not how you send patches to stable). On Tue, Jul 03, 2018 at 05:37:18PM +0200, Ard Biesheuvel wrote: > On 3 July 2018 at 15:32, Brijesh Singh wrote: > > SEV guest fails to update the UEFI runtime variables stored in the > > flash. commit 1379edd59673 ("x86/efi:

[PATCH] efi/cper: Remove the INDENT_SP silliness

From: Borislav Petkov <b...@suse.de> A separate define just to print a space character is silly and completely unneeded. Remove it. Signed-off-by: Borislav Petkov <b...@suse.de> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: linux-efi@vger.kernel.org --- drivers/firmware/

Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info Structure

ers/firmware/efi/cper-x86.c > index 863f0cd2a0ff..a9ab3bbf7986 100644 > --- a/drivers/firmware/efi/cper-x86.c > +++ b/drivers/firmware/efi/cper-x86.c > @@ -3,15 +3,28 @@ > > #include > > +#define INDENT_SP" " There's that thing again. So it was a tota

Re: [PATCH v3 2/8] efi: Decode IA32/X64 Processor Error Section

On Sat, Mar 24, 2018 at 01:49:34PM -0500, Yazen Ghannam wrote: > From: Yazen Ghannam > > Recognize the IA32/X64 Processor Error Section. > > Do the section decoding in a new "cper-x86.c" file and add this to the > Makefile depending on a new "UEFI_CPER_X86" config option.

Re: [PATCH v2 0/8] Decode IA32/X64 CPER

On Fri, Mar 23, 2018 at 12:19:20AM +, Ghannam, Yazen wrote: > Is it alright if I go ahead and just send the v3 of this set without the MCA > decoding? Sure, but let's not drop the MCA decoding from the todo list. :) Thx. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Sat, Mar 10, 2018 at 12:33:35AM +, Prakhya, Sai Praneeth wrote: > Although the discussions were off my understanding, the present issue > I see is, (and also the motivation for me to do the patch is) when a > thread tries to execute any efi_runtime_service() we switch to efi_pgd > (which

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Fri, Mar 09, 2018 at 02:37:59AM +, Prakhya, Sai Praneeth wrote: > But, I guess, we have some downsides with this design: > 1. We are doing this to have "no exceptions to use efi_rts_wq", but we will > be making > the common case complicated. i.e. When a user requests to write some efi >

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Thu, Mar 08, 2018 at 05:05:44PM +, Luck, Tony wrote: > > "Hence, pstore calls efi_runtime_services() without using efi_rts_wq" - > > that doesn't sound like optimal design to me. I would try to shove them > > all through the workqueue - not have exceptions. > > But pstore is trying to save

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Thu, Mar 08, 2018 at 05:31:03AM +, Prakhya, Sai Praneeth wrote: > Another warning by checkpatch is "use of in_atomic() in drivers code" I'm assuming it warns because you're touching files in drivers/ but the efi fun is not really a driver... But looking at patch 3, that thing looks like a

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Mon, Mar 05, 2018 at 03:23:09PM -0800, Sai Praneeth Prakhya wrote: > +#define efi_queue_work(_rts, _arg1, _arg2, _arg3, _arg4, _arg5) > \ > +({ \ > + struct efi_runtime_work efi_rts_work;

Re: [PATCH v2 0/8] Decode IA32/X64 CPER

On Wed, Feb 28, 2018 at 08:58:15PM +, Ghannam, Yazen wrote: > 1) We keep this set mostly as-is. This would be our fallback if we don't have > anything better. Yes, sounds good. We try to decode it as MCE and if we cannot, we dump the raw CPER record. > 2) I add the MCA decoding to this set.

Re: [PATCH v2 0/8] Decode IA32/X64 CPER

On Wed, Feb 28, 2018 at 03:12:09PM +, Ghannam, Yazen wrote: > CPER is the format used for BERT, etc. We'll only ever see a CPER if the > firmware creates it. And it's up to firmware policy what is shared with > the OS. Yap, but we should still tie it into our infra. > My main reason for

Re: [PATCH v2 0/8] Decode IA32/X64 CPER

On Mon, Feb 26, 2018 at 01:38:56PM -0600, Yazen Ghannam wrote: > From: Yazen Ghannam > > This series adds decoding for the IA32/X64 Common Platform Error Record. One much more important thing I forgot about yesterday: how is this thing playing into our RAS reporting, x86

Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

On Tue, Feb 27, 2018 at 09:32:18PM +, Ghannam, Yazen wrote: > Not much more readable. It's still vague and confusing to a user and devoid > of any real info so an expert can't help. And now the information is printed > arbitrarily, so someone needs to read the source to figure out what it

Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

On Tue, Feb 27, 2018 at 06:40:13PM +, Ghannam, Yazen wrote: > Code readability. Bullshit! You can't tell me this: snprintf(newpfx, sizeof(newpfx), "%s ", pfx); is less readable than: snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP); > 1) No one except debug and

Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section

On Tue, Feb 27, 2018 at 06:06:21PM +, Ghannam, Yazen wrote: > It's not just about arches but record types. A single platform can report > using arch-specific records, memory records, PCIe records, etc. > > So all the other record types only show fields with a valid bit set and this > has

Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

On Tue, Feb 27, 2018 at 05:46:54PM +, Ghannam, Yazen wrote: > I think there's value in following the conventions in a subsystem. "conventions in a subsystem" my ass. That's brainless copy-pasting. It was added by f6edea77c8c8 ("ACPI, APEI, CPER: Cleanup CPER memory error output format")

Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section

On Tue, Feb 27, 2018 at 05:27:39PM +, Ghannam, Yazen wrote: > Sure, we can print the fields unconditionally if Ard is okay with that. > > The issue is that the x86 behavior will be different from all the others, so > that > might be confusing. Confusing for whom? Are we sharing tools with

Re: [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures

On Tue, Feb 27, 2018 at 03:33:44PM +, Ghannam, Yazen wrote: > I agree which is why I've included the Validation Bits. A user can then > check the Validation Bits for any field that is of interest but missing. No, no half-baked fields. So you know drivers/edac/mce_amd.c, right? And you know

Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

On Tue, Feb 27, 2018 at 03:25:06PM +, Ghannam, Yazen wrote: > This is the same as the other CPER code. Dude, turn on brain! So if it is in the other CPER code, we should copy it, no matter how dumb it is?!? > Also, the spec allows platform-defined GUIDs. So we should always print this >

Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section

On Tue, Feb 27, 2018 at 03:13:11PM +, Ghannam, Yazen wrote: > I decided to print the Validation Bits as a sanity check for whomever is > looking > at this. Since we only print fields with a valid bit, it may be confusing for > users > who don't know why fields are missing. I suggested what

Re: [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures

On Mon, Feb 26, 2018 at 01:39:01PM -0600, Yazen Ghannam wrote: > +static void print_err_info(const char *pfx, u8 err_type, u64 check) > +{ > + u16 validation_bits = CHECK_VALID_BITS(check); > + > + printk("%sValidation Bits: 0x%04x\n", pfx, validation_bits); > + > + if (err_type ==

Re: [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs

On Mon, Feb 26, 2018 at 01:39:00PM -0600, Yazen Ghannam wrote: > @@ -45,6 +81,11 @@ void cper_print_proc_ia(const char *pfx, const struct > cper_sec_proc_ia *proc) > printk("%sError Structure Type: %pUl\n", newpfx, > _info->err_type); > > +

Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

On Mon, Feb 26, 2018 at 01:38:59PM -0600, Yazen Ghannam wrote: > From: Yazen Ghannam > > Print the fields in the IA32/X64 Processor Error Info Structure. > > Based on UEFI 2.7 Table 256. IA32/X64 Processor Error Information > Structure. > > Signed-off-by: Yazen Ghannam

Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section

On Mon, Feb 26, 2018 at 01:38:58PM -0600, Yazen Ghannam wrote: > + * We don't need a "CPER_IA" prefix since these are all locally defined. > + * This will save us a lot of line space. > + */ > +#define VALID_LAPIC_ID BIT_ULL(0) > +#define VALID_CPUID_INFO

Re: [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition

On Mon, Feb 26, 2018 at 01:38:57PM -0600, Yazen Ghannam wrote: > From: Yazen Ghannam > > Based on UEFI 2.7 Table 255. Processor Error Record, the "Local APIC_ID" My pdf says this is table 252. > field is 8 bytes but Linux defines this field as 1 byte. > > Fix this in

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote: > We may see some other patches or RFCs about caching and/or shadowing > variable values in efivarfs to reduce the number of direct EFI reads, > with the goal of reducing how many SMIs are generated. So if you do the caching scheme, the

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote: > By your own reasoning above, that's a no-no as well. I'm sure we can come up with some emulation - the same way we did the BIOS emulation. > But thanks for your input. Anyone else got something constructive to > contribute? The

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

On Fri, Feb 16, 2018 at 10:41:45AM +, Ard Biesheuvel wrote: > On 15 February 2018 at 18:22, Joe Konno wrote: > > From: Joe Konno > > > > It was pointed out that normal, unprivileged users reading certain EFI > > variables (through efivarfs) can

Re: [Part1 PATCH v4 07/17] x86/efi: Access EFI data as encrypted when SEV is active

> Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Andy Lutomirski <l...@kernel.org> > Cc: Matt Fleming <m...@codeblueprint.co.uk&g

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

On Fri, Sep 15, 2017 at 09:48:53AM -0500, Brijesh Singh wrote: > I see the similar issue with non SEV guest with my simple patch below. > Guest will reboot as soon as it tries to enable the key. Can't do it there as the pagetable is not setup yet and you're probably getting a #PF on any of the

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

On Fri, Sep 15, 2017 at 09:13:00AM -0500, Brijesh Singh wrote: > thanks for the suggestion Boris, it will make patch much simpler. > I will try this out. It won't build - this was supposed to show the general idea. I need to figure out the include hell first. -- Regards/Gruss, Boris. SUSE

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Fri, Sep 01, 2017 at 05:52:13PM -0500, Brijesh Singh wrote: > So far, we have not seen the need for having such functions except > this cases. The approach we have right now works just fine and not > sure if its worth adding new functions. Then put the call to kvm_map_hv_shared_decrypted()

Re: [RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active

On Mon, Jul 24, 2017 at 02:07:57PM -0500, Brijesh Singh wrote: > The guest physical memory area holding the struct pvclock_wall_clock and > struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor > periodically updates the contents of the memory. When SEV is active, we > must

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: > I was trying to avoid mixing early and no-early set_memory_decrypted() but if > feedback is: use early_set_memory_decrypted() only if its required otherwise > use set_memory_decrypted() then I can improve the logic in next rev.

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

On Mon, Jul 24, 2017 at 02:07:56PM -0500, Brijesh Singh wrote: > Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU MSRs > variable at compile time and share its physical address with hypervisor. That sentence needs changing - the MSRs don't allocate -

Re: [RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot

On Mon, Jul 24, 2017 at 02:07:55PM -0500, Brijesh Singh wrote: > Some KVM-specific custom MSRs shares the guest physical address with s/shares/share/ > hypervisor. "the hypervisor." > When SEV is active, the shared physical address must be mapped > with encryption attribute cleared so that

Re: [RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

Btw, I don't see our SEV-specific chicken bit which disables SEV only. Do we need it? If so, maybe something like mem_encrypt=sme_only or so. Or is the mem_encrypt=off chicken bit enough? What about the use case where you want SME but no encrypted guests? A bunch of hmmm. --

Re: [RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

On Mon, Jul 24, 2017 at 02:07:54PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Early in the boot process, add checks to determine if the kernel is > running with Secure Encrypted Virtualization (SEV) active. > > Checking for SEV requires checking that the

Re: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

On Wed, Jul 26, 2017 at 03:07:14PM -0500, Brijesh Singh wrote: > Are you commenting on amount of code duplication ? If so, I can certainly > improve > and use the similar macro used into header file to generate the functions > body. So the argument about having CONFIG_AMD_MEM_ENCRYPT disabled

Re: [RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

On Mon, Jul 24, 2017 at 02:07:51PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order for memory pages to be properly mapped when SEV is active, we > need to use the PAGE_KERNEL protection attribute as the base protection. > This will insure that memory

Re: [RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

On Mon, Jul 24, 2017 at 02:07:49PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() > functions each have much of the same code. Create a new function that > consolidates the common code

Re: [RFC Part1 PATCH v3 08/17] x86/efi: Access EFI data as encrypted when SEV is active

On Mon, Jul 24, 2017 at 02:07:48PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > EFI data is encrypted when the kernel is run under SEV. Update the > page table references to be sure the EFI memory areas are accessed > encrypted. > > Signed-off-by: Tom Lendacky

Re: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The current code checks only for sme_active() when determining whether > to perform the encryption attribute change. Include sev_active() in this > check so that memory attribute

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

On Wed, Jul 26, 2017 at 11:47:32AM -0500, Tom Lendacky wrote: > If it's made static then the sme_active()/sev_active() inline functions > would need to be turned into functions within the mem_encrypt.c file. So > there's a trade-off to do that, which is the better one? Simple: why do we have

Re: [RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

On Mon, Jul 24, 2017 at 02:07:46PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When Secure Encrypted Virtualization (SEV) is active, boot data (such as > EFI related data, setup data) is encrypted and needs to be accessed as > such when mapped. Update the

Re: [RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

Subject: x86/realmode: ... On Mon, Jul 24, 2017 at 02:07:45PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the trampoline area will need to be in encrypted > memory so only mark the area decrypted if SME is active. > > Signed-off-by: Tom

Re: [RFC Part1 PATCH v3 04/17] x86/mm: Don't attempt to encrypt initrd under SEV

On Mon, Jul 24, 2017 at 02:07:44PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > When SEV is active the initrd/initramfs will already have already been > placed in memory encyrpted so do not try to encrypt it. > > Signed-off-by: Tom Lendacky

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 10:29:40AM -0500, Tom Lendacky wrote: > But early_identify_cpu() calls get_cpu_cap() which will check for cpuid > leaf 0x8008 support and set x86_phys_bits. Right, but it can't be less than 32, can it? And if it is more than 32 bits, then it probably doesn't really

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote: > True, but it is more about being accurate and making sure the value is > correct where ever it may be used. So early_identify_cpu() initializes phys_bits to 32 on 32-bit. Subtracting it there would actually make actively it wrong,

Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

On Mon, Jul 24, 2017 at 02:07:41PM -0500, Brijesh Singh wrote: Subject: Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption ^^

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote: > > If I make the scattered feature support conditional on CONFIG_X86_64 > > (based on comment below) then cpu_has() will always be false unless > > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the > > #ifdef. > > If

Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote: > Normally the __p4d() macro would be used and that would be ok whether > CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the > paravirt ops path I have to use native_make_p4d(). So __p4d is in !CONFIG_PARAVIRT path.

  1   2   3   4   5   >