From owner-freebsd-security@freebsd.org Thu Apr 23 10:54:16 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 5EBE12B1B12 for ; Thu, 23 Apr 2020 10:54:16 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 497Dh71Km7z4q6v for ; Thu, 23 Apr 2020 10:54:14 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x831.google.com with SMTP id w29so4461785qtv.3 for ; Thu, 23 Apr 2020 03:54:14 -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=mr9qCoXxlkwxZN5NUrEaDr65bM7haVFuB6uqLOxrrZE=; b=aikn7QkycGVv2Z8C1mXIDRY5crh6+T0Yykr6yOtJek8DJzkklBohL9006JfmV6NYsA Njz8u8RAyC+15cv7mFwkwBlrpcNbn+tDZ3wa+cd88EVSU+zx3UKTl+czkZ4rGLgM9PsN tV5pJD9qHwOhQxXGVnRJonPxPVupYZHzZZCvK5I9faN2yJV0aVPoII/L1VZPnY9aHSg4 SCLmtYzQmsSSirJuBbXvxdsKEnpn66R2tI35zHHQ+rqejPpUwWNL3oQj2dms//uPskIs Uqnaqjnv9755y6T3Bsd2oLQFYX14u4T0WRP2HwEWvoaLusyCADWms5WXmL9pNItPuoRA PpRg== 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=mr9qCoXxlkwxZN5NUrEaDr65bM7haVFuB6uqLOxrrZE=; b=tmeXUNvW6NQpWKiO4TyR9ynssFZOcuSydt1SU/wIL+Yc0357srBM/o9xgQlW+V0m/T hGVe4eKeNyYVv/wl2gXYWiL38hGgNMaqBnjFCJ7R1oQ8o7FeVA2Oh/mBIMWOve2HzWjl Z8GhtEB31NsMk1WPMU+haeKwqGKbwbFd/B8R9bDUdT1ynpjoQUvXvGnOrA9JjKVlVJuD fdSkrOm+5Ca7zlwj0TvZdFym4RUkD2YwyuI3un8NlWLyXImqbl0+XBO5Io8PT64ys6Td iZ6vHYAcIli/bKdNTlAk4g1EnZEjEZga8sMEu2ig6Qv4w5gLKiGIFc2YcJuiwS6t4VG7 KTtw== X-Gm-Message-State: AGi0Puag6jUZ+Bh3f1YDL2lYRIAKyStG1vqKBIlH/316INeCzmChwqzo zprtr/aFvrLF+/8ehiwYsLoVtyCJco0k2HtpBjG1hGcY X-Google-Smtp-Source: APiQypJEz1oa9XeNEdyzLR6+wBaAzEUoFeKnqmlBjWo6E2/UcBePgZiF/UTupbij/gSz1mI/ElPYbVNyfmpRPXyvbO8= X-Received: by 2002:ac8:4e2c:: with SMTP id d12mr3259759qtw.204.1587639253887; Thu, 23 Apr 2020 03:54:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Thu, 23 Apr 2020 12:54:01 +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: 497Dh71Km7z4q6v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=aikn7Qky; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-4.30 / 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)[1.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.00)[ip: (-9.21), 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: Thu, 23 Apr 2020 10:54:16 -0000 Hi Ed, Any thoughts on the questions below? Best regards, Marcin pon., 20 kwi 2020 o 16:21 Marcin Wojtas napisa=C5=82(a): > > 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 = status > > > 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 p= revent > > > enabling ASLR by default in the kernel and building the base system w= ith > > > -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 bet= ter 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 stabili= ty > > > verification and perf comparison purpose. Do you think it may be reas= onable > > > to create a kind of reference matrix (archs vs tests)? Those could be= done > > > 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 hug= e help > > > in such an effort. BTW, any particular tests / benchmarks come to you= r 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