Re: Propose gABI addition: SHF_NOREAD

[Joey Ye]

This feature is very useful and important to execute-only system, like these existing boards with Proprietary Code Read Out Protection (PCROP).

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00075930.pdf

 

Comments are highly appreciated.

 

Thanks,

Joey

[Michael Eager]

On 12/17/13 21:51, Joey Ye wrote:
> This feature is very useful and important to execute-only system, like these existing boards with
> Proprietary Code Read Out Protection (PCROP).

> _http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00075930.pdf_
> Comments are highly appreciated.

Is this something which can be done in a linker script
without requiring a new flag?

--
Michael Eager ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Suprateeka R Hegde]

What are the disadvantages of doing this under SHF_MASKOS environment
specific extensions? There are many sh_flags already existing under
environment specific extensions and are not part of the standard.

--
Supra

On 18-12-2013 11:21 AM, Joey Ye wrote:
> This feature is very useful and important to execute-only system, like
> these existing boards with Proprietary Code Read Out Protection (PCROP).

> _http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00075930.pdf_

> Comments are highly appreciated.
> Thanks,
> Joey
>

> --
> You received this message because you are subscribed to the Google
> Groups "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to generic-abi...@googlegroups.com.
> To post to this group, send email to gener...@googlegroups.com.
> Visit this group at http://groups.google.com/group/generic-abi.
> For more options, visit https://groups.google.com/groups/opt_out.

[Joey Ye]

Supra,

I agree that a new flag in SHF_MASKOS can solve this problem for ARM.

But execute-only is not an OS or target related feature, which is what SHF_MASKOS is used for. A new flag SHF_NOREAD will define execute-only in a generic way. The disadvantages of a new flag in SHF_MASKOS for ARM are
1. Other targets won't be able use this feature
2. If a generic SHF_NOREAD will be defined in future, existing tools that uses SHF_MASKOS will need to be modified again by then.

Thanks,
Joey

[Joey Ye]

Mike,

It can be done with existing linker script features, for example by playing with section names or even object file names. However, they are not generic enough to apply in all circumstances. With the belief that execute-only is a generic feature, I believe SHF_NOREAD is a more decent solution.

Thanks,
Joey

[Suprateeka R Hegde]

I would say SHF_NOREAD alone would not be generic solution in ELF. It is
because in future, we may have another proprietary system that needs
SHF_NOWRITE or SHF_NOEXEC. So we have to make it generic enough
considering all future possibilities.

Just like segment attributes (PF_R/PF_W/PF_X), we would need section
attributes to make it generic enough. However, there already exists
SHF_EXECINSTR, etc., which may overlap with the new semantics.

I would say, the existing ELF suggests, all such execute only sections
be linked to a segment with only PF_X set. Doesnt this work?

--
Supra

> > an email to generic-abi...@googlegroups.com <javascript:>.

> > To post to this group, send email to gener...@googlegroups.com

> <javascript:>.

> > Visit this group at http://groups.google.com/group/generic-abi

> <http://groups.google.com/group/generic-abi>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>

[Joey Ye]

On Thu, Jan 2, 2014 at 2:57 PM, Suprateeka R Hegde
<hegdes...@gmail.com> wrote:
> I would say SHF_NOREAD alone would not be generic solution in ELF. It is
> because in future, we may have another proprietary system that needs
> SHF_NOWRITE or SHF_NOEXEC. So we have to make it generic enough considering
> all future possibilities.

If NOWRITE/NOEXEC will be defined, it is nature to also have NOREAD.

>
> Just like segment attributes (PF_R/PF_W/PF_X), we would need section
> attributes to make it generic enough. However, there already exists
> SHF_EXECINSTR, etc., which may overlap with the new semantics.
>
> I would say, the existing ELF suggests, all such execute only sections be
> linked to a segment with only PF_X set. Doesnt this work?

Attribute of the output segment doesn't work. What's missing is
attribute of input sections. I'm seeking a generic solution to pick up
input sections with certain characteristics and output to a PF_X
segment.

>
> --
> Supra

