Re: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

> Subject: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 > per ACPI 6.1 Use a verb in your patch subjects: "Add support for ..." or so. On Tue, Mar 28, 2017 at 01:30:32PM -0600, Tyler Baicar wrote: > Currently when a RAS error is reported it is not timestamped. What is a

Re: [PATCH V14 01/10] acpi: apei: read ack upon ghes record consumption

On Tue, Mar 28, 2017 at 01:30:31PM -0600, Tyler Baicar wrote: > A RAS (Reliability, Availability, Serviceability) controller > may be a separate processor running in parallel with OS > execution, and may generate error records for consumption by > the OS. If the RAS controller produces multiple

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Thu, Apr 06, 2017 at 01:37:41PM -0500, Brijesh Singh wrote: > I did thought about prot idea but ran into another corner case which may > require > us changing the signature of phys_pud_init and phys_pmd_init. The paddr_start > and paddr_end args into kernel_physical_mapping_init() should be

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

Hi Brijesh, On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote: > I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains > routines to do basic page splitting. I think it sufficient for our usage. Good :) > I should be able to drop the memblock patch from the

Re: [RFC PATCH v2 16/32] x86: kvm: Provide support to create Guest and HV shared per-CPU variables

On Wed, Mar 29, 2017 at 05:21:13PM +0200, Paolo Bonzini wrote: > The GHCB would have to be allocated much earlier, possibly even by > firmware depending on how things will be designed. How about a statically allocated page like we do with the early pagetable pages in head_64.S? > I think it's

Re: [RFC PATCH v2 18/32] kvm: svm: Use the hardware provided GPA instead of page walk

we won't know > which memory address was translated into EXITINFO2. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > Reviewed-by: Borislav Petkov <b...@suse.de> I think I already asked you to remove Revewed-by tags when you have to change an already reviewed

Re: [RFC PATCH v2 16/32] x86: kvm: Provide support to create Guest and HV shared per-CPU variables

On Thu, Mar 02, 2017 at 10:15:36AM -0500, Brijesh Singh wrote: > Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU > variable at compile time and share its physical address with hypervisor. > It presents a challege when SEV is active in guest OS. When SEV is active, > guest

Re: [RFC PATCH v2 15/32] x86: Add support for changing memory encryption attribute in early boot

On Thu, Mar 02, 2017 at 10:15:28AM -0500, Brijesh Singh wrote: > Some KVM-specific custom MSRs shares the guest physical address with > hypervisor. When SEV is active, the shared physical address must be mapped > with encryption attribute cleared so that both hypervsior and guest can > access the

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On Fri, Mar 24, 2017 at 09:42:40AM +, Ard Biesheuvel wrote: > That is a different matter. If the regions are only mapped while > runtime services invocations are in progress (as we do on ARM), I am > not sure if it matters that much, given how rarely that occurs in > normal use. Question is,

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On Fri, Mar 24, 2017 at 10:24:34AM +0100, Ingo Molnar wrote: > Preserving virtual addresses for kexec is a red herring: the randomized > offset > could be passed to the kexec-ed kernel just fine. Not only that - kexec'ed kernel gets the addresses from sysfs so we can randomize. --

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 17, 2017 at 03:45:26PM +0100, Paolo Bonzini wrote: > Yes, and I'd like that to be done with a new data section rather than a > special KVM hook. Can you give more details about how pls? Or is there already an example for that somewhere in the kvm code? > I have no idea. SEV-ES seems

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote: > If it is possible to do it in a fairly hypervisor-independent manner, > I'm all for it. That is, only by looking at AMD-specified CPUID leaves > and at kernel ELF sections. Not even that. What that needs to be able to do is:

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote: > The kvmclock memory is initially zero so there is no need for the > hypervisor to allocate anything; the point of these patches is just to > access the data in a natural way from Linux source code. I realize that. > I also don't

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote: > I can take a look at fixing those warning. In my initial attempt was to create > a new function to clear encryption bit but it ended up looking very similar to > __change_page_attr_set_clr() hence decided to extend the exiting

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Thu, Mar 16, 2017 at 11:11:26AM -0500, Tom Lendacky wrote: > Not quite. The guest still needs to understand about the encryption mask > so that it can protect memory by setting the encryption mask in the > pagetable entries. It can also decide when to share memory with the > hypervisor by not

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: > Because there are differences between how SME and SEV behave > (instruction fetches are always decrypted under SEV, DMA to an > encrypted location is not supported under SEV, etc.) we need to > determine which mode we are in so that

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: > We could update this patch to use the below logic: > > * CPUID(0) - Check for AuthenticAMD > * CPID(1) - Check if under hypervisor > * CPUID(0x8000) - Check for highest supported leaf > * CPUID(0x801F).EAX - Check for

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote: > If kernel_maps_pages_in_pgd is called early in boot process to change the kernel_map_pages_in_pgd() > memory attributes then it fails to allocate memory when spliting large > pages. The patch extends the cpa_data to provide the

