search for: ist

On Tue, Jul 14, 2020 at 02:08:47PM +0200, Joerg Roedel wrote: > @@ -489,6 +490,9 @@ DEFINE_IDTENTRY_RAW(exc_nmi) > this_cpu_write(nmi_cr2, read_cr2()); > nmi_restart: > > + /* Needs to happen before DR7 is accessed */ > + sev_es_ist_enter(regs); > + > this_cpu_write(nmi_dr7, local_db_save()); > > nmi_enter(); > @@ -502,6 +506,8 @@ DEFINE_IDTENTRY_RAW(exc_nmi) > > local_db_restore(this_cpu_read(nmi_dr7)); > > + sev_es_ist_exit(); > + > if (unlikely(this_cpu_read(nmi_cr2) != read_cr...

On Tue, Jul 14, 2020 at 02:08:47PM +0200, Joerg Roedel wrote: > @@ -489,6 +490,9 @@ DEFINE_IDTENTRY_RAW(exc_nmi) > this_cpu_write(nmi_cr2, read_cr2()); > nmi_restart: > > + /* Needs to happen before DR7 is accessed */ > + sev_es_ist_enter(regs); > + > this_cpu_write(nmi_dr7, local_db_save()); > > nmi_enter(); > @@ -502,6 +506,8 @@ DEFINE_IDTENTRY_RAW(exc_nmi) > > local_db_restore(this_cpu_read(nmi_dr7)); > > + sev_es_ist_exit(); > + > if (unlikely(this_cpu_read(nmi_cr2) != read_cr...

Hi Andy, On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > 1. Use IST for #VC and deal with all the mess that entails. With the removal of IST shifting I wonder what you would suggest on how to best implement an NMI-safe IST handler with nesting support. My current plan is to implement an IST handler which switches itself off the IST stack as soon as possible, free...

...es -t nat -A POSTROUTING -p udp -s 192.168.13.110 --dport 161 -j SNAT --to-source 192.168.13.83:161" I have written a script to continuously poll an agent using snmpgetnext. This script works for some time and then snmpgetnext fails giving the following message "Fri Dec 21 19:10:20 IST 2007 SNMPv2-SMI::enterprises.3769.1.2.3.1.0 = "" Fri Dec 21 19:10:20 IST 2007 SNMPv2-SMI::enterprises.3769.1.2.3.1.0 = "" Fri Dec 21 19:10:20 IST 2007 SNMPv2-SMI::enterprises.3769.1.2.3.1.0 = "" Fri Dec 21 19:10:20 IST 2007 SNMPv2-SMI::enterprises.376...

...to find you handle the NMI-like cases.. The comment is not 100% accurate anymore, I will update it. Initially #DB was an NMI-like case, but I figured that with .text.noinstr and the way the #VC entry code switches stacks, there is no #DB special handling necessary anymore. > > + * case the IST entry for VC must be adjusted, so that any subsequent VC > > + * exception will not overwrite the stack contents of the interrupted VC > > + * handler. > > + * > > + * The IST entry is adjusted unconditionally so that it can be also be > > + * unconditionally back-adju...

On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > I assume the race you mean is: > > > > #VC > > Immediate NMI before IST gets shifted > > #VC > > > > Kaboom. > > > > How are you dealing with this? Ultimately, I think that NMI will need > > to turn off IST before engaging in any funny business. Let me ponder > > this a bit. > > Right, I dealt with that by unconditionall...

On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > I have a somewhat serious question: should we use IST for #VC at all? > As I understand it, Rome and Naples make it mandatory for hypervisors > to intercept #DB, which means that, due to the MOV SS mess, it's sort > of mandatory to use IST for #VC. But Milan fixes the #DB issue, so, > if we're running under a sufficiently sensible...

From: Joerg Roedel <jroedel at suse.de> When an NMI hits in the #VC handler entry code before it switched to another stack, any subsequent #VC exception in the NMI code-path will overwrite the interrupted #VC handlers stack. Make sure this doesn't happen by explicitly adjusting the #VC IST entry in the NMI handler for the time in can cause #VC exceptions. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/sev-es.h | 8 +++++ arch/x86/kernel/nmi.c | 6 ++++ arch/x86/kernel/sev-es.c | 61 +++++++++++++++++++++++++++++++++++ arch/x86/kernel/...

On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > Hi Andy, > > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > > 1. Use IST for #VC and deal with all the mess that entails. > > With the removal of IST shifting I wonder what you would suggest on how > to best implement an NMI-safe IST handler with nesting support. > > My current plan is to implement an IST handler which switches itself off > the IST s...

From: Joerg Roedel <jroedel at suse.de> Allocate and map enough stacks for the #VC handler to support sufficient levels of nesting and the NMI-in-#VC scenario. Also setup the IST entrys for the #VC handler on all CPUs because #VC needs to work before cpu_init() has set up the per-cpu TSS. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/cpu_entry_area.h | 61 +++++++++++++++++++++++++++ arch/x86/include/asm/page_64_types.h | 1 + arch/x86/...

From: Joerg Roedel <jroedel at suse.de> When an NMI hits in the #VC handler entry code before it switched to another stack, any subsequent #VC exception in the NMI code-path will overwrite the interrupted #VC handlers stack. Make sure this doesn't happen by explicitly adjusting the #VC IST entry in the NMI handler for the time in can cause #VC exceptions. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-46-joro at 8bytes.org --- arch/x86/include/asm/sev-es.h | 19 +++++++++++ arch/x86/kernel/nmi.c | 6 ++++ arch/x86...

On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: > If SNP is the sole reason #VC needs to be IST, then I'd strongly urge > you to only make it IST if/when you try and make SNP happen, not before. It is not the only reason, when ES guests gain debug register support then #VC also needs to be IST, because #DB can be promoted into #VC then, and as #DB is IST for a reason, #VC needs to be...

...23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > Or maybe you have a better idea how to implement this, so I'd like to > > hear your opinion first before I spend too many days implementing > > something. > > OK, excuse my ignorance, but I'm not seeing how that IST shifting > nonsense would've helped in the first place. > > If I understand correctly the problem is: > > <#VC> > shift IST > <NMI> > ... does stuff > <#VC> # again, safe because the shift > > But what happens if you get the...

...orks fine, smbclient works fine, but Windows 7 only works for SOME passwords. Some work, some do not. Samba is configured with restricted LDAP bind dn, but should see all attributes (except for the userPassword attribute, which is not used by samba afaik). During setup I have provided it with administrator LDAP access to populate some basic data and to see exactly how users are defined, but I have removed the populated samba groups from LDAP, since we do not use Samba as domain server. I set the password in sambaNTPassword attribute in LDAP. I have tried with the following password examples: i...

On Tue, Jun 23, 2020 at 01:14:43PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > > The v3 patchset implements an unconditional shift of the #VC IST entry > > in the NMI handler, before it can trigger a #VC exception. > > Going by that other thread -- where you said that any memory access can > trigger a #VC, there just isn't such a guarantee. As I wrote in the other mail, this can only happen when SNP gets enabled (which i...

Sometime my mongrel server threads..would simply stop responding to the requests...and in the logs i get following error: Tue Sep 05 03:56:40 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:21 IST 2006: ERROR: Transport endpoint is not connected - getpeername(2) Tue Sep 05 03:59:47 IST 2006: ERROR: Transport endpoi...

Hallo Liste Derzeit mache ich meine ersten Gehversuche mit Linux (SuSE). Bis jetzt habe ich in einem kleinen Netzwerk f?r meine Tauchschule vier Rechner betreut. Einer davon war WinNT-4.0 Server und Arbeitsplatz zugleich. Nachdem ich nicht mehr bereit bin, mich mit dem w?chentlichen "blue screen" un...

...+0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 01:30:07PM +0200, Joerg Roedel wrote: > But you cannot do a recursion check in #VC, because the NMI can happen > on the first instruction of #VC, before we can increment our counter, > and then the #VC can happen on NMI because the IST stack is a goner, and > we're fscked again (or on a per-cpu variable we touch in our elaborate > NMI setup, etc..). No, the recursion check is fine, because overwriting an already used IST stack doesn't matter (as long as it can be detected) if we are going to panic anyway. It doesn&...

On Tue, Jun 23, 2020 at 03:03:22PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: > > On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: > > > If SNP is the sole reason #VC needs to be IST, then I'd strongly urge > > > you to only make it IST if/when you try and make SNP happen, not before. > > > > It is not the only reason, when ES guests gain debug register support > > then #VC also needs to be IST, because #DB can be promoted into #VC > > then...

...t; wrote: > > On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel <joro at 8bytes.org> wrote: > > > > On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > > > I assume the race you mean is: > > > > > > #VC > > > Immediate NMI before IST gets shifted > > > #VC > > > > > > Kaboom. > > > > > > How are you dealing with this? Ultimately, I think that NMI will need > > > to turn off IST before engaging in any funny business. Let me ponder > > > this a bit. > > > &g...