lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Apr 2022 17:29:27 +0200 From: Juergen Gross <jgross@...e.com> To: Boris Ostrovsky <boris.ostrovsky@...cle.com>, xen-devel@...ts.xenproject.org, linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org Cc: Stefano Stabellini <sstabellini@...nel.org>, "James E.J. Bottomley" <jejb@...ux.ibm.com>, "Martin K. Petersen" <martin.petersen@...cle.com> Subject: Re: [PATCH 4/4] xen/scsifront: harden driver against malicious backend On 21.04.22 12:13, Juergen Gross wrote: > On 20.04.22 18:13, Boris Ostrovsky wrote: >> Just a couple of nits. >> >> >> On 4/20/22 5:25 AM, Juergen Gross wrote: >>> -static int scsifront_ring_drain(struct vscsifrnt_info *info) >>> +static int scsifront_ring_drain(struct vscsifrnt_info *info, >>> + unsigned int *eoiflag) >>> { >>> - struct vscsiif_response *ring_rsp; >>> + struct vscsiif_response ring_rsp; >>> RING_IDX i, rp; >>> int more_to_do = 0; >>> - rp = info->ring.sring->rsp_prod; >>> - rmb(); /* ordering required respective to dom0 */ >>> + rp = READ_ONCE(info->ring.sring->rsp_prod); >>> + virt_rmb(); /* ordering required respective to backend */ >>> + if (RING_RESPONSE_PROD_OVERFLOW(&info->ring, rp)) { >>> + scsifront_set_error(info, "illegal number of responses"); >> >> >> In net and block drivers we report number of such responses. (But not in usb) > I'm not sure the specific value is of any interest. > >>> + return 0; >>> + } >>> for (i = info->ring.rsp_cons; i != rp; i++) { >>> - ring_rsp = RING_GET_RESPONSE(&info->ring, i); >>> - scsifront_do_response(info, ring_rsp); >>> + RING_COPY_RESPONSE(&info->ring, i, &ring_rsp); >>> + scsifront_do_response(info, &ring_rsp); >>> + if (info->host_active == STATE_ERROR) >>> + return 0; >>> + *eoiflag = 0; >> >> >> *eoiflags &= ~XEN_EOI_FLAG_SPURIOUS; ? > > Yes, probably better. > >> We also use eoi_flags name in other instances in this file. > > I'll unify the name. Oh, eoi_flags is used in the backend driver. So nothing to unify. Juergen Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes) Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists