From owner-freebsd-security@freebsd.org Mon Apr 20 14:22:14 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D73B2C48F5 for ; Mon, 20 Apr 2020 14:22:14 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 495TRT4p7Qz4S5R for ; Mon, 20 Apr 2020 14:22:13 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x835.google.com with SMTP id w29so8550376qtv.3 for ; Mon, 20 Apr 2020 07:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+HyevYGSPR0FvFN4x/fF1TtPZNhzTEf8r4v8SWmrp5E=; b=tynewFQQ5vsa451mwJzsjHdaAFM5+tkoUA83CtzbhqVa/4dLk+MvkXB6WjHsmEdpHc HIF7PDrtLfrryarEC9CsXTQk9c6NjYwReZF9BjJNGTgaWQLm+Fvc0OsBpeQZybAhMQHp FNhhqr/KPz/894CrcBqS0RIRrRwMuVrlPt7aKJJYToiicCH69TNquoqggoEyv2qNtJkG sv9CaxpC0MZguRWdPrX7KSSg+wWxne+JaWNRhIQcI+9WAeBtJyLd7/F95K4saM3Am4Pd CNhlW8VgBZl5nsFaCscQODjvVuyXrZDaP7EieSO7FuxPf3PAdHHQaNy1/HCMuLHgOMS0 um2A== 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:content-transfer-encoding; bh=+HyevYGSPR0FvFN4x/fF1TtPZNhzTEf8r4v8SWmrp5E=; b=XoSek6O4a1QM6faYTYUs6HJyXiKjdMV9FFwO5u8vR7mTEPqWdPjLnNYCRNVfKjfEyJ bdPzE1gmkL8p9aDnhnrEuUn3UZ/p5AgitcMOa/Uq4brwS74Pyuc0qZjQhOPmvd8TBbXZ tm1iATazC+O7r0Rwt3rY+ij6VwIWxrxumIEPHagivFo7ApSWNYvAtPuJBAedTBMp9xqI hdB+49DVQfg8ltR8F5ZxJ7exFm3xcLpKrjS5P1u0WP6lVjErdV1A3cOeJc0h6QZsZNqm g+70kUvxy4fnR034Jm1eSoj3bKS0aIgtbfVG/VsLiYtDv79F9/kri8GlPxVPgELBJOhG Ib9g== X-Gm-Message-State: AGi0Pua08xVWOc8U5ffUcauwpdnxrxAGMtX5YT54BfNtzw3s7VMsV+OS V/M0GINcOBaiHfhMgkYkw3KaLMcXDDjyY6BZncrAbGozLds= X-Google-Smtp-Source: APiQypKjM2ftpASQoPvFjowyBWSA1L5ylOMOmvxl3JY4SzjOmMB2wEBqu0LWgaZ2wlUYu94DGYcS3z0Vb+oolP4WR+s= X-Received: by 2002:aed:3ec2:: with SMTP id o2mr16057862qtf.30.1587392532314; Mon, 20 Apr 2020 07:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Mon, 20 Apr 2020 16:21:59 +0200 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Ed Maste Cc: freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 495TRT4p7Qz4S5R X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=tynewFQQ; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::835) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-4.31 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[5.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.01)[ip: (-9.27), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 14:22:14 -0000 Hi Ed, pt., 17 kwi 2020 o 15:52 Ed Maste napisa=C5=82(a): > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > Hi, > > > > Together with our customers, Semihalf is interested in improving the st= atus > > of security mitigations enablement in FreeBSD. > > Happy to hear that there's interest in this work! > > > 1. Are there any hard blockers, like missing features or bugs, that pre= vent > > enabling ASLR by default in the kernel and building the base system wit= h > > -DWITH_PIE? > > I believe there are no showstopper issues but there are a some > prerequisites. One is that there are some applications that may > misbehave with randomization enabled. They would need to be > identified, and tagged (with the elfctl tool now in the base system). I was thinking if it is possible to come up with such wide test coverage to test every single application from the base system. Do you think it is achievable or should we rather follow the approach to do as many tests as possible, but rely on the community feedback to catch the corner cases (like the ntpd issue mentioned in this thread)? What about the ports? > > > 2. In case the enablement becomes eventually approved, will it be bette= r to > > do it for all archs or focus only on the selected ones? > > There's a general and increasing preference of avoiding different > defaults per architecture. One issue though is that some options may > have much larger performance impacts on certain architectures - e.g. > position independent executables (PIE) on i386. Understood. If there is likely a performance trade-off, how about doing tests e.g. on i386 and armv7? In case of a big drop or other issues, could limiting ALSR/PIE to 64-bit-only be a considered solution? > > > 3. IMO it may be worth to benchmark/stress the system for the stability > > verification and perf comparison purpose. Do you think it may be reason= able > > to create a kind of reference matrix (archs vs tests)? Those could be d= one > > to evaluate the current state of the OS, but also for validating each > > proposed feature. I also think engaging the FreeBSD CI might be a huge = help > > in such an effort. BTW, any particular tests / benchmarks come to your = mind > > as useful in this case? > > Yes, benchmarking and testing are very important tasks on a path to > enabling these by default. I agree with the CI comment; we should > start with CI build + kyua runs with options turned on, in advance of > changing the default. Indeed I thought of kyua and measuring buildworld execution time for stressing the DUT and having the first comparison numbers for the low price. Do you think it is possible to get help here, i.e. is there a FreeBSD devops team, maintaining the Jenkins CI whose spare cycles could be used for this purpose? Or is this a field requiring external help from interested parties? Even before the automation, would it be useful to perform some runs on chosen archs? > > I would be interested in seeing macro-level benchmarking with > mitigations on/off - for example, I assume Firefox must have a > performance test suite that they use for tracking their own > performance changes during development, and we could use benchmarks > like that to see the impact of mitigations. Coming up with a full set > of appropriate benchmarks will be a useful endeavour. Yes, making use of something actively maintained would be great. Do you see a need for IO stressing/benchmarking for the discussed cases? Best regards, Marcin