diff mbox series

[2/2] s390: mm: Fix secure storage access exception handling

Message ID 20210119100402.84734-3-frankja@linux.ibm.com (mailing list archive)
State New, archived
Headers show
Series s390: uv: small UV fixes | expand

Commit Message

Janosch Frank Jan. 19, 2021, 10:04 a.m. UTC
Turns out that the bit 61 in the TEID is not always 1 and if that's
the case the address space ID and the address are
unpredictable. Without an address and it's address space ID we can't
export memory and hence we can only send a SIGSEGV to the process or
panic the kernel depending on who caused the exception.

Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers")
Cc: stable@vger.kernel.org
---
 arch/s390/mm/fault.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

Comments

Cornelia Huck Jan. 19, 2021, 4:24 p.m. UTC | #1
On Tue, 19 Jan 2021 11:38:10 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 1/19/21 11:25 AM, Christian Borntraeger wrote:
> > 
> > 
> > On 19.01.21 11:04, Janosch Frank wrote:  
> >> Turns out that the bit 61 in the TEID is not always 1 and if that's
> >> the case the address space ID and the address are
> >> unpredictable. Without an address and it's address space ID we can't
> >> export memory and hence we can only send a SIGSEGV to the process or
> >> panic the kernel depending on who caused the exception.
> >>
> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> >> Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers")
> >> Cc: stable@vger.kernel.org  
> > 
> > Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>  
> 
> Thanks!
> 
> > 
> > some small things to consider (or to reject)
> >   
> >> ---
> >>  arch/s390/mm/fault.c | 14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >>
> >> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> >> index e30c7c781172..5442937e5b4b 100644
> >> --- a/arch/s390/mm/fault.c
> >> +++ b/arch/s390/mm/fault.c
> >> @@ -791,6 +791,20 @@ void do_secure_storage_access(struct pt_regs *regs)
> >>  	struct page *page;
> >>  	int rc;
> >>  
> >> +	/* There are cases where we don't have a TEID. */
> >> +	if (!(regs->int_parm_long & 0x4)) {
> >> +		/*
> >> +		 * Userspace could for example try to execute secure
> >> +		 * storage and trigger this. We should tell it that it
> >> +		 * shouldn't do that.  
> > 
> > Maybe something like
> > 		/*
> > 		 * when this happens, userspace did something that it

s/when/When/ :)

> > 		 * was not supposed to do, e.g. branching into secure
> > 		 * secure memory. Trigger a segmentation fault.  
> >> +		 */  
> 
> Sounds good
> 
> >> +		if (user_mode(regs)) {
> >> +			send_sig(SIGSEGV, current, 0);
> >> +			return;
> >> +		} else
> >> +			panic("Unexpected PGM 0x3d with TEID bit 61=0");  
> > 
> > use BUG instead of panic? That would kill this process, but it allows
> > people to maybe save unaffected data.  
> 
> That would make sense, will do

With BUG():

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Heiko Carstens Jan. 20, 2021, 1:42 p.m. UTC | #2
On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
> > +		if (user_mode(regs)) {
> > +			send_sig(SIGSEGV, current, 0);
> > +			return;
> > +		} else
> > +			panic("Unexpected PGM 0x3d with TEID bit 61=0");
> 
> use BUG instead of panic? That would kill this process, but it allows
> people to maybe save unaffected data.

It would kill the process, and most likely lead to deadlock'ed
system. But with all the "good" debug information being lost, which
wouldn't be the case with panic().
I really don't think this is a good idea.
Christian Borntraeger Jan. 20, 2021, 2:39 p.m. UTC | #3
On 20.01.21 14:42, Heiko Carstens wrote:
> On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
>>> +		if (user_mode(regs)) {
>>> +			send_sig(SIGSEGV, current, 0);
>>> +			return;
>>> +		} else
>>> +			panic("Unexpected PGM 0x3d with TEID bit 61=0");
>>
>> use BUG instead of panic? That would kill this process, but it allows
>> people to maybe save unaffected data.
> 
> It would kill the process, and most likely lead to deadlock'ed
> system. But with all the "good" debug information being lost, which
> wouldn't be the case with panic().
> I really don't think this is a good idea.
> 

My understanding is that Linus hates panic for anything that might be able
to continue to run. With BUG the admin can decide via panic_on_oops if
debugging data or runtime data is more important. But mm is more on your
side, so if you insist on panic we can keep it.
Heiko Carstens Jan. 20, 2021, 3:24 p.m. UTC | #4
On Wed, Jan 20, 2021 at 03:39:14PM +0100, Christian Borntraeger wrote:
> On 20.01.21 14:42, Heiko Carstens wrote:
> > On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
> >>> +		if (user_mode(regs)) {
> >>> +			send_sig(SIGSEGV, current, 0);
> >>> +			return;
> >>> +		} else
> >>> +			panic("Unexpected PGM 0x3d with TEID bit 61=0");
> >>
> >> use BUG instead of panic? That would kill this process, but it allows
> >> people to maybe save unaffected data.
> > 
> > It would kill the process, and most likely lead to deadlock'ed
> > system. But with all the "good" debug information being lost, which
> > wouldn't be the case with panic().
> > I really don't think this is a good idea.
> > 
> 
> My understanding is that Linus hates panic for anything that might be able
> to continue to run. With BUG the admin can decide via panic_on_oops if
> debugging data or runtime data is more important. But mm is more on your
> side, so if you insist on panic we can keep it.

I prefer to have good debug data - and when we are reaching this
panic, then we _most_ likely have data corruption anywhere (wrong
pointer?). So it seems to be best to me to shutdown the machine
immediately in order to avoid any further corruption instead of hoping
that the system stays somehow alive.

Furthermore a panic is easily detectable by a watchdog, while a BUG
may put the system into a limbo state where the real workload doesn't
work anymore, but the keepalive process does. I don't think this is
desirable.
diff mbox series

Patch

diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index e30c7c781172..5442937e5b4b 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -791,6 +791,20 @@  void do_secure_storage_access(struct pt_regs *regs)
 	struct page *page;
 	int rc;
 
+	/* There are cases where we don't have a TEID. */
+	if (!(regs->int_parm_long & 0x4)) {
+		/*
+		 * Userspace could for example try to execute secure
+		 * storage and trigger this. We should tell it that it
+		 * shouldn't do that.
+		 */
+		if (user_mode(regs)) {
+			send_sig(SIGSEGV, current, 0);
+			return;
+		} else
+			panic("Unexpected PGM 0x3d with TEID bit 61=0");
+	}
+
 	switch (get_fault_type(regs)) {
 	case USER_FAULT:
 		mm = current->mm;