On Thu, Mar 28, 2024 at 01:17:43AM -0500, Naik, Avadhut wrote:
> SOCKET -> Socket
> PROCESSOR -> Processor
> MICROCODE -> Microcode
SOCKET -> socket
PROCESSOR -> processor
MICROCODE -> microcode
And yeah, the acronyms need to obviously stay in all caps.
Thx.
--
Regards/Gruss,
Boris.
On Wed, Mar 27, 2024 at 03:31:01PM -0700, Sohil Mehta wrote:
> On 3/27/2024 1:54 PM, Avadhut Naik wrote:
>
> > - TP_printk("CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx,
> > ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN:
> > %llx, PROCESSOR: %u:%x, TIME:
On Mon, Mar 25, 2024 at 03:12:14PM -0500, Naik, Avadhut wrote:
> Can this patchset be merged in? Or would you prefer me sending out
> another revision with Steven's "Reviewed-by:" tag?
First of all, please do not top-post.
Then, you were on Cc on the previous thread. Please summarize from it
and
; someone to search for exactly where the bug happened.
>
> Reported-by: Borislav Petkov
> Signed-off-by: Steven Rostedt (Google)
> ---
> include/linux/tracepoint.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Tested-by: Borislav Petkov (AMD)
meani
On Fri, Jan 26, 2024 at 10:01:29PM +, Luck, Tony wrote:
> PPIN: Nice to have. People that send stuff to me are terrible about
> providing surrounding details. The record already includes
> CPUID(1).EAX ... so I can at least skip the step of asking them which
> CPU family/model/stepping they
On Fri, Jan 26, 2024 at 08:49:03PM +, Luck, Tony wrote:
> Every patch that adds new code or data structures adds to the kernel
> memory footprint. Each should be considered on its merits. The basic
> question being:
>
>"Is the new functionality worth the cost?"
>
> Where does it end? It
On Fri, Jan 26, 2024 at 07:15:50PM +, Luck, Tony wrote:
> If deployment of a microcode update across a fleet always went
> flawlessly, life would be simpler. But things can fail. And maybe the
> failure wasn't noticed. Perhaps a node was rebooting when the sysadmin
> pushed the update to the
On Fri, Jan 26, 2024 at 05:10:20PM +, Luck, Tony wrote:
> 12 extra bytes divided by (say) 64GB (a very small server these days, may
> laptop has that much)
>= 0.0001746%
>
> We will need 57000 changes like this one before we get to 0.001% :-)
You're forgetting that those 12 bytes
On Thu, Jan 25, 2024 at 07:19:22PM +, Luck, Tony wrote:
> 8 bytes for PPIN, 4 more for microcode.
I know, nothing leads to bloat like 0.01% here, 0.001% there...
> Number of recoverable machine checks per system I hope the
> monthly rate should be countable on my fingers...
That's not
On Thu, Jan 25, 2024 at 12:48:55PM -0600, Avadhut Naik wrote:
> This patchset updates the mce_record tracepoint so that the recently added
> fields of struct mce are exported through it to userspace.
>
> The first patch adds PPIN (Protected Processor Inventory Number) field to
> the tracepoint.
>
On Wed, Jan 24, 2024 at 09:09:08AM -0500, Steven Rostedt wrote:
> I don't think that's a worry anymore. The offsets can change based on
> kernel config. PowerTop needed to have the library ported to it because
> it use to hardcode the offsets but then it broke when running the 32bit
> version on a
On Tue, Jan 23, 2024 at 08:38:53PM -0500, Steven Rostedt wrote:
> Yes, rasdaemon uses libtraceevent (or a copy of it internally) that
> reads the format file to find fields. You can safely add fields to the
> middle of the event structure and the parsing will be just fine.
Should we worry about
On Fri, Dec 08, 2023 at 12:53:47PM +0100, Juergen Gross wrote:
> Took me a while to find it. Patch 5 was repairing the issue again
Can't have that. Any patch in any set must build and boot successfully
for bisection reasons.
--
Regards/Gruss,
Boris.
On Mon, Oct 30, 2023 at 03:25:07PM +0100, Juergen Gross wrote:
> Instead of stacking alternative and paravirt patching, use the new
> ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
> handling.
>
> This eliminates the need to be careful regarding the sequence of
> alternative
On Mon, Oct 30, 2023 at 03:25:06PM +0100, Juergen Gross wrote:
> Introduce the macro ALT_NOT_XEN as a short form of
> ALT_NOT(X86_FEATURE_XENPV).
Not crazy about adding yet another macro indirection - at least with the
X86_FEATURE_ it is clear what this is. But ok, whatever.
Anyway, this patch
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.
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.
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
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
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
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
>
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
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
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:
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
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
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
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
>
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
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
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
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
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.
>
.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
>
>
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 |
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
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
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.
>
>
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
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.
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
>
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
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
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
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.
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
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
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
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
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.
>
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
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
>
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?
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
> >>
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
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.
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
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
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")
>
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
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
+ 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
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.
>
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)
>
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
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
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
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
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,
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
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
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?
--
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
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
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:
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:
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.
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.
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
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
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, /*
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
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,
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
> @@
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
1 - 100 of 23602 matches
Mail list logo
