From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14048 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jewell Seay Newsgroups: gmane.linux.lib.musl.general Subject: RE: Changes for upstream? Date: Tue, 2 Apr 2019 20:24:15 +0000 Message-ID: References: <20190402195830.GN23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171162"; mail-complaints-to="usenet@blaine.gmane.org" To: "musl@lists.openwall.com" Original-X-From: musl-return-14064-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 02 22:24:37 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hBPxV-000iHV-Fc for gllmg-musl@m.gmane.org; Tue, 02 Apr 2019 22:24:37 +0200 Original-Received: (qmail 22276 invoked by uid 550); 2 Apr 2019 20:24:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22237 invoked from network); 2 Apr 2019 20:24:28 -0000 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=HkYfWok7lXAkTWmlCtrF0NdJSzrIn8CuHjiFZ3zBARW0CZdDkTAJdIoyjQt93rue3GsSWlIAgUOD0NSTHezsFSt8qOuQNV8+T/y2E/fbNGQLnHhmZ9tYyBr8X0lGoE+urD2QvUK4g2rvJxtlG7W7Q4aYVb+vo2ag8zTk1tsKoDY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DimTXtnFrRyueVqVXbWKOkJIN3Nsz3gpYuCudKpXg3E=; b=r+61fJzX0RmY+nhg94OlUV7UKzlMqJOG1PpXHsI8vir7fvWOO7k0WdMYXLPLxhmNt/ltckaS9uM5305TRTbPeYUKFYknaHmMHW2TjrEWaLlppkpGsB0qYp0pyiJvrFhFz3aAI5FLdjAjsHgDfj5eAqbfegUhckPpxM+m/tXurN0= ARC-Authentication-Results: =?us-ascii?Q?i=3D1;_test.office365.com_1;=0D=0A=09=09dmarc=3Dnone_action?= =?us-ascii?Q?=3Dnone_header.from=3Dmicrosoft.com;=0D=0A=09=09arc=3Dnone?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DimTXtnFrRyueVqVXbWKOkJIN3Nsz3gpYuCudKpXg3E=; b=HG9ZbB3fc2lQU5wGA7Hh+XVSR6NUegz/bKBO1Q6tL8Ry8Hy/pVpNvvv3QIffjEIt6XshzzEtmLZ1EWIiyNNS0tz1KFRJgDwio4ISXAUvoYwvxbRbTP6GuF7RSVPc2EJ2JWM3ywlLFivYBVV1oAnK/CMXlwQ1GpEZ9zWYc4sKRCM= Thread-Topic: [musl] Changes for upstream? Thread-Index: AdTph9ZrGB4BR8N4QGyc/BtSvL/8dAABpscAAABe0tA= In-Reply-To: <20190402195830.GN23599@brightrain.aerifal.cx> Accept-Language: en-US Content-Language: en-US msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=jeseay@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-02T20:24:14.0513201Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=24c9a846-0bf1-4900-9030-2770d680984d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jewell.Seay@microsoft.com; x-originating-ip: [2001:4898:80e8:0:8e22:78b6:2014:1697] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36ab1bd2-2761-49ca-049c-08d6b7a92d43 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020);SRVR:MN2PR21MB1229; x-ms-traffictypediagnostic: MN2PR21MB1229: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(39860400002)(136003)(346002)(396003)(376002)(199004)(189003)(71190400001)(97736004)(6116002)(6436002)(10090500001)(2501003)(446003)(6916009)(53936002)(8936002)(1730700003)(102836004)(46003)(86612001)(86362001)(5640700003)(81166006)(81156014)(8990500004)(52536014)(11346002)(476003)(9686003)(6246003)(229853002)(55016002)(8676002)(14454004)(7736002)(7696005)(68736007)(486006)(99286004)(478600001)(5660300002)(14444005)(33656002)(71200400001)(76176011)(25786009)(105586002)(186003)(10290500003)(74316002)(106356001)(72206003)(316002)(256004)(2351001)(22452003)(2906002)(305945005)(6506007);DIR:OUT;SFP:1102;SCL:1;SRVR:MN2PR21MB1229;H:MN2PR21MB1231.namprd21.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LeXtYvQ/9ewRYRMTF3/NYo09eOUJLEwq3+WPeBEZpRuBd0WAwFugkgT6/lhyB5dsklW/5pQ9eA8DvMi99oy1ZGETGy1bG5hrLyw1RkUbNyG6Pj2mq24nOw2YjbklM11vfkL0O1IBu2xBfQyalRapZ+6iCX60s/4OVX85g8woKqOkA+Pmou1RdAnXcm1Ec5OV96vXyL89pPFhI1ESgm+qFRsrzwRqe6QInXE+mEsnfJVR5pSjWatW7jFhtsB2QMEkY1uy3xYwKIl+heDaO41Ye0q6CQQapfGSIvNI0d002lbHc1mOuqLIf/3v5LtVU882Rwi5MRUyDlW0+vJ16A35O43uBpLwkouET9b/7YjIP9aa1WUPDQqxFCXcfurYZngYQFRzJmNJ+QKz7RGkoeEovrnJ9zAo9UpIrLe3hL75bXo= X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36ab1bd2-2761-49ca-049c-08d6b7a92d43 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 20:24:15.5647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR21MB1229 Xref: news.gmane.org gmane.linux.lib.musl.general:14048 Archived-At: > On Tue, Apr 02, 2019 at 07:11:14PM +0000, Jewell Seay wrote: > > Hello, > > > > The team I am on is in the beginning stages of making the following > > changes to musl, would upstream desire any of these? > > > > - Heap hardening: adding cookies and validation to increase the > > likelihood of crashing if someone corrupts heap memory (as a security > > mitigation). >=20 > Additional validation is desirable, but the existing malloc implementatio= n in > musl is not intended to be kept long-term, so doing and reviewing work on= it > is maybe not a good use of time... Thank you for the heads up. >=20 > > - Randomizing library locations in memory (while keeping the ordering > > of module _init and _fini calls stable). >=20 > I'm confused why this would be in musl and not just by the kernel's norma= l > ASLR. On 32-bit you really can't randomize positions because the address > space is just too small, but on 64-bit, doing strong mmap ASLR in the ker= nel > would get you this for free. Do you have a different/better method in min= d > that could be achieved in the dynamic linker but not in the kernel? >=20 We have already modified the kernel under ARM to have a wider ASLR range, h= owever this does not improve the Linux design where libraries are loaded in= -order in memory by the dynamic loader. A single address leak of a library = location allows easy address calculation to any other library for rop gadge= ts. Although the 32-bit address space is small, shuffling the order the lib= raries are located in memory results in more complex leaks being required t= o obtain needed library addresses for exploitation. It is more specific to our system as any normal system can just load a libr= ary to a random location while we are attempting to minimize cache hits so = there is a desire on our side to group them together just in different orde= rs. =20 > > - Shrink the memory footprint of the DATA and BSS sections. >=20 > That would be nice, but for the most part I don't think any further reduc= tion > is possible without introducing places where no forward progress is possi= ble > because memory needed was not reserved in advance. Obviously the stdio > buffer sizes could be decreased but that would hurt performance a lot. >=20 Thank you for the heads up. Our current build shows 2 pages of memory being= used and we are attempting to get it down to 1 page due to memory impact. > > - Return memory to the kernel within free(). >=20 > This is already done via MADV_DONTNEED. Using MADV_FREE has been > suggested recently and would probably be a good idea; it looks like it co= uld > be swapped in without any complex work. There are also a few past threads > where I discussed a desire to return not just the dirty page pressure, bu= t the > commit charge, to the kernel when there are huge free chunks. There are > tradeoffs involved, and with the current allocator slated to be replaced,= I > didn't really want to spend a lot of effort considering how they'd fit in= with it. >=20 What allocator do you plan to go to or are there plans to have one created = from scratch? > > The other question we have is that it does not appear that there is > > any standard way in musl to have certain functionality turned on or > > off. If any of these changes are desired to be optional then is there > > an accepted method for enabling or disabling the feature? >=20 > It's intentional that we don't have functionality switches, but of course= due > to CFLAGS various degrees of hardeing are already possible (stack protect= or, > stack clash check, etc., even UBSan) so it's conceivable that we could ad= d > things that require conditionals at the source level. Any such things sho= uld > not affect the exposed interfaces or the observable behavior of programs > with well-defined behavior. But ideally good hardening measures are > sufficiently inexpensive that making them optional is not needed. The mai= n > cost, which should always be minimized, is the source-level complexity, a= nd > that's same or worse when they're optional. >=20 If I am understanding correctly, any useful hardening measures should just = expect to be on and not an optional compilation flag.