[Suprateeka R Hegde]

On 03-01-2014 12:19 PM, Joey Ye wrote:
> On Thu, Jan 2, 2014 at 2:57 PM, Suprateeka R Hegde
> <hegdes...@gmail.com> wrote:
>> I would say SHF_NOREAD alone would not be generic solution in ELF. It is
>> because in future, we may have another proprietary system that needs
>> SHF_NOWRITE or SHF_NOEXEC. So we have to make it generic enough considering
>> all future possibilities.
> If NOWRITE/NOEXEC will be defined, it is nature to also have NOREAD.

Right. Then I believe, there is a need for clear definition in standard
terms comprising all these instead of just SHF_NOREAD. What I am saying
is that SHF_NOREAD is a negative attribute compared to the existing
SHF_WRITE, SHF_EXECINSTR, etc., in the SHF_* group. Adding attributes as
per the immediate specific necessity may render the specification more
ambiguous.

I would say, the definition of the new set of attribute must tell
- what are the valid combinations possible with the existing ones
- what are the strict semantics and what are allowable/system dependent
semantics. For instance, PF_X also allows read permission.
- A generic practical use of the new attribute. What exactly is NOREAD?
Is it noread for external programs like debuggers and dumpers? Or is it
noread absolutely? If absolutely noread, then how would a generic system
with the most common (von-neumann?) architecture would benefit from this
as at least the execution unit in the CPU (even if hardwired) has to
fetch ("read") the instructions.
- Is this useful only for embedded systems?
- etc.

If all these are clear, everyone on the forum may find the usefulness as
a generic solution and there could be a good consensus to make it to the
gABI.

>> I would say, the existing ELF suggests, all such execute only sections be
>> linked to a segment with only PF_X set. Doesnt this work?
> Attribute of the output segment doesn't work. What's missing is
> attribute of input sections. I'm seeking a generic solution to pick up
> input sections with certain characteristics and output to a PF_X
> segment.

My personal opinion in this case would be to go with SHF_MASKOS (or
MASKPROC if there are many systems like STM using ARM), as finally your
requirement is to form a segment with PF_X set. There are so many
proprietary compilers that use SHF_MASKOS range to generate
characteristic input sections that finally merge to a gABI conforming
segment.

That said, you may ask for further comments from others on the forum
regarding the usefulness for adding this (SHF_NOREAD alone) to gABI.

--
Supra

[Joey Ye]

Supra,

As I still think it necessary to add this flag, here is a proposal trying to answer questions you asked.

Non-readable but executable memory is supported in some micro-controller hardware. The motivation is to protect software IP in devices that having MCU program in it. Execute-only memory can be read by instruction fetches but NOT by data reads. It follows that a debugger cannot read the memory. It needs toolchain to support the execution-only model. An implementation of this feature can be found at:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00075930.pdf. Although so far I only know MCU has such a feature, there could be other applications this feature like smart phone firmware for security considerations.

The typical program model is that program flash is partitioned into readable and non-readable segments. Programmers use a compiler option to switch between readable/non-readable code generation. Then binutils maps non-readable sections into appropriate output sections. There are options for mapping that are 'easy' (not 'difficult') but have messy aspects in deployment. For example, sections can be sorted and mapped by section name but there is no standard for partitioning the section name space (ELF is mostly silent on this topic) so there is no *reliable*, *future-proof* way to exploit section naming.

What I'm proposing is a new ELF section flag SHF_NOREAD:

SHF_NOREAD: This section cannot be read by data access instructions during process execution. Only instruction fetches can read this section. SHF_NOREAD must be set in conjunction with SHF_EXECINSTR.

SHF_NOREAD is denoted by 'y' in the assembly language encoding of section flags. For example: .section .text, "xy", %progbits. It is erroneous to use 'y' without 'x'. 'xy' may be combined with other flags whose meaning does not conflict with the meaning of SHF_EXECINSTR and SHF_NOREAD.

A static linker combines sections according to their attributes and maps them into ELF segments in an executable ELF file. The effect of SHF_NOREAD on a segment's PF_R flag is as follows:

