Re: [PATCH v13 00/12] Add AMD SEV guest live migration support

2021-04-20 Thread Borislav Petkov
On Tue, Apr 20, 2021 at 09:08:26PM +0200, Paolo Bonzini wrote: > Yup, for now it's all at kvm/queue and it will land in kvm/next tomorrow > (hopefully). The guest interface patches in KVM are very near the top. Thx, I'll have a look tomorrow. -- Regards/Gruss, Boris.

Re: [PATCH] docs: fix the invalid vt-d spec location

2021-04-20 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 04:05:12PM +0800, Steven Zhou wrote: > Do you have any other suggestion about the link location please ? Yeah, I'm working on it. We need to come up with a proper solution for all those docs but it'll take time... Thx. -- Regards/Gruss, Boris.

Re: [PATCH v13 00/12] Add AMD SEV guest live migration support

2021-04-20 Thread Borislav Petkov
Hey Paolo, On Tue, Apr 20, 2021 at 01:11:31PM +0200, Paolo Bonzini wrote: > I have queued patches 1-6. > > For patches 8 and 10 I will post my own version based on my review and > feedback. can you pls push that tree up to here to a branch somewhere so that ... > For guest patches, please

Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

2021-04-20 Thread Borislav Petkov
On Tue, Apr 20, 2021 at 09:15:41PM +0800, Chen Yu wrote: > This patch was sent to Len and it is not in public repo yet. If that thing were in a public repo, you'd have the advantage of pointing people to it and they could be testing patches. -- Regards/Gruss, Boris. SUSE Software Solutions

Re: [RFC Part2 PATCH 05/30] x86: define RMP violation #PF error code

2021-04-20 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:11PM -0500, Brijesh Singh wrote: Btw, for all your patches where the subject prefix is only "x86:": The tip tree preferred format for patch subject prefixes is 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 'genirq/core:'. Please do not use

Re: [PATCH v1 1/3] mm/memory-failure: Use a mutex to avoid memory_failure() races

2021-04-20 Thread Borislav Petkov
On Tue, Apr 20, 2021 at 07:46:26AM +, HORIGUCHI NAOYA(堀口 直也) wrote: > If you have any other suggestion, please let me know. Looks almost ok... > From: Tony Luck > Date: Tue, 20 Apr 2021 16:42:01 +0900 > Subject: [PATCH 1/3] mm/memory-failure: Use a mutex to avoid memory_failure() > races >

Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table

2021-04-20 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 11:33:08AM -0700, Dave Hansen wrote: > My point was just that you can't _easily_ do the 2M->4k kernel mapping > demotion in a page fault handler, like I think Borislav was suggesting. Yeah, see my reply to Brijesh. Not in the #PF handler but when the guest does update the

Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table

2021-04-20 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 12:46:53PM -0500, Brijesh Singh wrote: > - KVM calls  alloc_page() to allocate a VMSA page. The allocator returns > 0xc820 (PFN 0x200, page-level=2M). The VMSA page is private > page so KVM will call RMPUPDATE to add the page as a private page in the > RMP

Re: [PATCH] x86, sched: Fix the AMD CPPC maximum perf on some specific generations

2021-04-20 Thread Borislav Petkov
ystems") > Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost > frequencies") > > Reported-by: Jason Bagavatsingham > Tested-by: Jason Bagavatsingham > Signed-off-by: Huang Rui > Cc: Alex Deucher > Cc: Nathan Fontenot > Cc:

Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

2021-04-20 Thread Borislav Petkov
On Tue, Apr 20, 2021 at 10:03:36AM +0800, Chen Yu wrote: > On Mon, Apr 19, 2021 at 02:58:12PM -0500, Terry Bowman wrote: > > Turbostat fails to correctly collect and display RAPL summary information > > on Family 17h and 19h AMD processors. Running turbostat on these processors > > returns

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-19 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 05:33:03PM -0400, Len Brown wrote: > For this to happen, every thread would not only have to include/link-with > code that uses AMX, but that code would have to *run*. It looks like either I'm not expressing myself clearly enough or you're not reading my text: the

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-19 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 02:18:51PM -0400, Len Brown wrote: > Yes, we could invent a new system call and mandate that it be called > between #2 and #3. However, we'd still do #4 in response, so I don't > see any value to that system call. Lemme refresh your memory: there was a time when the kernel

Re: [PATCH v1 1/3] mm/memory-failure: Use a mutex to avoid memory_failure() races

2021-04-19 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 07:43:18AM +0900, Naoya Horiguchi wrote: > From: Tony Luck > > There can be races when multiple CPUs consume poison from the same > page. The first into memory_failure() atomically sets the HWPoison > page flag and begins hunting for tasks that map this page. Eventually >

Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table

