All of lore.kernel.org
 help / color / mirror / Atom feed
From: Collin Walling <walling@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Cc: frankja@linux.ibm.com, david@redhat.com, cohuck@redhat.com,
	pasic@linux.ibm.com, borntraeger@de.ibm.com, mst@redhat.com,
	pbonzini@redhat.com, sumanthk@linux.ibm.com,
	mihajlov@linux.ibm.com, rth@twiddle.net
Subject: Re: [PATCH v5 3/8] s390/sclp: read sccb from mem based on provided length
Date: Fri, 11 Sep 2020 14:16:27 -0400	[thread overview]
Message-ID: <2b7a8807-279f-1256-e89b-0f53ae6d5623@linux.ibm.com> (raw)
In-Reply-To: <811e906a-689e-a53c-706e-5d6217ef3cb2@linux.ibm.com>

On 9/10/20 1:56 PM, Collin Walling wrote:
> On 9/10/20 1:50 PM, Thomas Huth wrote:
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> The header contained within the SCCB passed to the SCLP service call
>>> contains the actual length of the SCCB. Instead of allocating a static
>>> 4K size for the work sccb, let's allow for a variable size determined
>>> by the value in the header. The proper checks are already in place to
>>> ensure the SCCB length is sufficent to store a full response and that
>>> the length does not cross any explicitly-set boundaries.
>>>
>>> Signed-off-by: Collin Walling <walling@linux.ibm.com>
>>> ---
>>>  hw/s390x/event-facility.c |  2 +-
>>>  hw/s390x/sclp.c           | 58 ++++++++++++++++++++++-----------------
>>>  include/hw/s390x/sclp.h   |  2 +-
>>>  3 files changed, 35 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
>>> index 645b4080c5..ed92ce510d 100644
>>> --- a/hw/s390x/event-facility.c
>>> +++ b/hw/s390x/event-facility.c
>>> @@ -213,7 +213,7 @@ static uint16_t handle_sccb_read_events(SCLPEventFacility *ef, SCCB *sccb,
>>>  
>>>      event_buf = &red->ebh;
>>>      event_buf->length = 0;
>>> -    slen = sizeof(sccb->data);
>>> +    slen = sccb_data_len(sccb);
>>>  
>>>      rc = SCLP_RC_NO_EVENT_BUFFERS_STORED;
>>>  
>>> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
>>> index 69a8724dc7..cb8e2e8ec3 100644
>>> --- a/hw/s390x/sclp.c
>>> +++ b/hw/s390x/sclp.c
>>> @@ -231,25 +231,30 @@ int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb,
>>>  {
>>>      SCLPDevice *sclp = get_sclp_device();
>>>      SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
>>> -    SCCB work_sccb;
>>> -    hwaddr sccb_len = sizeof(SCCB);
>>> +    SCCBHeader header;
>>> +    SCCB *work_sccb;
>>
>> I'd maybe use "g_autofree SCCB *work_sccb = NULL" so you don't have to
>> worry about doing the g_free() later.
> 
> Can do.
> 
>>
>>> -    s390_cpu_pv_mem_read(env_archcpu(env), 0, &work_sccb, sccb_len);
>>> +    s390_cpu_pv_mem_read(env_archcpu(env), 0, &header, sizeof(SCCBHeader));
>>> +
>>> +    work_sccb = g_malloc0(header.length);
>>
>> Please use be16_to_cpu(header.length) here as well.
> 
> Good catch, thanks!
> 

Shouldn't the mallocs use cpu_to_be16 instead since the header length
was read in from a cpu?

[...]

-- 
Regards,
Collin

Stay safe and stay healthy


  reply	other threads:[~2020-09-11 18:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10  9:36 [PATCH v5 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318 Collin Walling
2020-09-10  9:36 ` [PATCH v5 1/8] s390/sclp: get machine once during read scp/cpu info Collin Walling
2020-09-10  9:36 ` [PATCH v5 2/8] s390/sclp: rework sclp boundary checks Collin Walling
2020-09-10 17:45   ` Thomas Huth
2020-09-11 10:24     ` Cornelia Huck
2020-09-11 14:50       ` Collin Walling
2020-09-10  9:36 ` [PATCH v5 3/8] s390/sclp: read sccb from mem based on provided length Collin Walling
2020-09-10 17:50   ` Thomas Huth
2020-09-10 17:56     ` Collin Walling
2020-09-11 18:16       ` Collin Walling [this message]
2020-09-12  6:28         ` Thomas Huth
2020-09-15 14:27           ` Collin Walling
2020-09-10  9:36 ` [PATCH v5 4/8] s390/sclp: check sccb len before filling in data Collin Walling
2020-09-10  9:36 ` [PATCH v5 5/8] s390/sclp: use cpu offset to locate cpu entries Collin Walling
2020-09-11  4:33   ` Thomas Huth
2020-09-11 10:36   ` Cornelia Huck
2020-09-10  9:36 ` [PATCH v5 6/8] s390/sclp: add extended-length sccb support for kvm guest Collin Walling
2020-09-11 10:47   ` Cornelia Huck
2020-09-11 13:41   ` Thomas Huth
2020-09-11 13:54     ` Thomas Huth
2020-09-11 14:52       ` Collin Walling
2020-09-10  9:36 ` [PATCH v5 7/8] s390/kvm: header sync for diag318 Collin Walling
2020-09-10 11:09   ` Cornelia Huck
2020-09-10  9:36 ` [PATCH v5 8/8] s390: guest support for diagnose 0x318 Collin Walling
2020-09-11 15:08   ` Thomas Huth
2020-09-11 15:14     ` Thomas Huth
2020-09-15 14:57     ` Collin Walling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b7a8807-279f-1256-e89b-0f53ae6d5623@linux.ibm.com \
    --to=walling@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=mihajlov@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sumanthk@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.