Re: [RFC PATCH v2 13/32] KVM: SVM: Enable SEV by setting the SEV_ENABLE CPU feature

On Thu, Mar 02, 2017 at 10:15:01AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Modify the SVM cpuid update function to indicate if Secure Encrypted > Virtualization (SEV) is active in the guest by setting the SEV KVM CPU > features bit. SEV is active if Secure

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote: > This is not how you check if running under a hypervisor; you should > check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx. This in turn > tells you if leaf 0x4000 is valid. Ah, good point, I already do that in the microcode

Re: [RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption

On Tue, Mar 07, 2017 at 10:05:00AM -0600, Tom Lendacky wrote: > > And then you need to correct the function signature in the > > !CONFIG_AMD_MEM_ENCRYPT case, at the end of this file, too: > > > > unsigned long __init sme_enable(struct boot_params *bp) { > > return 0; } > > Yup,

Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial > support defines a flag that is used by the kernel to determine if it is > running with SEV active. > >

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote: > All right, I will just update the code comment. Just back ported kaslr > to our OS product, people reviewed and found the upper boundary of kaslr > mm region is EFI_VA_START, that's not correct, it has to be corrected > firstly in

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 08, 2017 at 04:45:13PM +0800, Baoquan He wrote: > -4G and -68G just a trick which makes people understand easily, still we > think kernel text mapping region is in higher addr area then vmalloc. I > personnally think. Just remove the direction: bottom-up or top-down, it will confuse

Re: [RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > DMA access to memory mapped as encrypted while SEV is active can not be > encrypted during device write or decrypted during device read. In order > for DMA to properly work when SEV

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote: > Yes, it looks better. I can repost with this change. Thanks. No it doesn't: #define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) #define EFI_VA_END (-68 * (_AC(1, UL) << 30)) That's -4G (the shift by 30) and -68G, respectively.

Re: [RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > In order to map BOOT data with the proper encryption bit, the Btw, what does that all-caps spelling "BOOT" denote? Something I'm missing? > early_ioremap() function calls are

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On Thu, Mar 02, 2017 at 10:13:32AM -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 PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

On Thu, Mar 02, 2017 at 10:13:21AM -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 PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial > support defines a flag that is used by the kernel to determine if it is > running with SEV active. > >

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On Thu, Mar 02, 2017 at 10:12:59AM -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 PATCH v2 04/32] KVM: SVM: Add SEV feature definitions to KVM

On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Define a new KVM CPU feature for Secure Encrypted Virtualization (SEV). > The kernel will check for the presence of this feature to determine if > it is running with SEV active. > >

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote: > +merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can > activate > +memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) > or > +by supplying mem_encrypt=on on the kernel command line. However,

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > > This RFC series provides support for AMD's new Secure Encrypted > > Virtualization > > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 >

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SME is identified by > CPUID 0x801f, but requires BIOS

Re: [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address

On Tue, Feb 28, 2017 at 04:34:39PM -0600, Tom Lendacky wrote: > Or if we want to guard against ACPI adding a type 0 in the future, I > could make the function return an int and then return -EINVAL if an e820 > entry isn't found. This might be the better option. Yap, think so too. I don't trust

Re: [PATCH v10 1/1] efi: a misc char interface for user to update efi firmware

On Mon, Dec 21, 2015 at 05:04:11PM +, Bryan O'Donoghue wrote: > > This patch also export efi_capsule_supported() function symbol for > > verifying the submitted capsule header in this kernel module. > > 1. Should be a separate patch > 2. Suggested, rewording for that patch log > > 2/2 Title

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Wed, Dec 16, 2015 at 11:09:50AM +, Kweh, Hock Leong wrote: > So, my conclusion is that this module is not able to be tested on QEMU > environment. That's not the point. The module should better handle writing to the device file gracefully and not explode. Regardless of whether it is

Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware

On Tue, Dec 08, 2015 at 12:25:57PM +, Matt Fleming wrote: > On Mon, 07 Dec, at 11:10:43PM, Kosuke Tatsukawa wrote: > > > > Thank you pointing that out. > > > > linux-4.4-rc3 booted without a problem on a real server even with XD > > turned off by the firmware. I didn't notice this before

Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware

On Tue, Dec 08, 2015 at 12:30:06PM -0800, Kees Cook wrote: > If we add this for not-nx, I would like to add it for not-rodata too. The W+X thing? I was under the impression we want to fix all those so that the ptdump check doesn't fire anymore. > I've never seen anyone actually use it. I was

Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware

On Tue, Dec 08, 2015 at 12:39:14PM -0800, H. Peter Anvin wrote: > Actually I think of it much more as a debug option - being able to > mimic NX-unaware hardware and to track down problems in the field. Considering it can be dangerous when exposed to the user, should we hide it behind a "Kernel

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Wed, Nov 18, 2015 at 09:00:47AM +0100, Ingo Molnar wrote: > We should at least check the BIOS version via a DMI quirk and panic in some > nicely > informative 'upgrade your BIOS!' way to ease the transition ... Or since we're touching BIOS anyway, maybe stick a bit somewhere which says "EFI

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote: > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to > efi_apply_memmap_quirks to force SGI UV systems to fall back to the old > EFI memmap mechanism. We have a BIOS fix for this issue now, so we no > longer need this

Re: [PATCH 4/6] x86/efi: Hoist page table switching code into efi_call_virt()

On Thu, Nov 12, 2015 at 08:01:08PM +, Matt Fleming wrote: > > That PUSHF implicitly pushes on the stack pointed by %rsp. But(!) we > > have switched the pagetable (i.e., %cr3 has efi_scratch.efi_pgt) and > > we're pushing to the VA where the stack *was* but is not anymore. > > All the kernel

Re: [PATCH 3/6] x86/efi: Map RAM into the identity page table for mixed mode

rk when we move to a separate page table in the future. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> > --- > arch/x86/platform/efi/efi_64.c | 20 ++

Re: [PATCH 1/6] x86/mm/pageattr: Ensure cpa->pfn only contains page frame numbers

in > this case. But when we move to using a separate page table for the EFI > runtime this will be an issue. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Dave Hansen <dave.han...@intel.com> > Sig

Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

the table > so that it's possible to see at a glance where they fall in relation > to other regions. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Linus Torvald

Re: [PATCH 5/6] x86/efi: Build our own page table structures

On Thu, Nov 12, 2015 at 03:40:22PM +, Matt Fleming wrote: > With commit e1a58320a38d ("x86/mm: Warn on W^X mappings") all users > booting on 64-bit UEFI machines see the following warning, > > [ cut here ] > WARNING: CPU: 7 PID: 1 at

Re: [PATCH 4/6] x86/efi: Hoist page table switching code into efi_call_virt()

of > writing the page table switching code in C instead of asm. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Linus Torvalds <torva...@linux-foundation.org>

Re: [PATCH 2/6] x86/mm/pageattr: Do not strip pte flags from cpa->pfn

ost machines do not have page frame numbers that reach that high. > > Still, pte flags are never stored in cpa->pfn so we can safely delete > the code. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Si

Re: [GIT PULL] x86/mm changes for v4.4

On Fri, Nov 06, 2015 at 01:09:48PM +, Matt Fleming wrote: > On Thu, 05 Nov, at 11:05:35PM, Andy Lutomirski wrote: > > > > Admittedly, we might need to use a certain amount of care to avoid > > interesting conflicts with the vmap mechanism. We might need to vmap > > all of the EFI stuff, and

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Mon, Nov 02, 2015 at 06:47:29AM +, Kweh, Hock Leong wrote: > By looking at your dmesg log, the above print out message seem that > someone has called the flush() after the write(2). In my environment, flush() > only being called in 2 places which are before write(2) and during close(2). >

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Mon, Nov 02, 2015 at 07:17:28AM +, Kweh, Hock Leong wrote: > This is not a return value to indicate what is going now. It is a flag > used in "cap_info->index" which positive value has a meaning of index > number. I am using the negative value for the flag which similar to > the

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Sun, Nov 01, 2015 at 10:52:52AM +, Kweh, Hock Leong wrote: > Could you share me your dumb file? I did perform negative test, but I did > not get these dump stack in dmesg. Thanks. I think almost any file works: cat /bin/ls > /dev/efi_capsule_loader > > > +#define UPLOAD_DONE -1 > > > >

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Thu, Oct 29, 2015 at 01:58:57AM +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > Introducing a kernel module to expose capsule loader interface > (misc char device file note) for user to upload capsule binaries. > > Example method to load the capsule

Re: [PATCH v9 1/1] efi: a misc char interface for user to update efi firmware

On Sun, Nov 01, 2015 at 11:11:23AM +, Kweh, Hock Leong wrote: > Hmm If I combine these 2 flags to become one as > "NO_MORE_WRITE_ACTION" to better describing the situation, you Okay > with it? I don't understand, why combine? Why not simply make UPLOAD_DONE a positive value: #define

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Wed, Oct 21, 2015 at 03:28:56PM +0200, Ard Biesheuvel wrote: > In theory, yes. In practice, since this is supposed to be a security > enhancement, we need some kind of ground truth to tell us which pages > can be legally modified *and* executed, so that we can detect the > illegal cases. My

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Wed, Oct 21, 2015 at 02:57:47PM +0200, Ard Biesheuvel wrote: > ... For the remaining cases, which is the vast majority, no such > assumptions can be made, and since the UEFI runtime regions are > typically populated with a bunch of PE/COFF images (each of which > consists of text + data),

Re: [PATCH V2] x86/efi: Fix kernel panic when CONFIG_DEBUG_VIRTUAL is enabled

DOWN(__pa(address)); > + > + if (pfn_range_is_mapped(pfn, pfn + 1)) > + split_page_count(level); > + } > > /* >* Install the new, split up pagetable. > -- Looks ok to me, these minor nitpicks can be adjusted when applying,

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Thu, Oct 15, 2015 at 11:10:16AM +0100, Matt Fleming wrote: > We do this for the Linux UEFI Validation project kernel [1]. There, we > do not map EFI Boot Services regions by default, only if the firmware > tries to access them. > > This gives us the opporunity to print an error message if Boot

Re: [PATCH] x86/efi: Fix kernel panic when CONFIG_DEBUG_VIRTUAL is enabled

On Tue, Oct 13, 2015 at 12:42:57PM -0700, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > When CONFIG_DEBUG_VIRTUAL is turned on, all accesses to __pa(address) > are monitored to see whether address falls in direct mapping or kernel > mapping, make that

Re: [PATCH v2] x86/mm: warn on W+x mappings

On Wed, Oct 14, 2015 at 08:30:48AM -0700, Andy Lutomirski wrote: > Can we just unmap these things until someone tries to do an EFI call, > and then unmap them again after the call returns? We already switch > pgds for EFI IIRC. hpa did mention an EFI-aware page fault handler at the time. I guess

Re: [PATCH v7 1/2] efi: export efi_capsule_supported() function symbol

On Tue, Oct 06, 2015 at 04:15:54AM +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > This patch export efi_capsule_supported() function symbol for capsule > kernel module to use. > > Cc: Matt Fleming > Signed-off-by: Kweh, Hock

Re: [PATCH v6 1/2] efi: export efi_capsule_supported() function symbol

On Sat, Oct 03, 2015 at 03:02:11AM +, Kweh, Hock Leong wrote: > It is because the author of this code is Matt. Submitting this, > allows him to easily squash into his patch: > https://lkml.org/lkml/2014/10/7/391 Then you should say that in the commit message or above it or under the "---"

Re: [PATCH v6 0/2] Enable capsule loader interface for efi firmware updating

On Sat, Oct 03, 2015 at 03:18:41AM +, Kweh, Hock Leong wrote: > > What does the error case look like? A standard glibc message about > > write(2) failing? > > > > Any upload fail error like -ENOMEM, -EINVAL, -EIO as well as error returned > by efi_capsule_update() API. All I'm asking is,

Re: [PATCH v6 0/2] Enable capsule loader interface for efi firmware updating

On Fri, Oct 02, 2015 at 09:18:05PM -0700, Andy Lutomirski wrote: > > What does the error case look like? A standard glibc message about > > write(2) failing? > > > > close(2), right? I'm looking at those retvals of efi_capsule_write(). They are returned to userspace during write(2), no? /me has

Re: [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware

On Fri, Oct 02, 2015 at 05:05:54AM +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > Introducing a kernel module to expose capsule loader interface > (misc char device file note) for user to upload capsule binaries. > > Example method to load the capsule

Re: [PATCH v6 0/2] Enable capsule loader interface for efi firmware updating

On Fri, Oct 02, 2015 at 05:05:52AM +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > Dear maintainers & communities, > > This patchset is created on top of Matt's patchset: > 1.)https://lkml.org/lkml/2014/10/7/390 > "[PATCH 1/2] efi: Move

Re: [PATCH v6 1/2] efi: export efi_capsule_supported() function symbol

On Fri, Oct 02, 2015 at 05:05:53AM +0800, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > This patch export efi_capsule_supported() function symbol for capsule > kernel module to use. > > Cc: Matt Fleming > Signed-off-by: Kweh, Hock

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On Tue, Sep 29, 2015 at 05:56:07PM -0700, H. Peter Anvin wrote: > On 09/29/2015 07:36 AM, Matt Fleming wrote: > > > > That's a pretty good summary for x86. I think specifically the reason > > we map the EFI memmap entries "backwards" (entry N has higher VA than > > entry N+1) is because the code

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On Tue, Sep 29, 2015 at 05:31:00PM +0800, Dave Young wrote: > http://permalink.gmane.org/gmane.linux.kernel.efi/822 > > And more replies here: > http://comments.gmane.org/gmane.linux.kernel.efi/820 Whatever we did think back then, it all is moot as long as some UEFI vendors do funky crap or the

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > Could we please re-list all the arguments pro and contra of 1:1 physical > mappings, > in a post that also explains the background so that more people can chime in, > not > just people versed in EFI internals? It's very much

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote: > ... so even if we wanted to, it would be intractible to find each > cross-section relative reference and do the fixup. Hmm, maybe we should go and patch EFI code segments and fixup all relative references after mapping. I mean, if

Re: [PATCH V2 2/2] ras: acpi / apei: generate trace event for unrecognized CPER section

On Tue, Sep 08, 2015 at 02:29:21PM -0700, Jonathan (Zhixiong) Zhang wrote: > /* > + * Raw Events Report > + * > + * This event is generated when hardware detected a hardware > + * error event, which may be of non-standard section as defined > + * in UEFI spec appendix "Common Platform Error

Re: [PATCH V2 1/2] efi: print unrecognized CPER section

On Tue, Sep 08, 2015 at 02:29:20PM -0700, Jonathan (Zhixiong) Zhang wrote: > From: "Jonathan (Zhixiong) Zhang" > > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER

Re: [PATCH V9 0/5] map GHES memory region according to EFI memory map

On Mon, Aug 03, 2015 at 05:23:54PM +0100, Matt Fleming wrote: Rafael, Boris? The ghes.c change looks fine I guess. The whole patchset makes sense now, with the arch bits extracted. So Acked-by: Borislav Petkov b...@suse.de However, we probably should work towards adhering to EFI memory

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 12:53:42AM -0700, H. Peter Anvin wrote: This changelog is at least partially incomprehensive. It also seems more than a bit aggressive to expect that 1 GB will be sufficient forever. Right, before we do anything, I'd like for us to figure out first why this is a problem

Re: [PATCH] x86_64/efi: Use all 64 bit of efi_memmap in setup_e820()

On Wed, Jul 22, 2015 at 07:06:10PM +0400, Dmitry Skorodumov wrote: The efi_info structure stores low 32 bits of memory map in efi_memmap and high 32 bits in efi_memmap_hi. While constructing pointer in the setup_e820(), need to take into account all 64 bit of the pointer. It is because on

Re: [PATCH 1/2] efi: parse vendor proprietary CPER section

On Tue, Jul 21, 2015 at 04:36:46PM -0700, Jonathan (Zhixiong) Zhang wrote: From: Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. If Section Type field of

Re: [PATCH 2/2] ras: acpi/apei: trace event for vendor proprietary CPER section

On Tue, Jul 21, 2015 at 04:36:47PM -0700, Jonathan (Zhixiong) Zhang wrote: From: Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org Trace event is generated when hardware detected a hardware error event, which is of non-standard section as defined in UEFI spec appendix Common Platform Error

Re: [PATCH] x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT

On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote: Definitely not FW_BUG. The field is reserved *now*; it would be legitimate for a new version of the BGRT spec to define one of those bits for something else. Which would mean that booting old kernels on new FW which defines those

Re: [PATCH] x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT

On Mon, Jun 29, 2015 at 01:06:42PM +0100, Matt Fleming wrote: From: Matt Fleming matt.flem...@intel.com It's totally legitimate, per the ACPI spec, for the firmware to set the BGRT 'status' field to zero to indicate that the BGRT image isn't being displayed, and we shouldn't be printing an

Re: [PATCH] x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT

On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote: It still makes sense to have the error message because the kernel literally does not know what the firmware is trying to achieve by setting those bits. But I agree with Josh that for the specific case of reserved bits, FW_BUG is

Re: [PATCH v5 06/10] x86/asm/efi: Fix asmvalidate warnings for efi_stub_64.S

On Thu, Jun 11, 2015 at 02:14:39PM +0100, Matt Fleming wrote: Yeah, fair enough. Though it's worth noting that because we're calling firmware functions, which use the Microsoft ABI, %rbp will be saved by the callee function if used. Yeah, just looked at the spec. But you know how we don't

Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path()

On Wed, Apr 15, 2015 at 11:14:55AM +0100, Matt Fleming wrote: Well, I haven't come across a scenario where you need a brand new interface for getting it *out* of the kernel again. Well, how are we going to read crash data on next boot then? EFI var or what? Are we going to have a generic

Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path()

On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote: This is why I think that the right approach would be to avoid using firmware_class entirely for this. IMO a simple_char device would be the way to go (hint hint...) but other simple approaches are certainly possible. Btw,

Re: [PATCH v3 2/7] x86, boot: Move ZO to end of buffer

On Mon, Mar 09, 2015 at 05:54:01PM -0700, Kees Cook wrote: On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu ying...@kernel.org wrote: Boris found data from boot stage can not be used kernel stage. ... be used during kernel stage. Also, can you give a specific example of this problem? (Which

Re: [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data

Final patch: --- From: Yinghai Lu ying...@kernel.org Date: Sat, 7 Mar 2015 14:07:17 -0800 Subject: [PATCH] x86/setup: Don't overlap vmlinux's brk with compressed kernel's data We already do move the compressed kernel close to the end of the buffer. However, there's still overlapping beween

Re: [PATCH v3 2/7] x86, boot: Move ZO to end of buffer

On Tue, Mar 10, 2015 at 10:34:31AM +0100, Jiri Kosina wrote: Thanks a lot for fixing my oversight. Bah, it was my suggestion to use setup_data in the first place, sorry about that. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list:

Re: [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data

On Tue, Mar 10, 2015 at 08:17:01AM -0700, Yinghai Lu wrote: Make it not confusing. ZO: arch/x86/boot/compressed/vmlinux VO: vmlinux setup + ZO == bzImage. compressed kernel is just compressed VO. So the two end up being the compressed kernel and kernel proper. And then the subject

Re: [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data

On Tue, Mar 10, 2015 at 08:05:52AM -0700, Yinghai Lu wrote: We need to keep VO and ZO here... Why? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to

Re: [PATCH v3 2/7] x86, boot: Move ZO to end of buffer

On Tue, Mar 10, 2015 at 08:11:03AM -0700, Yinghai Lu wrote: Also stop using compressed kernel please, that is confusing. Why? Just use ZO: arch/x86/boot/compressed/vmlinux VO: vmlinux and this is not confusing? Yeah, right. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails

Re: [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data

On Tue, Mar 10, 2015 at 08:42:40AM -0700, Yinghai Lu wrote: In arch/x86/boot/header.S, we already use VO and ZO. So please keep on using them, and don't introduce kernel proper etc. So you're suggesting commit messages should use variable names and prefixes from the code instead of being

Re: [PATCH v3 2/7] x86, boot: Move ZO to end of buffer

Final patch: --- From: Yinghai Lu ying...@kernel.org Date: Sat, 7 Mar 2015 14:07:16 -0800 Subject: [PATCH] x86/setup: Move compressed kernel to the end of the buffer Boris found that passing KASLR status through setup_data from the boot stage cannot be used later in the kernel stage, see commit

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

On Sat, Mar 07, 2015 at 02:07:15PM -0800, Yinghai Lu wrote: ... I ended up committing this. Anything I've missed? --- From: Yinghai Lu ying...@kernel.org Date: Sat, 7 Mar 2015 14:07:15 -0800 Subject: [PATCH] x86/setup: Use init_size instead of run_size Commit e6023367d779 (x86, kaslr:

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

On Mon, Mar 09, 2015 at 04:58:13PM +0100, Ingo Molnar wrote: So this would be fine as-is for v4.1, but I think we want to attempt to fix this in x86/urgent so that we don't have to revert the kaslr changes in v4.0, so it would be awesome if you could split it into two parts: the fix, plus

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

On Mon, Mar 09, 2015 at 01:06:00PM -0700, Yinghai Lu wrote: Yes. Just to emphasize that We need to make sure [z_extra_offset, init_size) will fit ZO So you want to say: We need to make sure the compressed kernel fits in the interval [z_extra_offset, z_extra_offset + init_size) ? --

fwupdate

+ pjones. So reportedly, there is already a capsule-loading thing which doesn't need the kernel at all: https://github.com/rhinstaller/fwupdate So why are we even wasting energy with this discussion here? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To

Re: [PATCH v3 1/7] x86, kaslr: Use init_size instead of run_size

On Mon, Mar 09, 2015 at 12:35:25PM -0700, Yinghai Lu wrote: Can you put back: So need to make sure [z_extra_offset, init_size) will fit ZO, that means init_size need to be adjusted according to ZO size. That make init_size is always = run_size. Why? We don't adjust init_size. We assign

Re: [PATCH v2 04/15] x86, kaslr: get kaslr_enabled back correctly

On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote: That will get wrong value back for kaslr_enabled in kernel stage. 1. When kaslr is not enabled at boot/choose_kernel_location, if kaslr_enabled get set wrongly in setup.c, late in module.c::get_module_load_offset will return not

<    1   2   3   4   5   >