2021-04-19 Thread Borislav Petkov
On Mon, Apr 19, 2021 at 10:25:01AM -0500, Brijesh Singh wrote: > To my understanding, we don't group 512 4K entries into a 2M for the > kernel address range. We do this for the userspace address through > khugepage daemon. If page tables get out of sync then it will cause an > RMP violation, the

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-19 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 06:05:10PM -0400, Len Brown wrote: > I'm not aware of any intent to transparently use AMX for bcopy, like > what happened > with AVX-512. (didn't they undo that mistake?) No clue, did they? > Tasks are created without an 8KB AMX buffer. > Tasks have to actually touch the

Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table

2021-04-19 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:10PM -0500, Brijesh Singh wrote: > A write from the hypervisor goes through the RMP checks. When the > hypervisor writes to pages, hardware checks to ensures that the assigned > bit in the RMP is zero (i.e page is shared). If the page table entry that > gives the sPA

Re: [patch] x86/crash: fix crash_setup_memmap_entries() out-of-bounds access

2021-04-19 Thread Borislav Petkov
eader region */ 326 start = image->arch.elf_load_addr; (gdb) Make sure the ranges array becomes a single element allocated. [ bp: Write a proper commit message. ] Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call") Signed-off-by: Mike Galbraith

Re: [PATCH] docs: fix the invalid vt-d spec location

2021-04-18 Thread Borislav Petkov
On Sun, Apr 18, 2021 at 09:29:46AM -0700, Liang Zhou wrote: > This patch fixes the invalid vt-d spec location. Avoid having "This patch" or "This commit" in the commit message. It is tautologically useless. Also, do $ git grep 'This patch' Documentation/process for more details. >

Re: [tip: x86/urgent] x86/dma: Tear down DMA ops on driver unbind

2021-04-17 Thread Borislav Petkov
.kernel.org/tip/9f8614f5567eb4e38579422d38a1bdfeeb648ffc > Author:Jean-Philippe Brucker > AuthorDate:Wed, 14 Apr 2021 10:26:34 +02:00 > Committer: Borislav Petkov > CommitterDate: Thu, 15 Apr 2021 10:27:29 +02:00 > > x86/dma: Tear down DMA ops on driver unbind > > Since > >

Re: [tip:sched/core 23/23] kernel/sched/topology.c:17:2: error: 'sched_debug_verbose' undeclared; did you mean 'sched_debug_setup'?

2021-04-17 Thread Borislav Petkov
On Sat, Apr 17, 2021 at 02:47:46PM +0800, kernel test robot wrote: >kernel/sched/topology.c: In function 'sched_debug_setup': > >> kernel/sched/topology.c:17:2: error: 'sched_debug_verbose' undeclared > >> (first use in this function); did you mean 'sched_debug_setup'? > 17 |

Re: [PATCH 05/15] x86: Implement function_nocfi

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote: > On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote: > > > > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote: > > > __nocfi only disables CFI checking in a function, the compiler stil

Re: [PATCH 05/15] x86: Implement function_nocfi

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote: > __nocfi only disables CFI checking in a function, the compiler still > changes function addresses to point to the CFI jump table, which is > why we need function_nocfi(). So call it __func_addr() or get_function_addr() or so, so

Re: [PATCH 05/15] x86: Implement function_nocfi

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 01:38:34PM -0700, Sami Tolvanen wrote: > With CONFIG_CFI_CLANG, the compiler replaces function addresses in > instrumented C code with jump table addresses. This change implements > the function_nocfi() macro, which returns the actual function address > instead. > >

Re: [RFCv2 02/13] x86/kvm: Introduce KVM memory protection feature

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 06:40:55PM +0300, Kirill A. Shutemov wrote: > Provide basic helpers, KVM_FEATURE, CPUID flag and a hypercall. > > Host side doesn't provide the feature yet, so it is a dead code for now. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/include/asm/cpufeatures.h

Re: [patch] x86/crash: fix crash_setup_memmap_entries() out-of-bounds access

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote: > On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote: > > > > Please be more verbose and structure your commit message like this: > > Hrmph, I thought it was too verbose for dinky one-liner if anything.

Re: [patch] x86/crash: fix crash_setup_memmap_entries() out-of-bounds access

