"Enabled hardening configs default to build. (#1223)"" - #2232
"Enabled hardening configs default to build. (#1223)""#2232Jaihind Yadav (jaihindy) wants to merge 1 commit into
Conversation
|
Avoid “Revert of revert” in the commit message. This doesn't provide any meaningful info on the change. Instead, restore the original commit message to provide sufficient context on why this change is being made. |
Test Results 30 files 30 suites 2h 6m 45s ⏱️ For more details on these failures, see this check. Results for commit 572eea6. ♻️ This comment has been updated with latest results. |
"Reapply" is another option for “Revert of revert” and recent verions of git uses this formulation. |
|
Missing SoB. Why? |
|
No commit message, failing DCO, please follow the guidelines for commit messages from this repository. |
Dmitry Baryshkov (lumag)
left a comment
Dmitry Baryshkov (lumag)
left a comment
There was a problem hiding this comment.
Please respond to review comments.
Jaihind Yadav (jaihindy)
changed the title
|
|
Nothing changed here, not even DCO is passing. |
Yes, that’s correct. The non-HLOS binaries need to be published and then consumed by meta-qcom (outside of the PR activity). Only after this is completed PR will pass so waiting for the binaries. We will work on the comments once this non-hlos binaries are updated. JFI : |
|
Moving to draft then. |
53697a4 to
69eb719
Compare
69eb719 to
56e7abd
Compare
|
bootup issue on rb4 on all distros |
56e7abd to
faa6a59
Compare
Dmitry Baryshkov (lumag)
left a comment
Dmitry Baryshkov (lumag)
left a comment
There was a problem hiding this comment.
Not to mention that commit doesn't follow established guidelines. See CONTRIBUTING.md
| CONFIG_VETH=m | ||
| # Disable stack erase plugin to avoid buildpath leakage in out-of-tree modules | ||
| CONFIG_KSTACK_ERASE=n | ||
| # Disabled due to TrustZone memory allocator initialization failure |
There was a problem hiding this comment.
Why? This would usually point out the error in the memory map. Can the boards boot with CONFIG_MEMTEST=y and memtest=1 kernel arg?
There was a problem hiding this comment.
We performed additional debugging and identified that the failure is occurring during TrustZone SHM Bridge enablement. Specifically, the following API returns a non-zero status from TrustZone:
ret = qcom_scm_shm_bridge_enable(qcom_tzmem_dev);
Show more lines
Debug logs show:
[ 0.070390] qcom_scm firmware:scm: SHM bridge enable raw result: ret=0 res0=97 res1=0 res2=0
[ 0.070391] qcom_scm firmware:scm: SHM bridge enable returned non-zero status: 97
From the collected logs:
The SHM Bridge feature availability check succeeds (avail=1).
The SCM call itself completes successfully (ret=0).
However, TrustZone returns status 97 in res0.
The kernel interprets this status as a failure and reports:
Failed to enable the TrustZone memory allocator
Additionally, I tested:
CONFIG_QCOM_TZMEM_MODE_GENERIC=y
instead of:
CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y
With GENERIC mode, the device boots successfully, including when the kernel hardening configurations (CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON) are enabled.
We have engaged the TrustZone (SSG) team and shared the debug findings. They are currently investigating why TrustZone returns status 97 for the SHM Bridge enable request on this platform.
Even if a TrustZone-side fix is identified, it is expected to take considerable time before it becomes available in the Non-HLOS images used by the nightly builds. Since this issue was only recently uncovered, waiting for the firmware fix would significantly delay the rollout of the hardening configuration changes.
Therefore, I would kindly request approval of this change while we continue to work with the SSG team on the root-cause analysis and firmware-side resolution of the SHM Bridge enablement failure. Once the fix will be available we'll enable CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON back.
There was a problem hiding this comment.
I would prefer to wait until we are able to identify a fix from the TrustZone-side, as we do want to find these type of issues.
There was a problem hiding this comment.
Any progress on this issue?
Thanks . I"ll fix the commit message accordingly. |
faa6a59 to
c1122bc
Compare
Latest push still has a non-compliant commit message. See CONTRIBUTING.md and for our robot helpers, have the tool follow https://github.com/qualcomm-linux/meta-qcom/blob/master/AGENTS.md |
Koen Kooi (koenkooi)
left a comment
Koen Kooi (koenkooi)
left a comment
There was a problem hiding this comment.
Commit message
|
c1122bc to
648a747
Compare
|
That's a much better commit message! |
Dmitry Baryshkov (lumag)
left a comment
Dmitry Baryshkov (lumag)
left a comment
There was a problem hiding this comment.
This should be fixed in the kernel tree rather than requiring a fix for every module.
|
Conflicts will have to be fixed as well. |
060f012 to
2233e29
Compare
| against this kernel inherit the same behavior without per-module | ||
| workarounds. | ||
|
|
||
| Upstream-Status: Pending |
There was a problem hiding this comment.
No Pending patches, thanks.
There was a problem hiding this comment.
Hi ,
We are actively working with the upstream kernel community to address this issue. Based on the latest feedback from the upstream maintainer, the proposed fix appears to be on the right track, and Nathan indicated that he is willing to take the patch through the upstream process.
I've attached a screenshot of the upstream feedback for reference.
Given this, can we proceed with CONFIG_KSTACK_ERASE=n for now and then switch to CONFIG_KSTACK_ERASE=y once the upstream patch is merged into a future kernel version?
For reference, the latest upstream submission is available here:
PATCH v3 - suppress recorded GCC switches for extmod builds
https://lore.kernel.org/all/20260820060116.786173-1-jaihindy@qti.qualcomm.com/
Please let me know your thoughts.
Thanks,
Jaihind
There was a problem hiding this comment.
Please let me know your thoughts
Please check the files under Documentation/process, they might make your upstream submission smoother.
There was a problem hiding this comment.
Thanks for suggestion. I'll review the documents in Documentation/process and incorporate the guidance to improve future upstream submissions.
There was a problem hiding this comment.
Given this, can we proceed with CONFIG_KSTACK_ERASE=n for now and then switch to CONFIG_KSTACK_ERASE=y once the upstream patch is merged into a future kernel version?
No, wait for it to be accepted by the maintainers into their tree.
There was a problem hiding this comment.
Dmitry,
I believe we should proceed with Jaihind's proposal to set CONFIG_KSTACK_ERASE=n, as the upstream review is still in progress and waiting for the change to flow back into our tree could take additional time.
Further delaying the hardening effort may introduce more issues similar to those we have already encountered. As seen previously, this was not an isolated case, and we identified three separate issues that required considerable debugging effort and follow-up discussions.
It is also important to recognize that hardening is not limited to CONFIG_KSTACK_ERASE alone. The earlier we enable and validate these hardening features, the more time we will have to identify potential regressions, strengthen the implementation, and ensure a robust solution before the release.
Thanks.
There was a problem hiding this comment.
Did we sort out the issue with one of the hardening options causing an error because of the incorrect boot memory map? If that is solved and the option is reenabled, I'm fine with mering this PR.
There was a problem hiding this comment.
Sorry Dmitry we were waiting for the Bootup crash related fix to be part of mainline below is the status .
Early bootup crash is fixed as part of firmware update "#3069" waiting for approval.
GCC KSTACK related is getting tracked as part of
https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git/commit/?id=51794b107d54b3c9a8ebbe12a3b81d8495bd482c
There was a problem hiding this comment.
Was the last commit backported to qcom-next and qcom-6.18?
There was a problem hiding this comment.
We had not created any backport for qcom-next or qcom-6.18 yet , Waiting for backport will futher delay . As agreed earlier we should go for enabling the hardening first and later we will get this backports .
We are still waiting for #3069 closer .
2233e29 to
648a747
Compare
Enable hardening.config in the default KERNEL_CONFIGS list to provide a stronger security baseline across meta-qcom targets. Keep CONFIG_KSTACK_ERASE disabled to avoid embedding build path information into out-of-tree kernel modules, which triggers Yocto buildpath QA failures. Keep CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON disabled due to a memmap issue in UEFI on RB4 that causes boot failures when memory initialization hardening is enabled. The UEFI team is in process of merging the change. Re-enable these options once the fix is available in the meta. Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
648a747 to
572eea6
Compare
9 participants
Include hardening.config in kernel configuration
Include hardening.config via merge_config.sh during kernel
configuration to enable consistent security hardening across
all builds.
Previously, kernel configurations did not include these
defaults, resulting in missing compiler-based mitigations and
other hardening features.
Set CONFIG_KSTACK_ERASE to 'n' as enabling it embeds absolute
build paths into out-of-tree kernel modules, leading to
Yocto QA buildpath failures.
This ensures hardened defaults while maintaining clean QA
compliance.
Keep CONFIG_INIT_ON_ALLOC_DEFAULT_ON and
CONFIG_INIT_ON_FREE_DEFAULT_ON disabled due to a TrustZone issue on
RB4 that causes boot failures when memory initialization hardening
is enabled. The TrustZone team is working on a fix. Re-enable these
options once the issue is resolved.
Update:
A fix for the CONFIG_KSTACK_ERASE build path issue has been submitted upstream - https://lore.kernel.org/all/20260820060116.786173-1-jaihindy@qti.qualcomm.com/ to the Linux kernel mailing list (upstream patch submission). The upstream maintainer has indicated that the change is expected to be merged in a future kernel release. Once the upstream fix is available and integrated, we plan to enable CONFIG_KSTACK_ERASE=y as part of the default hardening configuration.