From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D56F168 for ; Thu, 8 Jul 2021 19:49:28 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id n14so18481122lfu.8 for ; Thu, 08 Jul 2021 12:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YqCcKMfCn6KIf6YzKQ50P7XM3AkVJWZbm2YLWSRDFO8=; b=JSp1DSgGVEX097wmsT3YRPbTWWVcXJYz3Jcj6RkuNrwq0mQ6KX4iiuqaEpHpF1fSCN f4buIJqejVZQ0yWxKarTohJ1WXOl82v9be7OZldjh6YsQcm0bu3oTXxgPFDWOQifYqMl o7z3z9YkqxYakTrAdtT/ylBlzEgvVjZvDD6ugpAio+G8wA+IY2BawHcjwuzj7TEJj/w8 U35W+6LMf3Kjv1fZmgb04hXszm+KdZX+zpPdEIOjpds0JZphBkmv8HUKhyDLzoL29gu9 5/9ac6S8QPvRRSxDohJJVoKQcrBjXfG5Zx8LhdCd/0n/ED4AuD8H83SXTX63Azpm41BM UmYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YqCcKMfCn6KIf6YzKQ50P7XM3AkVJWZbm2YLWSRDFO8=; b=mYaZfUs1gFiFIPjLPKCpyu21WdsUVyxtmdwidmAMq4S0+OuD9Up0egtvcdPy7xDlyQ lfQKdvkx0Iwr6FMbCBc2C5Q4/QjgqyBW0cUZGsFzE483/EwZWF2H57+ECH3fiEqsUbOF tHt/2zLFCcbv8DCw0sV8m6KjiKqMFWA/w6Jk0DctflU+b00RpY+Tc4lMMMw/rQc+7UgR SGH/b6az0Pr4Zc9LXADV9vm1D8oMUYSyQZjXdta7ZPVDiXouHvyMPUmE/jY4wQvEsxRa y+MX5Di/KA2itZ940Di2ifTizqOwz56dOrA3udAU42IDXhLW1USLq+Z+apN0jWgr+N85 crog== X-Gm-Message-State: AOAM5300eh4nRTyOOVeQsCyBEDUF0ZHF1rFwoMyrxPGhsLuigRgSZoB5 y3cn0JGH5Q6+WmWYto+LXjnsQlHy2L/oRq3wPFTo5w== X-Google-Smtp-Source: ABdhPJzuhk5BLOs63yD16rGtD2cyvi31+EFTRUjEjvehiI7OOl6mh0Xgm2mIoCJBNrTyPd8Muuzx7vnForPpA7r4RKY= X-Received: by 2002:a05:6512:1508:: with SMTP id bq8mr25990719lfb.529.1625773766614; Thu, 08 Jul 2021 12:49:26 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <1f2a62c19845e4602817c2130d47bbea02d04d1d.camel@HansenPartnership.com> <20210707203827.GI18396@quack2.suse.cz> In-Reply-To: From: Linus Walleij Date: Thu, 8 Jul 2021 21:49:15 +0200 Message-ID: Subject: Re: [TECH TOPIC] Rust for Linux To: Greg KH , Bartosz Golaszewski , Kees Cook Cc: Wedson Almeida Filho , Jan Kara , Miguel Ojeda , James Bottomley , Julia Lawall , Laurent Pinchart , Roland Dreier , ksummit@lists.linux.dev, Viresh Kumar Content-Type: text/plain; charset="UTF-8" On Thu, Jul 8, 2021 at 8:51 PM Greg KH wrote: > But if you didn't like the previous examples (nvme block driver, i2c > driver, gpio driver), how about looking at the drivers used by your > current desktop and picking something that you use today that actually > talks to hardware? With my GPIO maintainer hat on I'd say a GPIO driver would be quite interesting to look at. We are two GPIO maintainers and Bartosz is doing the heavy lifting for the moment so I'm connecting Bartosz to this discussion. (Now he has to read through the whole backlog, sorry Bart!) This is not to say I promise we will merge it or so, but I just generically like new approaches to old problems so I like this whole thing overall, despite being critical to some details. I am also trying to learn Rust. Baby steps. I also Cced Viresh Kumar who I think is thinking about Rust these days, using it for one end of a virtio pipe (IIUC) and Andy also brought up virtio, but now on the other side, in the kernel. My concern is still whether this really brings Rust closer to the actual problems we have and that Rust can solve. If the problem is really about real world security issues, I would ask Kees where the actual attack surface of the kernel is. He knows. It kind of matters. EternalBlue (WannaCry) was a horrific Windows exploit in that it shows us pretty well what kind of cyberweapons the intelligence agencies of the world have been constructing and stockpiling, and probably also used. We need to put countermeasures where such exploits are likely to hit, yesterday. Intuitively I would say any in-kernel network daemons, anything complex that responds directly to network traffic, is a good thing to fix. I do not know why people are so hung up on device drivers. I would look at something like fs/nfsd or what else is there that act like this? ksmbd is out-of-tree. Maybe contribute ksmbd in the form of Rust and show how nicely this implementation of SMB avoid all the dangers exposed in WannaCry for Windows? That kind of stuff would build real trust. KSMBD in C is there: https://github.com/namjaejeon/ksmbd If the problem is security in the sense of being secure from random crashes and general instability, drivers is an as good place to start as any. Yours, Linus Walleij