2021-04-16 Thread Borislav Petkov
On Fri, Apr 16, 2021 at 02:02:07PM +0200, Mike Galbraith wrote: > [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in > crash_setup_memmap_entries+0x17e/0x3a0 > [ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187 > > (gdb) list *crash_setup_memmap_entries+0x17e >

[tip: x86/cleanups] MAINTAINERS: Remove me from IDE/ATAPI section

2021-04-16 Thread tip-bot2 for Borislav Petkov
The following commit has been merged into the x86/cleanups branch of tip: Commit-ID: df448cdfc01ffc117702a494ef302e7fb76df78a Gitweb: https://git.kernel.org/tip/df448cdfc01ffc117702a494ef302e7fb76df78a Author:Borislav Petkov AuthorDate:Mon, 12 Apr 2021 10:59:51 +02:00

Re: [RFC Part2 PATCH 02/30] x86/sev-snp: add RMP entry lookup helpers

2021-04-15 Thread Borislav Petkov
On Thu, Apr 15, 2021 at 01:08:09PM -0500, Brijesh Singh wrote: > This is from Family 19h Model 01h Rev B01. The processor which > introduces the SNP feature. Yes, I have already upload the PPR on the BZ. > > The PPR is also available at AMD: https://www.amd.com/en/support/tech-docs Please add

Re: [RFC Part2 PATCH 03/30] x86: add helper functions for RMPUPDATE and PSMASH instruction

2021-04-15 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:09PM -0500, Brijesh Singh wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c > index 06394b6d56b2..7a0138cb3e17 100644 > --- a/arch/x86/mm/mem_encrypt.c > +++ b/arch/x86/mm/mem_encrypt.c > @@ -644,3 +644,44 @@ rmpentry_t

Re: [RFC Part2 PATCH 02/30] x86/sev-snp: add RMP entry lookup helpers

2021-04-15 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote: > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c Also, why is all this SNP stuff landing in this file instead of in sev.c or so which is AMD-specific? -- Regards/Gruss, Boris.

Re: [RFC Part2 PATCH 02/30] x86/sev-snp: add RMP entry lookup helpers

2021-04-15 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote: > The lookup_page_in_rmptable() can be used by the host to read the RMP > entry for a given page. The RMP entry format is documented in PPR > section 2.1.5.2. I see Table 15-36. Fields of an RMP Entry in the APM. Which PPR do you

Re: [PATCH] Documentation/submitting-patches: Document RESEND tag on patches

2021-04-15 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 03:02:21PM -0600, Jonathan Corbet wrote: > For future installments, could you send them in their own thread as an > ordinary patch so I don't need to edit in the changelog after applying > them? Ok, sure but I might not need to anymore because, AFAICT, what is left is

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-14 Thread Borislav Petkov
On Thu, Apr 15, 2021 at 07:29:38AM +0200, Willy Tarreau wrote: > What Len is saying is that not being interested in a feature is not an > argument for rejecting its adoption, Oh, I'm not rejecting its adoption - no, don't mean that. > which I'm perfectly fine with. But conversely not being

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-14 Thread Borislav Petkov
On Wed, Apr 14, 2021 at 05:57:22PM -0400, Len Brown wrote: > I'm pretty sure that the "it isn't my use case of interest, so it > doesn't matter" line of reasoning has long been established as -EINVAL > ;-) I have only a very faint idea what you're trying to say here. Please explain properly and

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-14 Thread Borislav Petkov
On Wed, Apr 14, 2021 at 07:46:49AM -0700, Jue Wang wrote: > I can see this is useful in other types of domains, e.g., on multi-tenant > cloud > servers where many VMs are collocated on the same host, > with proper recovery + live migration, a single MCE would only affect a single > VM at most. >

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-14 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 10:47:21PM -0700, Jue Wang wrote: > This path is when EPT #PF finds accesses to a hwpoisoned page and > sends SIGBUS to user space (KVM exits into user space) with the same > semantic as if regular #PF found access to a hwpoisoned page. > > The KVM_X86_SET_MCE ioctl

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-14 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 04:13:03PM +, Luck, Tony wrote: > Even if no applications ever do anything with it, it is still useful to avoid > crashing the whole system and just terminate one application/guest. True. > There's one more item on my long term TODO list. Add fixups so that >

Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow

2021-04-14 Thread Borislav Petkov
On Wed, Apr 14, 2021 at 01:30:43PM +0200, Florian Weimer wrote: > Is this discussion about better behavior (at least diagnostics) for > existing applications, without any code changes? Or an alternative > programming model? Former. > Does noavx512 acutally reduce the XSAVE size to AVX2 levels?

Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow

2021-04-14 Thread Borislav Petkov
On Mon, Apr 12, 2021 at 10:30:23PM +, Bae, Chang Seok wrote: > On Mar 26, 2021, at 03:30, Borislav Petkov wrote: > > On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote: > >> We really ought to have a SIGSIGFAIL signal that's sent, double-fault > >>

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-14 Thread Borislav Petkov
On Wed, Apr 14, 2021 at 12:06:39PM +0200, Willy Tarreau wrote: > And change jobs :-) I think by the time that happens, we'll be ready to go to the eternal vacation. Which means: not my problem. :-))) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-14 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 03:51:50PM -0400, Len Brown wrote: > AMX does the type of matrix multiplication that AI algorithms use. In > the unlikely event that you or one of the libraries you call are doing > the same, then you will be very happy with AMX. Otherwise, you'll > probably not use it.

Re: [RFC Part2 PATCH 01/30] x86: Add the host SEV-SNP initialization support

2021-04-14 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 12:04:07PM -0500, Brijesh Singh wrote: > @@ -538,6 +540,10 @@ > #define MSR_K8_SYSCFG0xc0010010 > #define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT23 > #define MSR_K8_SYSCFG_MEM_ENCRYPTBIT_ULL(MSR_K8_SYSCFG_MEM_ENCRYPT_BIT) > +#define

Re: [PATCH] MAINTAINERS: Remove me from IDE/ATAPI section

2021-04-14 Thread Borislav Petkov
On Wed, Apr 14, 2021 at 07:39:25AM +0100, Christoph Hellwig wrote: > On Mon, Apr 12, 2021 at 11:03:46AM +0200, Borislav Petkov wrote: > > IDE/ATAPI DRIVERS > > -M: Borislav Petkov > > L: linux-...@vger.kernel.org > > S: Maintained > > F: Documentation/cdr

Re: [thermal] 9223d0dccb: stress-ng.msg.ops_per_sec -27.4% regression

2021-04-13 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 09:58:01PM +0800, kernel test robot wrote: > Greeting, > > FYI, we noticed a -27.4% regression of stress-ng.msg.ops_per_sec due to > commit: > > > commit: 9223d0dccb8f8523754122f68316dd1a4f39f7f8 ("thermal: Move therm_throt > there from x86/mce") >

Re: Re: [PATCH] x86: Accelerate copy_page with non-temporal in X86

2021-04-13 Thread Borislav Petkov
On Tue, Apr 13, 2021 at 08:54:55PM +0800, Kemeng Shi wrote: > Yes. And NT stores should be better for copy_page especially copying a lot > of pages as only partial memory of copied page will be access recently. I thought "should be better" too last time when I measured rep; movs vs NT stores but

[PATCH] Documentation/submitting-patches: Document RESEND tag on patches

2021-04-13 Thread Borislav Petkov
Hi Jon, here's the next piece of documentation which should be generic enough. Thx. --- From: Borislav Petkov Date: Tue, 13 Apr 2021 13:26:29 +0200 Explain when a submitter should tag a patch or a patch series with the "RESEND" tag. This has been partially carved out from a tip

Re: [PATCH] x86: Accelerate copy_page with non-temporal in X86

2021-04-13 Thread Borislav Petkov
+ linux-nvdimm Original mail at https://lkml.kernel.org/r/3f28adee-8214-fa8e-b368-eaf8b1934...@huawei.com On Tue, Apr 13, 2021 at 02:25:58PM +0800, Kemeng Shi wrote: > I'm using AEP with dax_kmem drvier, and AEP is export as a NUMA node in What is AEP? > my system. I will move cold pages from

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-13 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 10:08:52AM -0700, Luck, Tony wrote: > Also not clear to me either ... but sending a SIGBUS to a kthread isn't > going to do anything useful. So avoiding doing that is another worthy > goal. Ack. > With these patches nothing gets killed when kernel touches user poison. >

Re: x86: report: write to unrecognized MSR

2021-04-13 Thread Borislav Petkov
On Mon, Apr 12, 2021 at 03:09:41PM -0700, Randy Dunlap wrote: > > [ 27.075563] msr: Write to unrecognized MSR 0x1b0 by x86_energy_perf (pid: > 1223). > [ 27.078979] msr: See > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details. > > (aka x86_energy_perf_policy) >

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-12 Thread Borislav Petkov
On Mon, Apr 12, 2021 at 04:38:15PM +0200, Florian Weimer wrote: > Yes, that's why we have the XGETBV handshake. I was imprecise. It's > CPUID + XGETBV of course. Or even AT_HWCAP2 (for FSGSBASE). Ok, that sounds better. So looking at glibc sources, I see something like this: init_cpu_features

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-12 Thread Borislav Petkov
On Mon, Apr 12, 2021 at 04:19:29PM +0200, Florian Weimer wrote: > Maybe we could have done this in 2016 when I reported this for the first > time. Now it is too late, as more and more software is using > CPUID-based detection for AVX-512. So as I said on another mail today, I don't think a

Re: [RFC Part1 PATCH 13/13] x86/kernel: add support to validate memory when changing C-bit

2021-04-12 Thread Borislav Petkov
On Mon, Apr 12, 2021 at 07:55:01AM -0500, Brijesh Singh wrote: > The cur_entry is updated by the hypervisor. While building the psc > buffer the guest sets the cur_entry=0 and the end_entry point to the > last valid entry. The cur_entry is incremented by the hypervisor after > it successfully

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-04-12 Thread Borislav Petkov
On Sun, Apr 11, 2021 at 03:07:29PM -0400, Len Brown wrote: > If it is the program, how does it know that the library wants to use > what instructions? > > If it is the library, then you have just changed XCR0 at run-time and > you expose breakage of the thread library that has computed XSAVE

Re: [RFC Part1 PATCH 13/13] x86/kernel: add support to validate memory when changing C-bit

2021-04-12 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 11:44:24AM -0500, Brijesh Singh wrote: > @@ -161,3 +162,108 @@ void __init early_snp_set_memory_shared(unsigned long > vaddr, unsigned long paddr >/* Ask hypervisor to make the memory shared in the RMP table. */ > early_snp_set_page_state(paddr, npages,

Re: [PATCH] x86/msr: Block writes to certain MSRs unconditionally

2021-04-12 Thread Borislav Petkov
On Sun, Apr 11, 2021 at 04:21:21PM -0700, Andy Lutomirski wrote: > https://bugs.winehq.org/show_bug.cgi?id=33275#c19 > > I sure hope no one is still doing this. Aha, IRET with rFLAGS.NT set. At least it is only an ad-hoc program to fix this particular issue and I hope too it hasn't propagated

[PATCH] MAINTAINERS: Remove me from IDE/ATAPI section

2021-04-12 Thread Borislav Petkov
From: Borislav Petkov It has been years since I've touched this and "this" is going away anyway... any day now. :-) So remove me so that I do not get CCed on bugs/patches. Signed-off-by: Borislav Petkov --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAI

Re: [PATCH] x86/msr: Block writes to certain MSRs unconditionally

2021-04-11 Thread Borislav Petkov
On Sun, Apr 11, 2021 at 09:57:20AM -0700, Andy Lutomirski wrote: > Working around a kernel bug. The workaround only worked on AMD > systems. The correct solution was to fix the kernel bug, not poke > MSRs. Do you remember which program(s) and where I can get them to have a look? --

Re: [PATCH] x86/msr: Block writes to certain MSRs unconditionally

2021-04-11 Thread Borislav Petkov
On Sat, Apr 10, 2021 at 11:52:17AM -0700, Andi Kleen wrote: > Have you ever seen any user programs actually write those MSRs? > I don't see why they ever would, it's not that they have any motivation > to do it (unlike SMM), and I don't know of any examples. You'd be surprised how much motivation

Re: [PATCH v2] x86: pat: Do not compile stubbed functions when X86_PAT is off

2021-04-11 Thread Borislav Petkov
On Sun, Apr 11, 2021 at 11:12:32AM +0200, Jan Kiszka wrote: > The patches are coming from downstream usage, yes, Ok, for the future, it would be good to mention that in the commit message so that a committer knows what they're for. > but I think the solutions are relevant cleanups for upstream

Re: [PATCH v2] x86: pat: Do not compile stubbed functions when X86_PAT is off

2021-04-11 Thread Borislav Petkov
On Sun, Apr 11, 2021 at 10:22:19AM +0200, Jan Kiszka wrote: > On 26.10.20 18:39, Jan Kiszka wrote: > > From: Jan Kiszka > > > > Those are already provided by linux/io.h as stubs. > > > > The conflict remains invisible until someone would pull linux/io.h into > > memtype.c. > > > > Signed-off-by:

[GIT PULL] x86/urgent for v5.12-rc7

2021-04-11 Thread Borislav Petkov
Hi Linus, please pull two more urgent fixes (not gonna say "final" this time) from x86-land. Thx. --- The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120: Linux 5.12-rc6 (2021-04-04 14:15:36 -0700) are available in the Git repository at:

Re: [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked

2021-04-10 Thread Borislav Petkov
On Sat, Apr 10, 2021 at 10:48:56PM +0800, Feng Tang wrote: > And the bigger risk is still BIOS's writing to TSC_ADJUST MSR beneath > kernel. For that we need to do more persuasive work with hw guys. Needs a *lot* of perseverance. -- Regards/Gruss, Boris.

[PATCH -v1.1] x86/msr: Block writes to certain MSRs unconditionally

2021-04-10 Thread Borislav Petkov
On Sat, Apr 10, 2021 at 07:51:58AM -0700, Andy Lutomirski wrote: > Can you add STAR, CSTAR, LSTAR, SYSENTER*, SYSCALL*, and EFER please? Sure. --- From: Borislav Petkov Date: Sat, 10 Apr 2021 14:08:13 +0200 There are a bunch of MSRs which luserspace has no business poking at, whatsoever.

[PATCH] x86/msr: Block writes to certain MSRs unconditionally

2021-04-10 Thread Borislav Petkov
From: Borislav Petkov Date: Sat, 10 Apr 2021 14:08:13 +0200 There are a bunch of MSRs which luserspace has no business poking at, whatsoever. Add a ban list and put the TSC-related MSRs in there. Issue a big juicy splat to catch offenders. Signed-off-by: Borislav Petkov --- arch/x86/kernel

Re: [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked

2021-04-10 Thread Borislav Petkov
On Sat, Apr 10, 2021 at 11:27:11AM +0200, Thomas Gleixner wrote: > On Tue, Mar 30 2021 at 16:25, Feng Tang wrote: > > Normally the tsc_sync will be checked every time system enters idle state, > > but there is still caveat that a system won't enter idle, either because > > it's too busy or

Re: [PATCH v24 04/30] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions

2021-04-10 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 04:14:09PM -0700, Yu, Yu-cheng wrote: > > @@ -53,6 +55,8 @@ static short xsave_cpuid_features[] __initdata = { > > X86_FEATURE_INTEL_PT, > > X86_FEATURE_PKU, > > X86_FEATURE_ENQCMD, > > + X86_FEATURE_CET, /* XFEATURE_CET_USER */ > > + X86_FEATURE_CET, /*

Re: [PATCH 1/5] x86/cpufeatures: Define feature bits to support mitigation of PSF

2021-04-09 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 02:45:23PM -0500, Saripalli, RK wrote: > Yes, these options should be fine for now. > Like you said, if we get the need to add prctl and seccomp, I can always do > that later. > > What do you think auto should default to?. > In SSBD case, I believe auto defaults to prctl

Re: [PATCH 1/5] x86/cpufeatures: Define feature bits to support mitigation of PSF

2021-04-09 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 01:22:49PM -0500, Saripalli, RK wrote: > > And I think you don't need this one either if we do a "light" controls > > thing but lemme look at the rest first. Ok, and what I mean with "lite" version is something like this below which needs finishing and testing. Initially,

Re: [PATCH 1/5] x86/cpufeatures: Define feature bits to support mitigation of PSF

2021-04-09 Thread Borislav Petkov
On Tue, Apr 06, 2021 at 10:50:00AM -0500, Ramakrishna Saripalli wrote: > diff --git a/arch/x86/include/asm/cpufeatures.h > b/arch/x86/include/asm/cpufeatures.h > index cc96e26d69f7..21e7f8d0d7d9 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@

Re: [PATCH v24 04/30] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions

2021-04-09 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 08:52:52AM -0700, Yu, Yu-cheng wrote: > Recall we had complicated code for the XSAVES features detection in > xstate.c. Dave Hansen proposed the solution and then the whole thing > becomes simple. Because of this flag, even when only the shadow stack is > available, the

Re: [RFC Part1 PATCH 11/13] x86/kernel: validate rom memory before accessing when SEV-SNP is active

2021-04-09 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 11:44:22AM -0500, Brijesh Singh wrote: > + /* > + * The ROM memory is not part of the E820 system RAM and is not > prevalidated by the BIOS. > + * The kernel page table maps the ROM region as encrypted memory, the > SEV-SNP requires > + * the all the

Re: [RFCv1 2/7] x86/kvm: Introduce KVM memory protection feature

2021-04-09 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 04:36:01PM +0300, Kirill A. Shutemov wrote: > The patchset is still in path-finding stage. I'll be more specific once we > settle on how the feature works. This is not why I'm asking: these feature bits are visible to userspace in /proc/cpuinfo and if you don't have a use

Re: [PATCH v5 0/4] KVM: cpuid: fix KVM_GET_EMULATED_CPUID implementation

2021-04-09 Thread Borislav Petkov
On Fri, Apr 09, 2021 at 02:54:19PM +0200, Emanuele Giuseppe Esposito wrote: > This series aims to clarify the behavior of the KVM_GET_EMULATED_CPUID > ioctl, and fix a corner case where -E2BIG is returned when > the nent field of struct kvm_cpuid2 is matching the amount of > emulated entries that

Re: [PATCH v24 04/30] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions

2021-04-09 Thread Borislav Petkov
On Thu, Apr 01, 2021 at 03:10:38PM -0700, Yu-cheng Yu wrote: > Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow > Stack or Indirect Branch Tracking (or both) is present. Also introduce > related cpu init/setup functions. > > Signed-off-by: Yu-cheng Yu > Cc: Kees Cook

Re: [PATCH 0/5] Introduce support for PSF mitigation

2021-04-09 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 09:56:47AM -0500, Saripalli, RK wrote: > It is possible most applications have been reviewed and scrubbed for > SSB-type attacks but PSF-type issues may not have been looked at yet. > This may be one of the cases where SSB is enabled but PSF is disabled > until the

Re: [PATCH 4/4] x86/mce: Avoid infinite loop for copy from user recovery

2021-04-08 Thread Borislav Petkov
On Thu, Mar 25, 2021 at 05:02:35PM -0700, Tony Luck wrote: ... > Expected worst case is two machine checks before moving on (e.g. one user > access with page faults disabled, then a repeat to the same addrsss with > page faults enabled). Just in case there is some code that loops forever > enforce

Re: [RFC Part1 PATCH 09/13] x86/kernel: add support to validate memory in early enc attribute change

2021-04-08 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 11:44:20AM -0500, Brijesh Singh wrote: > @@ -63,6 +63,10 @@ struct __packed snp_page_state_change { > #define GHCB_REGISTER_GPA_RESP 0x013UL > #define GHCB_REGISTER_GPA_RESP_VAL(val) ((val) >> 12) > > +/* Macro to convert the x86 page level to

Re: [RFCv1 2/7] x86/kvm: Introduce KVM memory protection feature

2021-04-08 Thread Borislav Petkov
On Fri, Apr 02, 2021 at 06:26:40PM +0300, Kirill A. Shutemov wrote: > Provide basic helpers, KVM_FEATURE, CPUID flag and a hypercall. > > Host side doesn't provide the feature yet, so it is a dead code for now. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/include/asm/cpufeatures.h

Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the debugfs

2021-04-08 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 12:13:21PM +0300, Jarkko Sakkinen wrote: > Actually I think read-only sysctl attributes would be a better idea. I still think debugfs is the right *start* for this: you play with them, see what makes sense and what not, tweak them, etc, and then you cast them in stone.

Re: [PATCH v2 1/2] x86/sgx: Do not update sgx_nr_free_pages in sgx_setup_epc_section()

2021-04-08 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 12:22:56PM +0300, Jarkko Sakkinen wrote: > They are not in the "free_page_list" before sanitization process has put > them to there. So in that way the count is also better in sync with this > fix. This is the bit of information I was looking for. This needs to be in the

Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the debugfs

2021-04-08 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 11:52:40AM +0300, Jarkko Sakkinen wrote: > I think these attributes are quite useful information to have available so > I'd go actually doing sysfs attributes and create > Documentation/ABI/stable/sysfs-driver-sgx to document them. testing/ This directory

Re: [PATCH v2 1/2] x86/sgx: Do not update sgx_nr_free_pages in sgx_setup_epc_section()

2021-04-08 Thread Borislav Petkov
On Thu, Apr 08, 2021 at 11:48:46AM +0300, Jarkko Sakkinen wrote: > The regression is that the sgx_nr_free_pages is also incremented by > sgx_free_epc_pages(), and thus it ends up having double the number of > pages available. So when you add a new EPC section with sgx_setup_epc_section(), those

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-08 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 02:43:10PM -0700, Luck, Tony wrote: > On Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote: > > On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote: > > > Andy Lutomirski pointed out that sending SIGBUS to tasks that > > > hit p

Re: [RFC Part1 PATCH 08/13] x86/sev-es: register GHCB memory when SEV-SNP is active

2021-04-08 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 11:44:19AM -0500, Brijesh Singh wrote: > @@ -88,6 +89,13 @@ struct sev_es_runtime_data { >* is currently unsupported in SEV-ES guests. >*/ > unsigned long dr7; > + > + /* > + * SEV-SNP requires that the GHCB must be registered before using it.

Re: [RFC Part1 PATCH 07/13] x86/compressed: register GHCB memory when SNP is active

2021-04-08 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 12:34:59PM -0500, Brijesh Singh wrote: > The feature is part of the GHCB version 2 and is enforced by the > hypervisor. I guess it can be extended for the ES. Since this feature > was not available in GHCB version 1 (base ES) so it should be presented > as an optional for

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

2021-04-07 Thread Borislav Petkov
On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote: > Andy Lutomirski pointed out that sending SIGBUS to tasks that > hit poison in the kernel copying syscall parameters from user > address space is not the right semantic. What does that mean exactly? >From looking at the code, that is

Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 01:25:55PM +0200, Borislav Petkov wrote: > On Tue, Apr 06, 2021 at 02:42:43PM -0500, Tom Lendacky wrote: > > The GHCB spec only defines the "0" reason code set. We could provide Linux > > it's own reason code set with some more specific reas

Re: [PATCH] x86/kernel: remove unneeded dead-store initialization

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 09:03:28PM +0200, Borislav Petkov wrote: > On Wed, Apr 07, 2021 at 10:41:26AM -0700, Nick Desaulniers wrote: > > You do have clang-tidy installed right? `which clang-tidy`? Btw, for user convenience, that "clang-analyzer" Makefile target could che

Re: [PATCH] x86/kernel: remove unneeded dead-store initialization

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 10:41:26AM -0700, Nick Desaulniers wrote: > You do have clang-tidy installed right? `which clang-tidy`? Yah, installed that and was able to repro: arch/x86/kernel/cpu/cacheinfo.c:880:24: warning: Value stored to 'this_cpu_ci' during its initialization is never read

Re: [PATCH v2 8/8] KVM: SVM: Allocate SEV command structures on local stack

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 05:05:07PM +, Sean Christopherson wrote: > I used memset() to defer initialization until after the various sanity > checks, I'd actually vote for that too - I don't like doing stuff which is not going to be used. I.e., don't change what you have. -- Regards/Gruss,

Re: [PATCH v2 1/2] x86/sgx: Do not update sgx_nr_free_pages in sgx_setup_epc_section()

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 07:03:47PM +0300, Jarkko Sakkinen wrote: > > Which leads to my question: what is sgx_nr_free_pages supposed to denote? > > > > Because I understand the callpath > > > > sgx_page_cache_init > > ... > > for (i = 0; i < ARRAY_SIZE(sgx_epc_sections); i++) { > > ... > >

Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the debugfs

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 07:09:11PM +0300, Jarkko Sakkinen wrote: > I left out "epc" because they are already prefixed with "sgx_". Are there any other "page" types which are going to be figurating in some pseudofs or is "sgx" == "epc" in this case? > debugfs was my first shot, but for sure these

Re: [PATCH 1/7] hyperv: Detect Nested virtualization support for SVM

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 02:41:22PM +, Vineeth Pillai wrote: > Detect nested features exposed by Hyper-V if SVM is enabled. > > Signed-off-by: Vineeth Pillai > --- > arch/x86/kernel/cpu/mshyperv.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the debugfs

2021-04-07 Thread Borislav Petkov
On Tue, Apr 06, 2021 at 02:26:53AM +0300, Jarkko Sakkinen wrote: > Add two debugs attributes: > > * /sys/kernel/debug/x86/sgx_nr_all_pages > * /sys/kernel/debug/x86/sgx_nr_free_pages Definitely under /sys/kernel/debug/x86/sgx/... ^^ > These provide

Re: [PATCH v2 1/2] x86/sgx: Do not update sgx_nr_free_pages in sgx_setup_epc_section()

2021-04-07 Thread Borislav Petkov
On Tue, Apr 06, 2021 at 02:26:52AM +0300, Jarkko Sakkinen wrote: > Now that the sanitization process will make pages available by calling > sgx_free_epc_page(), sgx_setup_epc_section() should not touch to > sgx_nr_free_pages. This will result sgx_nr_free_pages to contain 2x the > number of actual

Re: [PATCH 0/5] Introduce support for PSF mitigation

2021-04-07 Thread Borislav Petkov
On Wed, Apr 07, 2021 at 07:49:48AM -0500, Ramakrishna Saripalli wrote: > From: Ramakrishna Saripalli It seems you're new to this kernel development thing. While you're waiting for your patches to be reviewed fully and properly, please take the time to read

Re: [PATCH] x86/kernel: remove unneeded dead-store initialization

2021-04-07 Thread Borislav Petkov
On Wed, Mar 31, 2021 at 04:00:24PM +0800, Yang Li wrote: > make clang-analyzer on x86_64 defconfig caught my attention with: I can't trigger this here using: make CC=clang-11 -j16 clang-analyzer I get all kinds of missing python scripts: multiprocessing.pool.RemoteTraceback: """ Traceback

Re: [RFC Part1 PATCH 07/13] x86/compressed: register GHCB memory when SNP is active

2021-04-07 Thread Borislav Petkov
On Wed, Mar 24, 2021 at 11:44:18AM -0500, Brijesh Singh wrote: > The SEV-SNP guest is required to perform GHCB GPA registration. This is Why does it need to do that? Some additional security so as to not allow changing the GHCB once it is established? I'm guessing that's enforced by the SNP fw

Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB

2021-04-07 Thread Borislav Petkov
On Tue, Apr 06, 2021 at 02:42:43PM -0500, Tom Lendacky wrote: > The GHCB spec only defines the "0" reason code set. We could provide Linux > it's own reason code set with some more specific reason codes for > failures, if that is needed. Why Linux only? Don't we want to have a generalized set of

Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB

2021-04-07 Thread Borislav Petkov
On Tue, Apr 06, 2021 at 10:47:18AM -0500, Brijesh Singh wrote: > Before the GHCB is established the caller does not need to save and > restore MSRs. The page_state_change() uses the GHCB MSR protocol and it > can be called before and after the GHCB is established hence I am saving > and restoring

  1   2   3   4   5   6   7   8   9   10   >