Re: [PATCH 1/8] x86, kaslr: get kaslr_enabled back correctly

On Sun, Mar 01, 2015 at 04:23:51PM +0100, Ingo Molnar wrote: I think that's a different bug. parse_kaslr_setup() is simply bogus, it does: kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data)); Well, we found that while debugging the other issue too:

Re: [PATCH 1/8] x86, kaslr: get kaslr_enabled back correctly

On Sun, Mar 01, 2015 at 11:27:48AM -0800, Yinghai Lu wrote: other 7 should also address the problem in http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com No, they don't: [0.00] parse_setup_data: data: 0x2206e50 (va: ff200e50) { next: 0x0, type: 0x0, len: 16,

Re: [PATCH 1/8] x86, kaslr: get kaslr_enabled back correctly

On Sun, Mar 01, 2015 at 12:24:08PM -0800, Yinghai Lu wrote: static allocation in misc.c can not be used to kernel/head_64.S stage safely. Correct. One possibility that works is sticking it right below LOAD_PHYSICAL_ADDR: +static void add_kaslr_setup_data(struct boot_params *params, +

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Wed, Feb 25, 2015 at 12:38:20PM +, Kweh, Hock Leong wrote: The reason we use this interface for efi capsule is that efi capsule support multi binaries to be uploaded and each binary file name can be different. So you can write the file path to a second file and reload then, once per

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote: So the process steps basically look like this: 1.) cat capsule_ticket=== acquire a number and lock mutex then expose firmware_class user helper

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Thu, Feb 26, 2015 at 07:30:54AM -0800, Andy Lutomirski wrote: How can the error code be propagated? Would that echo command fail in case of error? Yeah, either that or we can put the error code in the sysfs file which userspace can cat. -- Regards/Gruss, Boris. ECO tip #101: Trim

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote: No. Only root should be able to load capsules, but even root may not be able to write to /lib. So basically what we want to do is: # cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img /sys/firmware/efi/update Now

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 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 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] 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 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 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 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: [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 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: [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] 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 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 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 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] 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 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 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 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 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 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 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 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 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 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 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: [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: [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: [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 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 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 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 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 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 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 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: [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: [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 03/10] efi: parse ARM processor error

On Tue, Mar 28, 2017 at 01:30:33PM -0600, Tyler Baicar wrote: > Add support for ARM Common Platform Error Record (CPER). > UEFI 2.6 specification adds support for ARM specific > processor error information to be reported as part of the > CPER records. This provides more detail on for processor

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 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: [PATCH V14 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

On Thu, Apr 13, 2017 at 02:30:21PM -0600, Baicar, Tyler wrote: > I do not agree with this. The struct being passed to this function is > already named acpi_hest_generic_data in the existing code and all over this > code is named gdata not just d. And I'm saying they're too long - the preexisting

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On Thu, Apr 20, 2017 at 12:29:20PM -0500, Tom Lendacky wrote: > Hmmm... and actually if cpu_has(X86_FEATURE_SME) is true then it's a > given that extended_cpuid_level >= 0x801f. So this can be > simplified to just: > > if (cpu_has(c, X86_FEATURE_SME)) { > ... the rest of

Re: [PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

On Wed, Apr 19, 2017 at 09:23:47AM -0500, Tom Lendacky wrote: > Btw, I tried to update all the subjects and descriptions to be > more descriptive but I'm sure there is still room for improvement > so keep the comments on them coming. No worries there :) > Note, just because the bit is set in

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On Tue, Apr 18, 2017 at 05:05:15PM -0600, Tyler Baicar wrote: > The ACPI 6.1 spec added a timestamp to the HEST generic data HEST? I see the timestamp in Table 18-343 Generic Error Data Entry where those things are "One or more Generic Error Data Entry structures may be recorded in the Generic

Re: [PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

On Tue, Apr 18, 2017 at 05:05:14PM -0600, Tyler Baicar wrote: > The ACPI 6.1 spec adds a new version of the generic data structure. which data structure? HEST? > Add support to handle the new structure as well as properly verify > and iterate through the generic data entries. > > Signed-off-by:

Re: [PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

On Tue, Apr 18, 2017 at 05:05:13PM -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: [PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

On Wed, Apr 19, 2017 at 02:31:13PM -0600, Baicar, Tyler wrote: > Will do. You don't necessarily have to reply with "will do" if you agree with the review. Also, please wait until I've gone through the whole pile before sending it again. Thanks. -- Regards/Gruss, Boris. Good mailing

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote: > When System Memory Encryption (SME) is enabled, the physical address > space is reduced. Adjust the x86_phys_bits value to reflect this > reduction. > > Signed-off-by: Tom Lendacky > --- >

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On Fri, Apr 21, 2017 at 12:08:43PM -0600, Baicar, Tyler wrote: > The timestamp may still be useful when it is imprecise. In the polling case, > you may only poll every minute or so, so the time may be useful. Well, what is in the timestamp when !precise? Some random time or some timestamp from a

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Tue, Apr 18, 2017 at 05:05:16PM -0600, Tyler Baicar wrote: > Add support for ARM Common Platform Error Record (CPER). > UEFI 2.6 specification adds support for ARM specific > processor error information to be reported as part of the > CPER records. This provides more detail on for processor

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

On Fri, Apr 21, 2017 at 10:04:35AM -0600, Baicar, Tyler wrote: > This is basically what I already had in v14...you asked to move it into a > different if-statement? https://lkml.org/lkml/2017/4/12/397 Well, clearly I've been smoking some nasty potent sh*t. :-\ /me goes and looks at the spec:

Re: [PATCH v5 07/32] x86/mm: Add support to enable SME in early boot processing

On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote: > Add support to the early boot code to use Secure Memory Encryption (SME). > Since the kernel has been loaded into memory in a decrypted state, support > is added to encrypt the kernel in place and update the early pagetables

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 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 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 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 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 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: [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 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 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: [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: [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 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. > >

<    1   2   3   4   5   >