* If no consolidated section mapped by a segment has the SHF_NOREAD attribute, the segment's PF_R flag is set by default.

* If every consolidated section mapped by a segment has the SHF_NOREAD attribute, the segment's PF_R flag must be cleared.

When targeting a system that can enforce execute-only access to memory it is a user error to map a section with the SHF_NOREAD attribute and one without the SHF_NOREAD attribute into the same executable segment. When mapping such sections a linker may set PF_R or clear PF_R, and may issue a diagnostic message. We recommend that linkers should clear PF_R and issue a non-fatal Error diagnostic.

Thanks
Joey

[Joey Ye]

Supra, any comments to the update proposal?

- Joey

On Thursday, April 18, 2013 11:28:58 AM UTC+8, Joey Ye wrote:

Non-readable but executable memory is supported in some micro-controller hardware. The motivation is to protect software IP in devices that having MCU program in it. Program in execute-only memory can run, but can't be read and reverse engineered with tools like debugger. It needs toolchain to support the execution-only model.

The typical model is that program flash is partitioned into readable and non-readable segments. Programmers use a compiler option to switch between readable/non-readable code generation. Then binutils then distinguish them and put non-readable sections into appropriate output sections.

What I'm proposing is a new ELF section flag SHF_NOREAD:

SHF_NOREAD

        The section contains data/machine instructions that cannot be read during process execution. If enabled together with SHF_EXECINSTR, the section contains execute-only machine instructions.

The flag will be annotated as 'y' in assembler, the same as PE targets. So assembler should recognize following for ELF:
.section .text, "xy", %progbits

Linker script should be written as following:
.text { INPUT_SECTION_FLAGS (!SHF_NOREAD)*(.text*) } > FLASH1
.text2 {INPUT_SECTION_FLAGS ( SHF_NOREAD) *(.text*) } > FLASH2

Thanks - Joey

[Joey Ye]

If this request is to be rejected, please reject now explicitly, so that alternative approach can be explored.

Highly appreciate any comments!

- Joey

[Joey Ye]

Ping again

- Joey

> --
> You received this message because you are subscribed to the Google Groups
> "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to generic-abi...@googlegroups.com.
> To post to this group, send email to gener...@googlegroups.com.
> Visit this group at http://groups.google.com/group/generic-abi.
> For more options, visit https://groups.google.com/d/optout.

[Suprateeka R Hegde]

On 25-06-2014 03:34 PM, Joey Ye wrote:
> Supra,
>
> As I still think it necessary to add this flag, here is a proposal
> trying to answer questions you asked.
>
> Non-readable but executable memory is supported in some micro-controller
> hardware.

The "some" is the concern here.

> The motivation is to protect software IP in devices that
> having MCU program in it. Execute-only memory can be read by instruction
> fetches but NOT by data reads. It follows that a debugger cannot read
> the memory. It needs toolchain to support the execution-only model. An
> implementation of this feature can be found at:
> http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00075930.pdf.

Agreed on the security part of the technology. Agreed that we need some
sort of marker in the ELF specs for this. But...

> Although so far I only know MCU has such a feature,

...this is the concern. Does it justify an addition to the gABI when we
have psABI (or processor/os specific ELF extensions)?

Especially when the proposal says "This section cannot be read by data

access instructions during process execution. Only instruction fetches

can read this section", this looks like psABI related where only a
particular processor/hardware provides the feature.

> there could be other
> applications this feature like smart phone firmware for security
> considerations.

We do not have consensus here. I did not see any other response. It may
also connote there are no such requirements/applications other than MCU.

I again assert my earlier comments on this, specially the other ways of
achieving this (through Special Section, say .eodata or psABI, etc.).

However, if others on this forum think that this helps a larger set of
hardware/software vendors and hence makes sense to add this to gABI, I
fully support that.

(You have to assign a new non-conflicting ELF value for the new flag to
make the proposal complete. Other than this, the description looks good)

I do not have any more comments.

Thanks a lot
--
Supra