[89WvfwGAfwEKStaSsUXVEgAAAABJRU5ErkJggg==]
보안 문서
보안 문서는 PDF로 암호화 됩니다.
보안문서 열람을 위해 인증 방법 및 필수 설치프로그램을 확인하여 주십시오.
* 1. 보안문서를 조회하려면 본인인증이 필요합니다.
* - Knox Portal 사용자 : Knox Portal 아이디 + 비밀번호
* - 미사용자 : E-mail주소 + *사전등록 비밀번호
* *사전등록 비밀번호 : 별도 수신한 '보안 문서 열람을 위한 등록안내' 메일 참고
* 2. 보안문서는 Adobe Reader로만 열람 가능합니다.
* Adobe Reader 10.1.1 이상 설치되어 있어야 사용 가능합니다.
* 미 설치자의 경우 [1]클릭하여 설치하세요.
* * Windows 뷰어 앱으로 오픈 불가 [ windows 8.1 이상]
* 3. 보안문서를 열람하는 동안 화면캡쳐방지 프로그램이 동작합니다.
* 해당 프로그램은 화면캡쳐를 제한하는 기능만을 포함합니다.
* 자동 설치되지 않을 경우 [2]클릭하여 설치하세요.
* 4. 보안문서의 답장, 전달 시 최초 수신인 외에는 열람이 불가합니다.
필수 프로그램 설치하였으나 PDF 파일이 열리지 않을 경우 아래 내용을 확인해주세요.
브라우저의 PDF 저장 설정 (Chrome) 설정 → 개인정보 및 보안 → 사이트 설정 → 추가 콘텐츠 설정 → PDF 문서 →
‘Chrome에서 PDF 파일을 자동으로 여는 대신 다운로드’를 On으로 설정 (Edge) 설정 → 쿠키 및 사이트 권한 →
PDF 문서 → ‘항상 PDF 파일 다운로드‘를 On으로 설정 Adobe Reader PDF 파일을 저장 후 Adobe
Reader 프로그램을 단독 실행하여 저장된 PDF파일 불러오기로 진행
※ 문제해결이 되지 않는 경우 Adobe Reader 프로그램 삭제 후 Adobe Reader DC버전으로 재설치 후 다시
시도해 주십시오.
추가적인 도움이 필요하시면 [3]FAQ 확인 또는
서비스 데스크 (+82-(2)-1661-3311) 로 연락주십시오.
Security Document
Secure documents are encrypted into PDF.
Check the authentication procedure and required installation program to
view the security document
* 1. To view a secure document, you need to authenticate yourself
using the following information.
* - Knox Portal User : Knox Portal ID + Knox Portal Password
* - Knox Portal Non-User : E-mail address + *pre-registered Password
* *pre-registered Password : See the "Guide for Security Mail," which
was sent separately.
* 2. Security documents can be viewed only with Adobe Reader.
* It can be used only if the installed version is 10.1.1 or higher.
* If you have not installed it yet, please [4]click to install it.
* * Cannot be opened with Windows Viewer App [ windows 8.1 or higher
]
* 3. The screen capture prevention program is active while viewing a
secure document.
* It only has a feature that blocks screen captures.
* If it does not install automatically, please [5]click to install
it.
* 4. When replying or forwarding a secure document, it is not
available for viewing except the first recipient.
If the required program is installed but the PDF file does not open,
please check the following.
PDF Save Settings in Browser (Chrome) Settings → Privacy and security →
Site Settings → Additional content settings →
PDF documents → Select "Download PDFs" (Edge) Settings → Cookies and
site permissions → PDF documents →
Select "Always download PDF files" Adobe Reader After saving the PDF
file, run the Adobe Reader program alone and proceed to loading the
file If the problem is not resolved,
uninstall the Adobe Reader program, reinstall the Adobe Reader DC
version, and try again.
If you need additional help, please check [6]FAQ or contact us.
Service Desk (+82-(2)-1661-3311)
References
1. http://global103.cdnworks.com/AdbeRdr10112_mui_Std.zip
2. http://ssdrm.samsung.net/install/ssdrm/SSDRM_for_mySingle.exe
3. http://ssdrm.samsung.net/static/ssdrm/mySingle_SSDRM_FAQ_ko.pdf
4. http://global103.cdnworks.com/AdbeRdr10112_mui_Std.zip
5. http://ssdrm.samsung.net/install/ssdrm/SSDRM_for_mySingle.exe
6. http://ssdrm.samsung.net/static/ssdrm/mySingle_SSDRM_FAQ_en.pdf
Hi everyone,
As you may be aware, at Qualcomm we've been looking into various enhancements we'd like to make to Hafnium; one recent area we've identified for improvement is the fatal error handling which currently just spins on panic / abort.
To start with, we're looking at making abort() stop other CPUs and DMA, as well as introduce a platform hook to allow for platform-specific handling before propagating the error to the SPMD via FFA_ABORT; please let us know if this sound reasonable and if you have any other suggestions for improving this abort handling.
Beyond this we are also interested in improving the fatal error handling in the secure world more broadly. In particular, when a fatal event is received by TF-A then we want to give the SPMC and its SPs the opportunity to run so they can perform their own error handling before reset.
Is there a suitable framework for supporting this kind of error / reset handling? One existing mechanism for this is SDEI, though on the TF Discord it was mentioned that this has been deprecated (at least for hardware events) in favor of more recent extensions such as FEAT_NMI; would these newer extensions be suitable for software events as well? How can event handling be supported on platforms that lack these newer extensions?
Also, what would be the impact of this kind of event handling on the FF-A specification?
Thanks in advance for your support on this issue.
Regards,
Jack Suann
Hi,
We encourage anyone working for an organization deploying Hafnium project and are potentially impacted by security vulnerabilities to go through the Trusted Firmware Security incident handling guidelines and register [1] as a Trusted Stakeholder.
We prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. We will start sending notifications to Trusted Stakeholders from the start of next week/month.
[1] https://general.docs.trustedfirmware.org/en/latest/security_center/incident…
Thanks,
Madhukar on behalf of Hafnium maintainers
Hi Hafnium Team,
I hope this email finds you well.
I am currently working with TF-A and Hafnium, and I have a quick
question regarding the versioning and tagging practices between the two
projects.
Could you clarify if Hafnium release tags (e.g., v2.14, v2.15) are
always strictly synchronized with TF-A release tags in terms of
compatibility and FF-A feature support?
Additionally, when picking a stable combination for production or
feature integration (especially around SPMD/SPMC interaction), is it
recommended to always pair identical release tags between TF-A and
Hafnium, or are there specific compatibility matrices we should refer
to?
Thank you for your time and guidance.
Best regards,
Mankyum Kim
[cid:cafe_image_0@s-core.co.kr]
[update?userid=mankyum.kim&do=bWFpbElEPTIwMjYwNzIwMDgwMjQxZXBjbXMycDU3Z
Dk0MzdkYTE1ZDdkZGQ0ZDVhMmYwNzZkNjU1YWZhOSZyZWNpcGllbnRBZGRyZXNzPWhhZm5p
dW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
Hi everyone,
I am sending this email to all tf.org project mailing lists to ensure all maintainers are aware and on board regarding this matter. If you have any concerns or questions, please reply on tf.org Discord #general channel, where I'll create a thread, as I think it will be much easier than dealing with cross-mailing lists emails.
Background
When a security vulnerability is discovered in one of the trustedfirmware.org projects, it is common to request a "Common Vulnerabilities and Exposures" (CVE) number. This number uniquely references the issue, which can then be searched in the vulnerability databases. One of these databases is NIST's "National Vulnerability Database" (NVD): https://nvd.nist.gov<https://nvd.nist.gov/vuln/detail/CVE-2023-51712>
Entering a specific CVE number in NVD search engine will allow you to easily find the details of a specific issue, for example:
https://nvd.nist.gov/vuln/detail/CVE-2023-51712
However, sometimes one is not looking for a specific CVE number but rather wants to list all known vulnerabilities affecting a particular project. For this, one can use the Common Platform Enumerations (CPE) search engine:
https://nvd.nist.gov/products/cpe/search
CPE is a structured naming scheme that includes information like the vendor name, the project name, the version / tag, and so on.
See https://nvd.nist.gov/products/cpe for more details.
So for example, https://nvd.nist.gov/vuln/detail/CVE-2023-51712 referenced above has the following CPE:
cpe:2.3:o:arm:trusted_firmware-m:*:*:*:*:*:*:*:*
This basically means
*
CPE version 2.3 is in use
*
'o is the type of project, in this case it stands for Operating Systems (which is probably the closest match for low-level code like TF-M)
*
'arm' is the vendor (that is wrong, see below)
*
'trusted_firmware-m' is the project name,
Problem statement
It appears that CPEs used in NVD to reference vulnerabilities in tf.org projects differ a lot across projects. For some projects, there's even multiple of them. Sometimes the vendor is "arm", sometimes it's "linaro", or something else.
Some of the TF-A and MbedTLS maintainers have initiated discussions with NVD to get this simplified and unified, but it would make sense to align other tf.org projects as well.
Proposal
CPE naming rules are that the vendor name should the parent organization of the project. Thus the proposal would be for all tf.org projects to use "trustedfirmware" as the vendor name in their CPE.
For example:
cpe:2.3:o:trustedfirmware:trusted_firmware-m:*:*:*:*:*:*:*:*
cpe:2.3:a:trustedfirmware:mbed_tls:*:*:*:*:*:*:*:*
We're only proposing to change the vendor name here ; each project is then free to choose how they want the project name or the type of software project they want to encode there.
Thanks for reading,
Best regards,
Sandrine Afsa
Hi all,
We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 8 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
[LOGO SMALL]
Saheer Babu
Principal Software Engineer
CESW – Engineering Infrastructure
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
