Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4835182imm; Mon, 14 May 2018 14:04:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpX/0jdnuk6V9Z2aAJ+7rrnnNdGV6DCX7z6fSdvqABO+nGT87KtOcXRmJs0YAKGXmvLEdWL X-Received: by 2002:a17:902:6687:: with SMTP id e7-v6mr5469890plk.242.1526331875713; Mon, 14 May 2018 14:04:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526331875; cv=none; d=google.com; s=arc-20160816; b=weGtdb7oFnMAOOb8lmyV4ZtKoVwtV9gfgS5+1EXi0eTSmh2q9VmDhiwdLecH/MyCkN HFVBtfZ0x6yCCY8Eo4wTg7d5R5eAex5lpqUGYx8g/6HFehbFC7FiQK5o3qXeuB8eBJxQ N0NVV4iWy+WNp9XMGAR+MuqzDCLUn29n3F5HlPs8T+izxfUbb/LVYVL8Dm56w2ruLOQ2 uVp55kZa5AhMA4Tycqs+Vs+VIsNjEY3HINKUrx9un47LIiXRsjZRyIaZWhONMKQtt0FY GvebuepeGf1nQ0fWHQeiJiEsLZl/HLEg9xTrjKAQGijmfKbjRrRoI5JYuUOA6BKdfnCv HZEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=X9g5AuJ12NhKu7PjWVZDU3vzMtDUhAvpkd/QGV063rM=; b=m9BfhxuSBnSnudVrJXkYOsOonYLbst09WheJFivUDhoByAsjz0LdEl7lthzbQPVcJC c2Cobl9a7LdlgTvsH8/n+BHfw0daNNl0HBQ1YztxEGfAPdNf3fFAspawO0qL4NEPSTC+ sB4yRccMs+uqUA7kGT1tQJ4D1x75U8UHgIg52FTFJxTsPKaXpzLKU5AfrFxQ5HJJISng Ycf0IdCWHt6/qIOpapYRLYrAN7MMW1sfRRuF3t0uOx3hMYhTHGohd7caSJ4fWKyWDguy kHjn3/9mg/u6R8em9Svc206IOiWVzJo8vDB2XIvQ/B7qHWtlVU4VAspco8gVr/cngG1H khIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4-v6si10683757pff.159.2018.05.14.14.04.21; Mon, 14 May 2018 14:04:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752328AbeENVCV (ORCPT + 99 others); Mon, 14 May 2018 17:02:21 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:43784 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752179AbeENVCL (ORCPT ); Mon, 14 May 2018 17:02:11 -0400 Received: by mail-ot0-f193.google.com with SMTP id y10-v6so15933279otg.10 for ; Mon, 14 May 2018 14:02:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X9g5AuJ12NhKu7PjWVZDU3vzMtDUhAvpkd/QGV063rM=; b=HK3Uq/vLc8KDH9FZ++/UOc/xJq5nAL53bS/sBhXuzvrETdNU1OI9FAF/J3d6u6w2HP +ig7VB7RUrUJrUxNm4RyzDcJuuLlGn0unwIVBl/bPWyxFH63vJa69R65G3Z3nVTeuKMu UMWCMdYHYhlp+g+ayrOjYmKNcCNShdBBaYpbWYl6f+Fv6+Hf7XTyTN4xHmqJa70VppxM 2ITyOoTuWUioIzdkanaCRVVCm2yct+0s/s21puOhutN6h6lg44VwKdJHp+kUtU9K4S+3 4dUsf0lGYUOFCtMbjN6MmejH5zVnGRFzZFVgq6IlB54N21ysF3GqRPddXWNfBSv8R/yN SQBQ== X-Gm-Message-State: ALKqPwdyghkk7XtqWsQ09fJF7ponJe98SLUciF5xscNUok1Tk9hNIL5x 3Of9i5AzZS22d+xuedrYl+3fVMeu+EA= X-Received: by 2002:a9d:538d:: with SMTP id w13-v6mr7986115otg.188.1526331730287; Mon, 14 May 2018 14:02:10 -0700 (PDT) Received: from ?IPv6:2601:602:9802:a8dc::d2dd? ([2601:602:9802:a8dc::d2dd]) by smtp.gmail.com with ESMTPSA id o9-v6sm5838926oti.58.2018.05.14.14.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 May 2018 14:02:09 -0700 (PDT) Subject: Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections To: Masahiro Yamada Cc: Andy Lutomirski , mjw@fedoraproject.org, "H . J . Lu" , Linus Torvalds , X86 ML , Linux Kernel Mailing List , Nick Clifton , Cary Coutant , Linux Kbuild mailing list References: <20180329180112.11055-1-labbott@redhat.com> From: Laura Abbott Message-ID: Date: Mon, 14 May 2018 14:02:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/06/2018 11:28 PM, Masahiro Yamada wrote: > 2018-03-30 3:01 GMT+09:00 Laura Abbott : >> Hi, >> >> This is v2 of my proposal to allow unique build-ids in the kernel. from >> last time: >> >> "" >> In Fedora, the debug information is packaged separately (foo-debuginfo) and >> can be installed separately. There's been a long standing issue where only one >> version of a debuginfo info package can be installed at a time. Mark Wielaard >> made an effort for Fedora 27 to allow parallel installation of debuginfo (see >> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for >> more details) >> >> Part of the requirement to allow this to work is that build ids are >> unique between builds. The existing upstream rpm implementation ensures >> this by re-calculating the build-id using the version and release as a >> seed. This doesn't work 100% for the kernel because of the vDSO which is >> its own binary and doesn't get updated. After poking holes in a few of my >> ideas, there was a discussion with some people from the binutils team about >> adding --build-id-salt to let ld do the calculation debugedit is doing. There >> was a counter proposal made about adding some extra information via a .comment >> which will affect the build id calculation but just get stripped out. >> "" > > > I think you already know '--build-id=uuid' linker option. > > Doesn't this solve your problem? > > The disadvantage of this option is, > we will lose reproducible building because --build-id=uuid > adds every time random salt. > > The advantage is, the implementation is even simpler, > and easier to migrate to --build-id-salt once it is supported > in the future. > > It could, theoretically. The reproducibility is nice though and I'd like to keep the kernel close to matching what other packages do though. Thanks, Laura >> This v2 cleans up the naming to be consistent and also switches to a >> config option vs. an environment variable. I've seen some sporadic >> failures about missing the generated header so I think I'm still missing >> a dependency somewhere. > > Right. > > There is no dependency between 'prepare' and 'scripts' > in the top Makefile. > Therefore, Kbuild can run them simultaneously, > which would cause a race in parallel building. > > > > > > > > > I'm still mostly looking for feedback whether >> this would be acceptable for merging or if we should just persue a >> --build-id-salt in binutils. >> >> Thanks, >> Laura >> >> >> Laura Abbott (3): >> kbuild: Introduce build-salt generated header >> kbuild: Link with generated build-salt header >> x86/vdso: Add build salt to the vDSO >> >> Makefile | 13 +++++++++++-- >> arch/x86/entry/vdso/vdso-layout.lds.S | 3 +++ >> init/Kconfig | 8 ++++++++ >> scripts/.gitignore | 1 + >> scripts/Makefile | 2 +- >> scripts/build-salt.lds.S | 5 +++++ >> scripts/gensalt | 21 +++++++++++++++++++++ >> scripts/link-vmlinux.sh | 3 ++- >> 8 files changed, 52 insertions(+), 4 deletions(-) >> create mode 100644 scripts/build-salt.lds.S >> create mode 100755 scripts/gensalt >> >> -- >> 2.16.2 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > >