From owner-svn-src-user@FreeBSD.ORG Mon May 5 05:02:10 2014 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94361848; Mon, 5 May 2014 05:02:10 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D787B1D7B; Mon, 5 May 2014 05:02:09 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z11so4857584lbi.36 for ; Sun, 04 May 2014 22:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=AkKFcyqaiha0MC0YuHCN+nfsaASB9dX5/llbx3mjjjI=; b=uWJtoqtc0Asrwl8sm6yeiO9q4YE3Pu8+vN3XCK4PnA1MSsEGgo90tws7M2sAyoPT+a S6scwbk9NIXV7+wgfTDQnUVeMxVvvnaU3ECOsB6yW7L3Ru0i2r/fv0gGRnTKLw2kXQN+ cb/V16TlX0lRXOdM1g5+2uJxp8QVtq9PCLqlh6eVE2XClmAFAwxcSrDLVolDttpMNoMz lCKY+rdUYyLEghNwc6i9dLqfmtcjCannex+RBS5SeLj2Q4fvbu4JfIHrH3YCNZcBXQxz xTc3GURamnpNa8z2HXt03GDLHa8oxkY1aAW9szmsm/TrDEeTaENWjcqdpBHEZwtiJYQ8 1Kcg== X-Received: by 10.112.126.7 with SMTP id mu7mr23832976lbb.17.1399266127568; Sun, 04 May 2014 22:02:07 -0700 (PDT) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru. [78.107.232.239]) by mx.google.com with ESMTPSA id ms3sm8281164lbb.17.2014.05.04.22.02.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 May 2014 22:02:06 -0700 (PDT) Sender: Dmitry Chagin Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.8/8.14.8) with ESMTP id s45524pH001628; Mon, 5 May 2014 09:02:04 +0400 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.8/8.14.8/Submit) id s45524S2001627; Mon, 5 May 2014 09:02:04 +0400 (MSK) (envelope-from dchagin) Date: Mon, 5 May 2014 09:02:04 +0400 From: Chagin Dmitry To: Mateusz Guzik Subject: Re: svn commit: r265327 - in user/dchagin/lemul/sys: amd64/linux amd64/linux32 compat/linux conf i386/linux modules/linux modules/linux64 Message-ID: <20140505050204.GA1307@dchagin.static.corbina.net> References: <201405041559.s44FxWdj053353@svn.freebsd.org> <20140504180749.GA17835@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20140504180749.GA17835@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:02:10 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 04, 2014 at 08:07:49PM +0200, Mateusz Guzik wrote: > On Sun, May 04, 2014 at 03:59:32PM +0000, Dmitry Chagin wrote: > > Author: dchagin > > Date: Sun May 4 15:59:32 2014 > > New Revision: 265327 > > URL: http://svnweb.freebsd.org/changeset/base/265327 > >=20 > > Log: > > Implement epoll family system calls. This is a tiny wrapper around kq= ueue > > to implement epoll subset of functionality. The kqueue user data are > > 32bit on i386 which is not enough for epoll user data, so we keep user > > data in the proc emuldata. > > =20 > > Initial patch developed by rdivacky in 2007, then extended by > > Yuri Victorovich @ r255672 and finished by me. > >=20 >=20 > I'm not happy with this. The code is full of fp <-> fd lookup races. >=20 Hi, Mateusz. Thanks for the reply. As far as I understand you, check epfd against fd is useless. FreeBSD does not check that it's the same file.But we must. Is it correct?: diff --git a/sys/compat/linux/linux_event.c b/sys/compat/linux/linux_event.c index ee70b9c..054df14 100644 --- a/sys/compat/linux/linux_event.c +++ b/sys/compat/linux/linux_event.c @@ -339,9 +339,6 @@ linux_epoll_ctl(struct thread *td, struct linux_epoll_c= tl_args *args) int nchanges =3D 0; int error; =20 - if (args->epfd =3D=3D args->fd) - return (EINVAL); - if (args->op !=3D LINUX_EPOLL_CTL_DEL) { error =3D copyin(args->event, &le, sizeof(le)); if (error !=3D 0) @@ -359,6 +356,12 @@ linux_epoll_ctl(struct thread *td, struct linux_epoll_= ctl_args *args) if (error !=3D 0) goto leave1; =20 + /* Linux disallows spying on himself */ + if (epfp =3D=3D fp) { + error =3D EINVAL; + goto leave0; + } + ciargs.changelist =3D kev; =20 switch (args->op) { > Example: >=20 > linux_epoll_ctl > if (args->epfd =3D=3D args->fd) > return (EINVAL); > [..] > error =3D fget(td, args->epfd, &rights, &epfp); > if (error !=3D 0) > return (error); >=20 > /* Protect user data vector from incorrectly supplied fd. */ > error =3D fget(td, args->fd, &rights, &fp); > if (error !=3D 0) > goto leave1; >=20 > fds could resolve to the same fp right from the start and even if that > was note done an attacker could arrange that after the check. >=20 > There is no validation you got epoll fd either. >=20 > Further down: > switch (args->op) { > case LINUX_EPOLL_CTL_MOD: > /* > * We don't memorize which events were set for this FD > * on this level, so just delete all we could have set: > * EVFILT_READ and EVFILT_WRITE, ignoring any errors > */ > error =3D epoll_delete_all_events(td, epfp, args->fd); >=20 > Again a lookup. >=20 > Whether this particular problem could be used to do something nasty I don= 't > know, but playing like this is asking for trouble. >=20 > The only solution I see is to modify kqueue functions to accept fps. >=20 reason? to prevent extra fget? or something else? --=20 Have fun! chd --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNnG0wACgkQ0t2Tb3OO/O2PuwCfauKJvtLm+crix2mZFef8JMxu 2bkAoL4pn6gZZwydAeVQlS/HLQef5bWV =EmRZ -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--