CN116795525A - 资源控制方法及装置 - Google Patents

资源控制方法及装置 Download PDF

Info

Publication number
CN116795525A
CN116795525A CN202210262411.2A CN202210262411A CN116795525A CN 116795525 A CN116795525 A CN 116795525A CN 202210262411 A CN202210262411 A CN 202210262411A CN 116795525 A CN116795525 A CN 116795525A
Authority
CN
China
Prior art keywords
instruction
code
controlled
instructions
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210262411.2A
Other languages
English (en)
Inventor
李国柱
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210262411.2A priority Critical patent/CN116795525A/zh
Priority to PCT/CN2023/071405 priority patent/WO2023173915A1/zh
Publication of CN116795525A publication Critical patent/CN116795525A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种资源控制方法及装置,涉及终端设备技术领域,该方法包括:在需要控制的程序运行之前,对该程序内的指令进行扫描,在扫描到该程序只包括预设指令集中的指令时,则对该程序中的指令的资源访问范围进行限制,使得该程序的指令在执行过程中,该程序只能在限制的资源访问范围内进行资源访问,而无法访问超出上述资源访问范围的资源,以实现对上述程序的安全控制,确保资源的安全访问。

Description

资源控制方法及装置
技术领域
本申请实施例涉及终端设备技术领域,尤其涉及一种资源控制方法及装置。
背景技术
为了信息的安全,在软件中,可对信息进行隔离。在对信息隔离时,计算机可通过对不同的软件代码赋予不同的角色,并基于角色来分配资源,以构成该角色的一个实例,从而保证不同的实例仅能访问对应角色实例(例如进程,容器,虚拟机等)被分配的资源,以实现信息的安全访问。
为了实现信息的安全访问,对于任意一个角色实例,处理器在执行该角色实例的每个指令时,都需要通过查询对该角色实例所分配的资源地址列表,来确定该指令的访问地址是否在该角色实例的访问权限内,以决定是否执行该指令,显然,这将降低处理器的程序执行效率。
发明内容
为了解决上述技术问题,本申请提供一种资源控制方法及装置。在该方法中,在受控模块运行前,通过检测其指令只包括预设指令集的指令以及限制其指令的资源访问范围,在运行受控模块时,则无需对其指令的访问权限进行检查,从而提升程序执行效率。
在一种可能的实施方式中,本申请实施例提供一种资源控制方法,应用于资源控制装置,所述资源控制装置包括控制模块和受控模块,所述资源控制装置中的指令被划分为受控类指令和非受控类指令。所述方法包括:在受控模块运行之前,所述控制模块对所述受控模块内的指令进行扫描,检测所述受控模块内的指令是否均为受控类指令;在所述控制模块检测到所述受控模块内的指令均为所述受控类指令时,所述控制模块对所述受控模块内的每个指令分配目标资源访问范围。
示例性的,资源控制装置内运行的指令被划分为两类,一类为受控类指令,另一类为非受控类指令。
资源控制装置可为中央处理器(CPU),或者任意一种处理器等,本申请对于资源控制装置的实现方式不做限制,为了便于说明,以资源控制装置实现为CPU为例进行说明。
示例性的,受控类指令可包括本申请的自定义指令集,其中,自定义指令集中的指令在被CPU执行时,只可以访问特定的资源范围,而无法访问特定资源范围之外的资源。换言之,自定义指令集中的指令在被CPU执行时被限制了资源访问范围。
可选地,受控类指令还可包括对非受控模块的代码和数据的安全无影响的一些传统的预设指令(例如加法指令、减法指令等不需要访问内存资源的指令),这些对非受控模块中的代码和数据的安全无影响的预设指令可根据需要而灵活设置,本申请对此不做限制。
可选地,在受控类指令包括与资源无关的预设指令(即不需要访问资源的指令,以资源为内存资源为例)的情况下,则控制模块无需对该预设指令分配目标资源访问范围,控制模块只需对受控模块内需要访问内存资源的每个受控类指令分配目标资源访问范围。这里以访问的资源为内存资源为例。
受控类指令在被CPU执行时,CPU只可以访问控制模块对该受控类指令所分配的特定的资源访问范围,而无法访问特定资源访问范围之外的资源。换言之,受控类指令的语义(或者说编码)决定受控类指令在被CPU执行时被限制了资源访问范围。那么CPU在执行每个受控类指令时,均无需通过查页表等方式来检查当前运行的该受控类指令中的资源访问地址是否在当前运行的程序的资源访问权限范围内,以提升CPU的指令处理效率。
而CPU在执行非受控类指令时,不需要对非受控类指令中的资源访问地址进行处理,可按照传统的方式,检测该非受控类指令中的资源访问地址是否是预先分配给该受控模块的可访问的地址(例如查页表等检测方式),如果该资源访问地址是可访问的地址,则CPU按照该资源访问地址访问资源,如果该资源访问地址是不可访问的地址,则CPU中断执行该受控模块内的指令。
那么将CPU内的指令被划分为受控类指令和非受控类指令,可按照上述两类指令的不同执行方式进行执行,使得CPU可支持运行不受资源访问范围限制的模块(例如非受控模块,其中,非受控模块可用于调用受控模块),以及支持运行受资源访问范围限制的模块(例如上述受控模块),丰富了CPU可执行的指令的类型,并实现了对运行在CPU中的受控模块的资源范围的访问控制。
本申请实施例中,受控类指令在被CPU执行时,CPU只可以访问对该受控类指令所分配的有限的资源访问范围,那么在受控模块运行之前,由控制模块扫描受控模块内的指令是否均为受控类指令,可在受控模块运行之前,通过控制模块来实现对受控模块内指令类型的检查。若控制模块检测到受控模块内的指令均为受控类指令,则可以确定受控模块在运行时不会访问超出其资源访问范围的资源,以确保受控模块在运行时的资源安全访问。也即在受控模块运行前,通过控制模块对受控模块进行指令扫描,可以确定该受控模块是否是安全的,在确定受控模块安全的情况下,才会运行该受控模块。本申请实施例能够在受控模块运行前,实现对第三方提供的受控模块的安全检查,无需在受控模块运行过程中,实时检查每个待执行的指令是否安全,提升了对受控模块的运行效率。能够在指令源头实现对受控模块的资源访问范围的限制,无需在执行指令过程中判断指令所请求访问的资源是否超出资源访问范围。
示例性的,以内存资源为例,在控制模块对所述受控模块内的每个指令分配目标资源访问范围时,控制模块可向CPU发送非受控类指令,CPU在执行该非受控类指令时,可对受控模块内的每个受控类指令,在内存中分配可访问的目标地址空间,以及确定该目标地址空间的目标地址参数。此外,控制模块还可向CPU发送非受控类指令,CPU在执行该非受控类指令时,可将上述目标地址参数写入存储单元。从而实现对受控模块内的每个指令的目标资源访问范围的分配。
本实施例中,通过CPU执行非受控类指令来对受控模块内的每个受控类指令分配目标资源访问范围,其目的在于,如果受控类指令在被CPU执行时,CPU可对受控模块分配目标资源访问范围,那么受控模块就可通过发送通过扫描确认的受控类指令至CPU,来使CPU修改对受控模块内每条指令所分配的目标资源访问范围。例如,受控模块将目标资源访问范围修改为控制模块不允许受控模块访问的资源访问范围,使得受控模块的资源访问范围无法受控制模块所控制。从而无法达到通过控制模块来限制受控模块的目标资源访问范围的目的,使得受控模块容易访问到敏感内存资源(例如存储有用户账号数据等数据的内存空间)。那么本申请实施例中,控制模块作为对受控模块的资源访问范围的限制方,CPU可通过执行控制模块内的非受控类指令,来对受控模块内的每个受控类指令分配目标资源访问范围,使得受控模块的资源访问范围是受控制模块控制的,受控模块自身无法修改其自身可访问的目标资源访问范围,从而确保受控模块对资源的安全访问。
示例性的,存储单元可内置于CPU,或者,存储单元为独立于CPU之外的外置芯片中的存储单元,CPU可访问外置芯片中的存储单元。
示例性的,存储单元可以是寄存器(包括但不限于段寄存器等)、磁头等。
在控制模块写入目标地址参数至CPU中的存储单元后,非受控模块可调用受控模块,以使受控模块运行在CPU中。
以具体示例来说明:
应用1(非受控模块的一个示例)中需要运行第三方开发的插件(受控模块的一个示例),以实现应用1的一项新功能,那么为了确保插件不会访问应用1中的敏感信息(例如用户信息等),应用1可内嵌本申请提供的控制程序(控制模块的一个示例)。
该控制程序可在应用1运行该插件之前,扫描插件中的指令,在扫描到插件中的指令均为受控类指令时,说明插件是安全的。然后,控制程序可对插件中的每个受控类指令设置内存资源访问范围,控制程序具体可通过非受控类指令,来将限制内存访问空间的目标地址参数写入本申请的CPU中的段寄存器(存储单元的一个示例)。
其中,将目标地址参数写入段寄存器的指令可为非受控类指令,而不可以是受控类指令,这样,可以避免上述插件在运行过程中,通过CPU执行受控类指令来修改段寄存器内的目标地址参数的情况。而目标地址参数可用于确定插件内的受控类指令可访问的目标地址空间,这样可以避免插件在运行过程中,篡改CPU内对应于该插件的指令的段寄存器内的数据,造成插件访问该目标地址空间之外的资源的情况。
然后,应用1可以调用插件,使得插件运行后,向CPU发送受控类指令,以使CPU执行该受控类指令,对受控类指令中的原内存访问地址,按照段寄存器中的地址参数,在所限制的内存访问空间中确定目标内存访问地址,并在内存中访问该目标内存访问地址,以实现内存资源的限制访问。
这样,应用1在调用第三方开发的插件时,能够在使用插件的功能的同时,确保插件只可以在限制的内存地址空间中访问数据资源和代码资源,确保插件对应用1的资源的安全访问。
在一种可能的实施方式中,所述资源控制装置还包括处理模块,所述控制模块对所述受控模块内的每个指令分配目标资源访问范围之后,所述方法还包括:所述处理模块对第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源;其中,所述第一访问地址为所述受控模块内当前运行的受控类指令中的资源访问地址;其中,所述处理后的第一访问地址,在所述当前运行的受控类指令对应的所述目标资源访问范围内。
示例性的,在受控模块运行过程中,处理模块可执行受控模块当前运行的受控类指令(例如目标指令),处理模块在执行该目标指令时,可将目标指令中的原内存访问地址映射至对该目标指令分配的目标地址空间内,得到该原内存访问地址在该目标地址空间中对应的目标内存访问地址;处理模块按照该目标内存访问地址来访问内存资源。
示例性的,处理模块可执行接收到的目标指令,在存储单元中读取对该受控模块内的该目标指令(一个受控类指令)所设置的目标地址参数,并按照预设算法,基于目标地址参数和目标指令中的原内存访问地址,来在该目标指令对应的目标地址空间中确定目标内存访问地址;处理模块在目标内存访问地址处访问内存资源。
示例性的,在原内存访问地址超出目标地址空间时,则处理模块可按照该目标地址参数来将原内存访问地址的部分高位置零,使得处理后的目标内存访问地址在目标地址空间内。简单来描述,例如目标地址空间为1至100,原内存访问地址为1000,则可将原内存访问地址的地址长度缩小10倍,得到目标内存访问地址100,使得目标内存访问地址在目标地址空间内。
在本申请实施例中,为了能够使目标指令在被处理模块执行时,只可以访问对该目标指令设定的目标地址空间内的资源,处理模块按照该目标指令的编码,在执行该目标指令时,可按照上述算法对原内存访问地址进行处理(例如多个高位地址置为零)。那么不论目标指令中的原内存访问地址是否在目标地址空间内,处理后的目标内存访问地址均在目标地址空间内。
例如,即便受控模块的一段代码请求调用目标地址空间之外的某个地址1处的代码资源,处理模块在执行该段代码对应的受控类指令时,则可将地址1按照上述算法映射到该目标地址空间内的地址2。那么无论受控模块请求访问的资源的地址在哪里,处理模块在执行受控模块的目标指令时,都可在目标地址空间内找到一个与该原内存访问地址对应的目标内存访问地址,并访问该目标内存访问地址处的资源作为对原内存访问地址的访问结果。
这样,本申请实施例的处理模块在执行目标指令时,并不是直接按照该目标指令的原内存访问地址进行资源访问,而是找到该原内存访问地址在目标地址空间内映射的目标内存访问地址,并在目标内存地址处访问子。能够从目标指令的访问地址的维度进行受控模块可访问资源的限制,目标内存访问地址所指向的资源是准确且唯一的,那么这种精细化维度的资源限制方式,能够确保受控模块的任意指令所访问的资源是已经预先确定好的唯一资源。
在一种可能的实施方式中,在所述控制模块检测到所述受控模块内的指令不均为所述受控类指令之后,该方法还包括:在所述控制模块检测到所述受控模块包括与第一预设指令集匹配的第一指令、且所述第一指令为用于访问第一预设代码资源的指令时,所述控制模块对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围;其中,所述非受控类指令包括所述第一预设指令集;所述第一预设代码资源位于第一资源访问范围,且所述第一资源访问范围与所述目标资源访问范围不同。
示例性的,非受控类指令可包括第一预设指令集和第二预设指令集,其中,第一预设指令集内的指令可为部分或全部的非受控类的跳转指令(jump指令)。第二预设指令集内的指令可为部分或全部的非受控类的跳转指令,本申请对此不做限制。
示例性的,第一预设指令集与第二预设指令集可以相同或不同,两个指令集可以存在相同的指令。
示例性的,对于非受控类的跳转指令(即jump指令)也可以分为多种编码的jump指令,不同编码的jump指令虽然在被CPU执行时都可以实现代码资源的访问,但是在对代码资源的访问方式上可存在区别,本申请对此不做限制。那么这里的第一预设指令集和第二预设指令集内的指令则均为jump指令,但是这两个预设指令集之间的jump指令的编码可以存在区别。例如第一预设指令集中的指令为jump1指令至jump5指令。第二预设指令集中的指令为jump6指令至jump10指令。
在本实施例中,为了能够使受控代码可以获得一些非受控代码的服务(比如一个受控的插件执行,需要获得系统的时间),那么只需要确保受控代码中调用外部服务的非受控类指令,所访问的外部代码资源(即非受控代码中的代码资源)都是经过控制代码检查确认可以访问的第一预设代码资源,那么这些非受控类指令可以允许存在于受控代码中,这样,相比于添加代理代码的方案,本实施例在调用非受控代码中的外部函数时,只需要进行一次跳转,就可以实现受控代码对外部函数的调用。
示例性的,控制代码通过处理模块在检测到受控代码包括非受控类的跳转指令,即与第一预设指令集匹配的第一指令,例如jump1指令至jump5指令中的至少一个指令,则可进一步检测第一指令的跳转目标是否满足预设条件,在受控代码中的每个第一指令的跳转目标均满足预设条件时,则说明所述第一指令为用于访问第一预设代码资源的指令。那么控制代码允许受控代码运行,否则提示出错,拒绝运行。
示例性的,第一预设代码资源为控制代码,或者非受控代码,允许受控代码访问的位于目标资源访问范围之外的代码资源。
第一预设代码资源为位于第一资源访问范围内的代码资源。第一资源访问范围(例如第四地址空间)的访问地址,与目标资源访问范围(即上述第一地址空间和第二地址空间)的访问地址不重叠。
示例性的,第一预设代码资源可以是第一预设函数。第一预设函数可以是一个或多个函数,本申请对此不做限制,那么该第一预设函数可为所述控制模块允许所述受控模块访问的、且不属于第一地址空间和第二地址空间的外部函数。
示例性的,所述第一指令为用于访问所述第一预设函数的第一跳转类指令(例如jump1指令至jump5指令中的至少一个指令);
示例性的,受控代码中每个第一指令均为用于访问第一预设代码资源的指令,则控制代码可确定受控代码中每个第一指令的跳转目标满足预设条件,允许受控代码运行。
示例性的,所述第一预设代码资源包括第一预设函数,其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
例如受控代码中每个jump指令所跳转至的外部函数均为第一预设函数,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。再如受控代码中每个jump指令的跳转地址(例如第四访问地址)均为第二预设地址,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。其中,第二预设地址为控制代码允许受控代码访问的第二预设函数的地址。
在本申请实施例中,控制代码在扫描受控代码中的指令时,如果检测到非受控类指令,且非受控类指令均为与第一预设指令集匹配的非受控类的跳转指令(即第一指令),并且非受控类的跳转指令(第一指令)的跳转目标满足预设条件,例如受控代码中每个jump指令所跳转至的代码资源均为第一预设代码资源,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。那么控制代码可以允许受控代码运行。本实施例中受控代码在访问外部函数时,只需要进行一次外部跳转,不需要通过代理代码进行二次跳转,受控代码的执行速度更快。
在一种可能的实施方式中,所述第一预设代码资源包括第一预设函数,所述第一指令为用于访问所述第一预设函数的第一跳转类指令;
其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
在本申请实施例中,控制代码可在通过处理模块扫描受控代码的指令之后,在检测到受控代码中的指令不均为受控类指令时,控制代码通过处理模块检测到受控代码包括的非受控类指令均为第一预设指令集中的第一指令,第一指令为用于访问第一预设函数的第一类跳转指令(例如short_jump指令)。控制代码在对受控代码扫描时,可实现对受控代码中非受控类指令的检测,检测非受控类指令均为非受控类的跳转指令,并且每个非受控类的跳转指令的跳转目标均为第一预设函数,则可以确保受控代码在访问第一地址空间和第二地址空间之外的代码资源时,所访问的代码资源是控制代码指定的第一预设函数,以确保受控代码对外部函数的限制性访问。本实施例中受控代码在访问外部函数时,只需要进行一次外部跳转,不需要通过代理代码进行二次外部跳转,CPU对受控代码的执行速度更快。
在一种可能的实施方式中,所述受控模块内的所述受控类指令包括用于访问代码资源的第一类指令和用于访问数据资源的第二类指令,所述控制模块对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围,包括:所述控制模块对所述第一类指令分配第二资源访问范围;所述控制模块对所述第二类指令分配第三资源访问范围;其中,所述第二资源访问范围和所述第三资源访问范围之间的资源访问地址不同。
示例性的,控制代码(控制模块的一个示例)在对受控代码(受控模块的一个示例)中的第一类指令分配第二资源访问范围时,控制代码可对受控代码中的每个第一类指令分配第一地址空间,以及与该第一地址空间对应的第一地址参数。
其中,第一地址空间用于存储受控代码中受控类指令可访问的代码资源。
示例性的,第一地址参数可用于确定第一地址空间的地址范围。
示例性的,控制代码在对受控代码中的第一类指令分配第三资源访问范围时,控制代码可对受控代码中的每个第二类指令分配第二地址空间,以及与该第二地址空间对应的第二地址参数。
其中,第二地址空间用于存储受控代码中受控类指令可访问的数据资源。
示例性的,第二地址参数可用于确定第二地址空间的地址范围。
示例性的,第一地址参数可包括code_base参数和code_limit参数。
其中,code_base参数可表示第一地址空间的起始地址(即首地址),code_limit参数可以是第一地址空间的地址范围参数(可理解为第一地址空间的长度),包括但不限于空间大小,或控制空间大小的二进制掩码等。
示例性的,控制代码对受控代码中的第一类指令所分配的第一地址空间可以是连续或者不连续的地址空间,本申请对此不做限制。
示例性的,第二地址参数可包括data_base参数和data_limit参数。
其中,data_base参数可表示第二地址空间的起始地址(即首地址),data_limit参数可以是第二地址空间的地址范围参数(可理解为第二地址空间的长度),包括但不限于空间大小,或控制空间大小的二进制掩码等。
示例性的,控制代码,对受控代码中的第二类指令所分配的第二地址空间可以是连续或者不连续的地址空间,本申请对此不做限制。
可选地,控制代码可将code_base参数和code_limit参数分别写入处理模块中的两个寄存器内,例如寄存器1和寄存器2,以及将data_base参数和data_limit参数分别写入处理模块中的另外两个寄存器内,例如寄存器3和寄存器4。
也就是说,第一地址参数和第二地址参数所对应的存储单元不同。
示例性的,上述寄存器可以是段寄存器,但是,本申请对于写入有第一地址参数或第二地址参数的存储单元的类型并不限制于寄存器,可以是处理模块内部的任何硬件存储单元,可选地,也可以是独立于处理模块之外的芯片内的硬件存储单元。
在本申请实施例中,第一地址空间和第二地址空间之间的地址不同。受控代码可通过第一类指令,来访问内存中存储在第一地址空间内的代码,以及通过第二类指令,来访问内存中存储在第二地址空间中的数据。如果第一地址空间和第二地址空间存在重叠的地址,那么重叠的地址可存储代码以及数据,那么受控代码可在控制代码扫描其指令均为受控类指令之后,通过例如store_short指令,来访问该重叠的地址,并修改该重复的地址处的代码,使得受控代码中的代码(也即指令)被修改为非受控类指令,从而能够在所限制的第一地址空间和第二地址空间之外进行数据或代码的访问。本申请通过对受控代码中的受控类指令,配置不同的第一地址空间和第二地址空间,以免受控代码在经扫描通过允许运行后,受控代码再次修改内部代码,使受控代码包括非受控类指令,以访问未分配的内存资源,从而避过控制代码的扫描。
示例性的,处理模块在执行第一类指令时,可按照第二预设算法code_base+[code_limit(mask)OR addr],来在由code_base和code_limit限制的第一地址空间中,对该第一类指令中的原内存访问地址addr进行映射,得到限制在第一地址空间内的目标访问地址。
例如,第一地址空间为0至ffff,那么可以确定code_base=0x00000000,code_limit=0x0000ffff。
例如受控代码中的short_jump指令访问的第一访问地址addr1为0x12345678,addr1并不在第一地址空间0至ffff的范围内,那么本申请的处理模块在执行该short_jump指令时,可对code_limit和addr1进行与运算,使得addr的高8位变为0,得到addr2为0x00005678。其中,addr2的地址长度在code_limit限制的长度内。然后,处理模块计算code_base+addr2,得到第二访问地址addr3,这里code_base为0,因此,addr3=addr2,显然short_jump指令的跳转地址被限制在addr3(这里为0x00005678),这不会产生错误,而且能够使受控代码仅访问第一地址空间内的资源。其中,addr3在0至ffff的地址范围内(code_base和code_limit限制的第一地址空间)。
示例性的,处理模块可从寄存器3和寄存器4中分别读取data_base参数和data_limit参数。
示例性的,data_base参数为第二地址空间的首地址,data_limit参数为控制第二地址空间大小的二进制掩码。
示例性的,处理模块在执行第二类指令时,可按照第四预设算法data_base+[data_limit(mask)OR addr],来得到该第二类指令中的内存访问地址addr,在由data_base和data_limit限制的第二地址空间中,对addr进行映射,得到可访问的内存地址。
例如,第二地址空间为0至ffff,那么可以确定data_base=0x00000000,data_limit=0x0000ffff。
例如受控代码中的load_short指令访问的第三访问地址addr1为0x12345678,addr1并不在第二地址空间0至ffff的范围内,那么本申请的处理模块在执行该load_short指令时,可对data_limit和addr1进行与运算,使得addr的高8位变为0,得到addr2为0x00005678。其中,addr2的地址长度在data_limit限制的长度内。然后,处理模块计算data_base+addr2,得到第四访问地址addr3,这里data_base为0,因此,addr3=addr2,显然addr3在0至ffff的地址范围内(data_base和data_limit限制的第二地址空间)。
相比于CPU处理每个指令,均进行查页表的遍历操作,本申请的CPU在执行受控类指令时,只需要对受控类指令中的原访问地址,按照相应算法,将该原访问地址的部分高位设置为0,从而将处理后的访问地址能够位于所限制的地址空间内,得到在限制的地址空间内的目标地址,计算目标地址的速度相比于查页表的速度更快,CPU的指令执行效率更高。
在一种可能的实施方式中,所述非受控类指令包括第二预设指令集,所述控制模块包括代理子模块,所述代理子模块包括与所述第二预设指令集匹配的第二指令,其中,所述第二指令为用于访问第二预设代码资源的指令,所述第二预设代码资源位于第四资源访问范围内,所述第四资源访问范围与所述目标资源访问范围之间的资源访问地址不同;所述控制模块对所述受控模块内的每个指令分配目标资源访问范围之后,所述方法还包括:所述控制模块将所述代理子模块写入至所述第二资源访问范围。
示例性的,控制代码可包括代理代码(代理子模块的一种示例),代理代码可包括至少一个非受控类的跳转指令(即jump指令),该非受控类的跳转指令在被处理模块执行时,处理模块可访问第二预设代码资源的地址。
示例性的,代理代码中的非受控类的跳转指令,可为第二预设指令集中的jump6指令至jump10指令中的至少一个指令。
第二预设代码资源为位于第四资源访问范围(例如第三地址空间)内的代码资源。第四资源访问范围的访问地址,与目标资源访问范围(即上述第一地址空间和第二地址空间)的访问地址不重叠。
示例性的,第二预设代码资源为控制代码,或者非受控代码,允许受控代码访问的位于目标资源访问范围之外的代码资源。
示例性的,第二预设代码资源可以是第二预设函数。第二预设函数可以是一个或多个函数,本申请对此不做限制,那么该第二预设函数可为所述控制模块允许所述受控模块访问的外部函数。
在本申请实施例中,在控制代码中包括代理代码时,代理代码可配置有允许受控代码访问的非受控代码中的第二预设代码资源的非受控类的跳转指令,那么在对受控代码中的第一类指令,例如受控类的跳转指令,分配允许访问的第一地址空间以及第一地址参数时,可将代理代码也写入至受控代码可访问的第一地址空间中。那么控制代码在需要调用非受控代码中的第二预设函数时,可通过首先跳转至代理代码中的非受控类的跳转指令,再通过代理代码跳转至非受控代码中的第二预设代码资源,以实现对受控代码之外的外部代码资源的有限访问。
需要说明的是,在本申请实施例中,处理模块通过执行受控代码中受控类的跳转指令,来跳转至代理代码中,以访问代理代码中的非受控类的跳转指令,以通过该非受控类的跳转指令实现外部函数的访问。但是,受控代码中用于访问数据的第二类指令(例如受控类的内存访问指令,load_short指令)所访问的地址空间限制在第二地址空间,并不可以访问第一地址空间,从而不可以访问代理代码所处的地址空间,以防止受控代码通过第二类指令来修改代理代码中的代码,从而通过代理代码跳转至非法空间,防止受控代码非法调用未允许的服务。所谓非法空间即为控制代码不允许受控代码所访问的地址空间。
示例性的,第一预设代码资源与第二预设代码资源可以相同。那么受控代码可通过代理代码的方式,或,在受控代码内包括访问第一预设代码资源的非受控类的跳转指令的方式,来实现对外部代码资源的访问,本申请对此不做限制。
可选地,第一预设代码资源与第二预设代码资源可以不同。那么受控代码可通过代理代码的方式,和,在受控代码内包括访问第一预设代码资源的非受控类的跳转指令的方式,来实现对外部代码资源的访问,本申请对此不做限制。
同理,第一预设函数与第二预设函数可以相同或不同,第一指令与第二指令也可以相同或不同。
在一种可能的实施方式中,所述第二预设代码资源包括第二预设函数,所述第一类指令包括用于访问所述第二指令的第二跳转类指令;所述处理模块对所述第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源,包括:所述处理模块对所述第二跳转类指令中的第二访问地址进行处理,并按照处理后的第二访问地址访问所述第二指令;所述处理模块按照所述第二指令中的第三访问地址,访问所述第二预设函数;其中,所述第二预设函数为所述控制模块允许所述受控模块访问的函数。
示例性的,第一类指令为受控代码中的受控类的跳转指令,例如用于访问所述第二指令的第二跳转类指令为short_jump指令,处理模块通过执行受控代码中的该short_jump指令,可将short_jump指令的跳转地址(即第二访问地址)按照上文所述的算法来将跳转地址的高位置零,从而将第二访问地址的地址长度缩短,以使处理后的第二访问地址在第一地址空间内代理代码所处的地址空间。那么处理模块可从处理后的第二访问地址读取到代理代码中的非受控类的跳转指令(即第二指令),例如jump6指令。那么处理模块可通过执行jump6指令进行代码跳转,可跳转到jump6指令对应的跳转地址(即上述第三访问地址)以访问第二预设函数,这样,就通过代理代码实现了受控代码对非受控代码中第二预设函数的访问。
在本申请实施例中,控制代码可在通过处理模块扫描受控代码的指令之后,在检测到受控代码中的指令均为受控类指令时,控制代码可通过处理模块在受控代码的第一地址空间中写入代理代码,使得第一地址空间中不仅包括受控代码,还可包括代理代码,那么受控代码就可以通过受控类的跳转指令跳转至代理代码,并通过代理代码中的非受控类的跳转指令,跳转到非受控代码允许受控代码访问的固定函数的位置,例如第二预设函数的首地址。这样受控代码只能进入非受控代码指定的各个函数的首地址位置上,这些位置上的代码可以做合适的检查,再决定是否提供相关的功能,以确保对第二预设函数的访问安全。
在一种可能的实施方式中,本申请实施例提供一种资源控制装置。所述资源控制装置包括控制模块和受控模块,所述资源控制装置中的指令被划分为受控类指令和非受控类指令,所述控制模块用于:在受控模块运行之前,对所述受控模块内的指令进行扫描,检测所述受控模块内的指令是否均为受控类指令;在检测到所述受控模块内的指令均为所述受控类指令时,对所述受控模块内的每个指令分配目标资源访问范围。
在一种可能的实施方式中,所述资源控制装置还包括处理模块;所述处理模块,用于对第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源;其中,所述第一访问地址为所述受控模块内当前运行的受控类指令中的资源访问地址;其中,所述处理后的第一访问地址,在所述当前运行的受控类指令对应的所述目标资源访问范围内。
在一种可能的实施方式中,所述控制模块,还用于在检测到所述受控模块内的指令不均为所述受控类指令之后,在检测到所述受控模块包括与第一预设指令集匹配的第一指令、且所述第一指令为用于访问第一预设代码资源的指令时,对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围;其中,所述非受控类指令包括所述第一预设指令集;所述第一预设代码资源位于第一资源访问范围,且所述第一资源访问范围与所述目标资源访问范围不同。
在一种可能的实施方式中,所述第一预设代码资源包括第一预设函数,所述第一指令为用于访问所述第一预设函数的第一跳转类指令;其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
在一种可能的实施方式中,所述受控模块内的所述受控类指令包括:用于访问代码资源的第一类指令和用于访问数据资源的第二类指令;所述控制模块,具体用于:对所述第一类指令分配第二资源访问范围;对所述第二类指令分配第三资源访问范围;其中,所述第二资源访问范围和所述第三资源访问范围之间的资源访问地址不同。
在一种可能的实施方式中,所述非受控类指令包括第二预设指令集,所述控制模块包括代理子模块,所述代理子模块包括与所述第二预设指令集匹配的第二指令;其中,所述第二指令为用于访问第二预设代码资源的指令,所述第二预设代码资源位于第四资源访问范围内,且所述第四资源访问范围与所述目标资源访问范围之间的资源访问地址不同;所述控制模块,还用于将所述代理子模块写入至所述第二资源访问范围。
在一种可能的实施方式中,所述第二预设代码资源包括第二预设函数,所述第一类指令包括用于访问所述第二指令的第二跳转类指令;所述处理模块,具体用于:对所述第二跳转类指令中的第二访问地址进行处理,并按照处理后的第二访问地址访问所述第二指令;按照所述第二指令中的第三访问地址,访问所述第二预设函数;其中,所述第二预设函数为所述控制模块允许所述受控模块访问的函数。
上述各实施方式的资源控制装置的效果,与上述各实施方式的资源控制方法的效果类似,这里不再赘述。
在一种可能的实施方式中,本申请实施例提供一种资源控制装置。资源控制装置包括包括一个或多个接口电路和一个或多个处理器;所述接口电路用于从存储器接收信号,并向所述处理器发送所述信号,所述信号包括存储器中存储的计算机指令;当所述处理器执行所述计算机指令时,所述处理器可实现上述任意一种实施方式中的方法。
本实施方式的资源控制装置的效果,与上述各实施方式的资源控制方法的效果类似,这里不再赘述。
在一种可能的实施方式中,本申请实施例提供一种计算机可读存储介质。计算机可读存储介质存储有计算机程序,当计算机程序运行在计算机或处理器上时,使得计算机或处理器执行上述任意一种实施方式中的方法。
本实施方式的计算机可读存储介质的效果,与上述各实施方式的资源控制方法的效果类似,这里不再赘述。
在一种可能的实施方式中,本申请实施例提供一种计算机程序产品。计算机程序产品包含软件程序,当软件程序被计算机或处理器执行时,使得上述任意一个实施方式中的方法被执行。
本实施方式的计算机程序产品的效果,与上述各实施方式的资源控制方法的效果类似,这里不再赘述。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例的描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为为示例性示出的代码隔离的示意图;
图2a为示例性示出的进程隔离代码的示意图;
图2b为示例性示出的虚拟机隔离代码的示意图;
图2c为示例性示出的安全区隔离代码的示意图;
图3a为示例性示出的系统框架结构示意图;
图3b为示例性示出的系统框架结构示意图;
图4a为示例性示出的系统的运行流程图;
图4b为示例性的示出的内存地址空间的示意图;
图5a为示例性示出的系统的运行流程图;
图5b为示例性的示出的内存地址空间的示意图;
图5c为示例性示出的受控代码的编译过程的示意图;
图6a为示例性示出的系统的运行流程图;
图6b为示例性的示出的内存地址空间的示意图;
图6c为示例性示出的受控代码的编译过程的示意图;
图7为示例性示出的系统架构示意图;
图8为本申请实施例提供的一种装置的结构示意图;
图9为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象,而不是用于描述对象的特定顺序。例如,第一目标对象和第二目标对象等是用于区别不同的目标对象,而不是用于描述目标对象的特定顺序。
在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中,除非另有说明,“多个”的含义是指两个或两个以上。例如,多个处理单元是指两个或两个以上的处理单元;多个系统是指两个或两个以上的系统。
为了信息的安全,在软件中,可对信息进行隔离。在对信息隔离时,计算机可通过对不同的软件代码赋予不同的角色,并基于角色来分配资源,以构成该角色的一个实例,从而保证不同的实例仅能访问对应角色实例被分配的资源,以实现代码隔离,确保信息安全访问。
示例性的,角色实例可包括但不限于进程,容器,虚拟机等。
示例性的,为了便于理解,以角色实例为进程为例进行说明。例如在手机的安卓操作系统(简称Android)上运行一个应用程序(App,Application)。Android是手机供应商提供的,它代表一个角色。而App是App提供商提供的,那么为了信息安全,Android允许App只能访问电话功能,不能访问位置功能。为了实现对App的权限控制,Android在将中央处理器(CPU)的控制权交给App前,可修改CPU的权限状态,从操作系统权限修改为进程权限,其中,Android可对进程设置权限,以控制App可在进程权限内进行资源访问。示例性的,进程权限可包括访问电话权限,但是不包括访问位置权限。
App的代码在接管CPU之后,App的代码就只可以在进程权限内进行资源范围,而无法访问Android未分配给该App的进程的权限内的资源。那么App如果想要获得更高的权限,以访问进程权限之外的资源(例如访问位置信息),那么App只可以将CPU的控制权重新交给Android,由Android的代码重新接管CPU,然后,Android完成对位置信息的资源访问。
通过以上示例可以看到,在对代码进行隔离时,可对CPU设计一个分层或者分类的状态,并由高特权级的代码(例如操作系统代码)控制低特权级代码(例如一般用户程序代码,如上述App的代码)的资源访问范围(例如电话访问权限)。并将CPU的权限从高特权级修改为低特权级,使CPU执行的代码跳转到低特权级的代码中,以使低特权级代码接管CPU。那么低特权级的代码只可以在被分配的权限范围内进行资源范围,无法访问权限外的资源。
如果低特权级的代码要离开低特权级的CPU状态,低特权级的代码只能主动(比如系统调用)或者被动(比如中断等)的放弃CPU的控制权,使得CPU执行的代码跳转到高特权级特定的代码位置上,同时将CPU的权限从低特权级修改为高特权级,以使高特权级权的代码重新获得CPU的控制权,高特级权的代码可在高特级权的权限范围内进行资源访问。
那么高特级权的代码(例如操作系统代码)通过对低特级权的代码进行权限控制,可以确保低特级权的代码在资源访问上的安全性,例如上述App的操作行为的安全,避免App获取到用户的关键信息,例如读取用户的交易密码等。
图1为示例性示出的代码隔离的示意图。
应该理解的是,图1仅是一个范例,代码隔离的隔离结构可以具有比图中所示的更多的或者更少的层级。
如图1所示,CPU权限从高到底依次为全系统控制的权限、虚拟机的权限、操作系统权限、进程权限。
其中,全系统控制代码在虚线箭头指向的全系统控制的权限内运行,操作系统管理代码在虚线箭头指向的操作系统的权限(这里为虚拟机中操作系统的权限)内运行,一般用户程序代码在虚线箭头指向的进程的权限内运行。那么从高到低的特级权的代码依次为全系统控制代码、虚拟机管理代码、操作系统管理代码和一般应用程序代码。
如图1所示,运行在进程的权限内的一般用户程序,如果希望访问进程的权限之外的资源,则进程需要交出CPU的控制权,将CPU的控制权交给更高特权级的操作系统;运行在操作系统的权限内的操作系统管理代码,如果希望访问操作系统的权限之外的资源,则虚拟机需要交出CPU的控制权,将CPU的控制权交给更高特权级的虚拟机;运行在虚拟机的权限内的虚拟机管理代码,如果希望访问虚拟机的权限之外的资源,则虚拟机需要交出CPU的控制权,将CPU的控制权交给更高特权级的全系统控制代码,以在全系统控制的权限内进行资源访问。
也就是说,如果低特权级的代码要离开低特权级的CPU状态,低特权级的代码只能主动(比如系统调用)或者被动(比如中断等)的放弃CPU的控制权,使得CPU执行的代码跳转到高特权级特定的代码位置上,同时将CPU的权限从低特权级修改为高特权级,以使高特权级权的代码重新获得CPU的控制权,高特级权的代码可在高特级权的权限范围内进行资源访问。
示例性的,在图1中,全系统控制代码在全系统控制的权限内运行时,可对虚拟机的权限进行配置,以限制虚拟机的资源访问权限;虚拟机管理代码在虚拟机权限内运行时,可对操作系统的权限进行配置,以限制操作系统的资源访问权限;操作系统管理代码可在操作系统的权限内运行,可对进程的权限进行配置,以限制进程的资源访问权限。换言之,高特级权的代码可以对低特级权的代码分配权限,以对低特级权的代码的资源访问范围进行权限控制。
示例性的,结合图1和图2a,高特级权的操作系统管理代码(运行在虚拟机中)可对运行有一般用户程序代码的进程的权限进行配置,以对进程的资源访问范围进行限制。其中,内存资源是较为重要的资源,不论是进程还是虚拟机或是操作系统等都可以访问内存资源。但是,对于可访问的内存资源的具体地址,操作系统管理代码可对进程进行限制,其中,操作系统管理代码可配置每个进程的页表,以设置进程可以访问的内存资源的地址范围。其中,页表中可以包括该进程可访问的内存地址的信息。
一般用户程序代码在进程的权限内运行,当进程发起该进程的权限之外的资源访问请求时,需要将CPU的控制权交给操作系统,由操作系统发起该资源访问请求。例如进程发起访问系统资源的指令,其中,资源访问权限不在该进程的权限范围之内,该指令被禁止访问,那么可将CPU的权限从进程的权限修改为操作系统的权限,以及将CPU的代码指针从在该进程中运行的一般用户程序代码,指向操作系统管理代码,以使操作系统管理代码控制CPU,以实现对系统资源的访问。这样,可以确保进程在分配的资源访问权限内进行资源访问,一般用户程序代码被隔离在进程对应的权限范围内运行,不能越过权限范围访问没有被分配的资源。
但是,内存资源是进程的权限内可以访问的资源,而进程对内存资源可访问的地址是受该进程的页表限制的。那么CPU每次在接收到进程发起的内存访问指令时,均需要查询用户态中对该进程配置的页表,以确定对该进程分配的内存地址列表。如果该内存访问指令所访问的内存地址不在该内存地址列表之内,则CPU无法对该内存访问指令进行执行,可产生异常。
对于通过进程来实现代码安全隔离的方案,CPU在执行进程发起的指令时,CPU为了确认高特级权代码确实分配了特定资源给低特级权的角色实例。每次低特级权的代码在访问资源的时候,CPU在运行该资源访问指令之前,必须对该角色实例所分配的资源进行检查(比如页表),例如确认对该进程分配的内存资源中是否包括该指令所指向的内存资源,那么这将降低CPU的执行效率。
示例性的,容器也是一种代码隔离方案,该方案可以看做为一种特殊的进程方案,它和硬件无关。操作系统可将多个进程成组看待,组内的多个进程之间相互请求的资源可以由CPU提供,不在进程之间的资源访问请求不提供,该方案与图2a的方案类似,容器内的进程不能越过容器的范围访问没有被分配的资源,从而保证容器内进程的代码是安全的。
同理,每次容器内进程中代码在访问资源的时候,CPU在运行该资源访问指令之前,必须对该容器所分配的资源进行检查(比如页表),例如确认对该容器分配的内存资源中是否包括该指令所指向的内存资源,那么这将降低CPU的执行效率。
示例性的,结合图1和图2b,虚拟机是一种代码隔离的方案,虚拟机的方案可以看做是图2a所示的进程隔离方案的叠加。可将操作系统和进程一起看做是一个被管理的对象,那么虚拟机管理代码可以看做是比图1和图2a中的操作系统管理代码具有更高特级权的管理者。虚拟机隔离的逻辑和进程隔离的逻辑类似,下面结合图2b进行简要阐述。
如图2b所示,操作系统代码在虚拟机的权限内运行。对于虚拟机的权限,物理芯片设备可以提供两个地址空间权限的配置,1级配置由虚拟机指定,2级配置由虚拟机管理代码指定。其中,对于2级配置,如图2b所示,虚拟机管理代码可对虚拟机的权限进行配置,以对虚拟机的资源访问范围进行限制。
其中,内存资源是较为重要的资源,不论是进程还是虚拟机或是操作系统等都可以访问内存资源。但是,对于可访问的内存资源的具体地址,虚拟机管理代码可对虚拟机进行限制。如图2b所示,虚拟机管理代码可配置每个虚拟机的2级页表,以设置虚拟机可以访问的内存资源的地址范围。其中,2级页表中可以包括该虚拟机可访问的内存地址的信息,从而使虚拟机管理代码在2级页表上控制虚拟机对内存资源的地址访问权限,进而实现对运行在虚拟机中的操作系统的资源访问地址的范围控制。
运行在虚拟机的权限中的操作系统代码,对内存资源可访问的地址是受该虚拟机的页表限制的。那么CPU每次在接收到虚拟机发起的内存访问指令时,均需要查询对该虚拟机配置的页表,以确定对该虚拟机分配的内存地址列表。如果该内存访问指令所访问的内存地址不在该内存地址列表之内,则CPU无法对该内存访问指令进行执行,可产生异常。
对于通过虚拟机来实现代码安全隔离的方案,CPU在执行虚拟机发起的指令时,CPU为了确认高特级权代码确实分配了特定资源给低特级权的角色实例。每次低特级权的代码在访问资源的时候,CPU在运行该资源访问指令之前,必须对该角色实例所分配的资源进行检查(比如页表),例如确认对该虚拟机分配的内存资源中是否包括该指令所指向的内存资源,那么这将降低CPU的执行效率。
示例性的,结合图2c,安全区是一种代码隔离的方案,安全区的方案可以看做是图2b所示的虚拟机隔离方案的叠加。如图2c所示,代码可分为运行在安全区的安全区代码和运行在非安全区的非安全区代码。其中,安全区代码可包括虚拟机管理代码、操作系统代码和一般用户程序代码等。安全区代码可以在安全区的权限范围内运行。安全管理代码可以看做是比图2c中的虚拟机管理代码具有更高特级权的管理者。安全区的代码隔离的逻辑和图2a所示的进程隔离、图2b所示的虚拟机隔离的逻辑类似,下面结合图2c对与进程隔离和虚拟机隔离的方案的区别之处做简要阐述。
在不同实现场景下,安全区的方案可存在区别。安全管理代码可用于设置安全区和非安全区的工作环境。例如在ARM CPU上,安全区可访问的内存不通过页表指定,而是硬件硬编码决定的,所以,安全区代码是否可以访问特定地址的内存,取决于该硬件硬编码。如果安全区代码接管CPU,并在运行安全区的权限范围内,则CPU对安全区代码发出的请求会添加一个安全标记,使得CPU发出的请求带有安全标记,否则CPU所发出的请求没有这个标记(例如CPU在运行非安全区代码)。CPU和内存之间具有总线,CPU通过总线发送写内存的请求至内存,总线相关逻辑可根据这个标记,决定是否允许这个请求被响应。如果该请求添加了标记,则该请求可以访问内存,如果该请求没有该标记,则丢弃该请求。那么安全管理代码可根据CPU发出的请求是否具有安全标记,来判断CPU可以执行的指令,或者在CPU发出地址访问请求时,可以检测是否有该地址的访问权限。
另一个区别之处在于安全区通常没有多个实例,进程方案可以有多个进程,虚拟机方案可以有多个虚拟机,但安全区可能只有一个,所以这种体系结构常常允许非安全区和安全区之间的代码直接互相调用,而不需要经过安全管理代码进行中转。其中,安全区和非安全区在互相调用时,只能调用对方固定的地址,且所调用的地址受安全管理代码的控制,从而维护了不同区域的安全。
那么安全区代码运行在CPU时,CPU发出的请求具有预设标记,安全管理代码在运行的时候,检查CPU发出的请求是否具有预设标记,以确定该请求可访问的资源范围,这种判断在CPU每次发出请求时都需要执行一次,这提高了运行成本。
总结而言,传统的进程、容器、虚拟机、安全区等代码隔离方案在实施时,CPU在执行指令时,为了确认高特权级代码确实分配了特定资源给低特权级的角色实例。每次低特级权的代码在访问资源的时候,CPU在运行该资源访问指令之前,必须对该角色实例所分配的资源进行检查(比如页表),例如确认对该虚拟机分配的内存资源中是否包括该指令所指向的内存资源,那么这将降低CPU的执行效率。
在一些应用场景下,当程序需要使用第三方代码时,为了确保第三方代码在运行过程中,不会访问本程序中的一些关键信息,传统技术可通过对第三方代码创建进程、容器或虚拟机等角色实例的方式,来将第三方代码的资源访问范围限制在所属角色实例对应的权限内,以实现第三方代码的安全访问。其中,第三方代码对应的角色实例的权限,由更高特级权的代码所分配。传统技术的缺陷如上文所述,CPU每次执行第三方代码的指令,都需要进行权限和资源的检查,这将降低CPU的执行效率。
为此,本申请提供了一种资源控制方法,该方法可在需要保证资源的安全访问的代码(简称受控代码,例如上述第三方代码)运行之前,对受控代码所使用的指令进行扫描。该方法在扫描到受控代码所使用的指令均是受控类指令后,其中,受控类指令在进行资源访问时只能在该受控代码的目标资源访问范围内进行资源访问,那么在受控代码运行过程中,CPU就不需要对受控代码发出的指令进行检查(例如查询对受控代码所属的进程所分配的资源)。那么受控代码所使用的指令不会超出受控代码的目标资源访问范围,从而提升CPU的执行效率。而且,在限制受控代码的资源访问范围时,不需要对受控代码创建相应的角色实例,例如进程、虚拟机等,以在该角色实例内对该受控代码进行权限限制。
实施例1
示例性的,图3a和图3b为示例性示出的系统框架结构示意图。应该理解的是,图3a和图3b所示系统仅是一个范例,本申请的系统可以具有比图中所示的更多的或者更少的模块,可以组合两个或多个的模块,或者可以具有不同的模块配置。图3a、图3b中所示出的各种模块可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
如图3a所示,本申请的提供的资源控制装置可包括控制模块以及受控模块,可选地包括处理模块,所述资源控制装置中的指令被划分为受控类指令和非受控类指令。该资源控制装置可执行下述实施例所述的方法。
示例性的,资源控制装置可实现为中央处理器(CPU),或者任意一种处理器等,本申请对于资源控制装置的实现方式不做限制,为了便于说明,以资源控制装置实现为CPU为例进行说明。
示例性的,处理模块可以是中央处理器中包括一个或多个信号处理和/或专用集成电路在内的硬件,处理模块可用于执行指令,处理模块可执行的指令被划分为受控类指令和非受控类指令,处理模块在执行指令时,并不区分指令类别,可按照指令的语义(或者说编码)来对指令进行解释执行。
其中,受控类指令在被处理模块执行时,处理模块只可以访问控制模块对该受控类指令所分配的特定的资源访问范围,而无法访问特定资源访问范围之外的资源。换言之,受控类指令的语义(或者说编码)决定,受控类指令在被处理模块执行时被限制了资源访问范围。那么处理模块在执行每个受控类指令时,均无需通过查页表等方式来检查当前运行的该受控类指令中的资源访问地址是否在当前运行的程序的资源访问权限范围内,以提升处理模块的指令处理效率。
非受控类指令在被处理模块执行时,可按照该非受控类指令的资源访问地址进行资源访问,而无需对非受控类指令中的资源访问地址进行处理。可选地,处理模块可按照传统的查页表等方式,来确定该非受控类指令所处的进程(或虚拟机等)是否具有该访问地址的访问权限,以决定是否继续执行该非受控类指令。如果该资源访问地址是权限内的访问的地址,则处理模块按照该资源访问地址访问资源,如果该资源访问地址是权限外的访问的地址,则处理模块中断执行该受控模块内的指令。
如图3a所示,本申请所提供的CPU中的处理模块,可支持对受控类指令和非受控类指令这两类指令的执行,并对这两类指令以不同的方式进行执行。
示例性的,处理模块可为CPU中的硬件结构。
示例性的,本申请可在CPU中的上述硬件结构做出改进,使得原本仅支持执行非受控类指令的CPU,在改进后可在硬件上支持受控类指令的解释执行,且CPU可对受控类指令和非受控类指令按照不同的方式进行解释执行。
示例性的,以访问的资源为内存资源为例,对于非受控类指令,处理模块可按照非受控类指令中的内存访问地址,按照传统的方式(例如查页表)进行内存访问;而对于受控类指令,处理模块可对受控类指令中的内存访问地址,映射到特定的内存地址空间内,以在特定的内存地址空间内访问内存,以使受控类指令被CPU执行后所访问的资源有限。
如图3a和图3b所示,CPU中运行的程序可选地包括受控模块、控制模块、非受控模块,在CPU运行上述三个模块中任意一个模块的过程中,处理模块可执行当前运行的模块中的指令,以实现当前运行的模块的功能。
下面对上述三个模块之间的关系做简要描述:
图3b所示,非受控模块,可用于调用第三方开发的受控模块,示例性的,非受控模块可运行在本申请提供的CPU中,以实现对受控模块的调用,示例性的,处理模块可用于执行非受控模块中的指令,非受控模块可包括非受控类指令,可选地,还可包括受控类指令,本申请对此不做限制。
示例性的,受控模块和非受控模块可看做一个模块(一个程序)中的两个部分。示例性的,非受控模块和受控模块可以是调用与被调用的关系。例如,非受控模块首先发起对受控模块的调用,在受控模块运行过程中,受控模块也可以调用非受控模块中的函数等以实现相应功能。
此外,非受控模块和受控模块的开发平台不同,非受控模块并无法完全信任受控模块,以使其访问非受控模块或非受控模块所属模块的任何资源,为了确保受控模块在运行过程中,所执行的操作对非受控模块而言是可控的,非受控模块需要对受控模块所访问的资源进行限制。
为此,本申请提供了上述控制模块,如图3b所示,非受控模块可安装或内嵌有本申请提供的控制模块,以通过控制模块来确保非受控模块在调用受控模块时,受控模块可访问有限的资源。示例性的,控制模块可包括非受控类指令,可选地进一步包括受控类指令。
示例性的,如图3a和图3b所示,控制模块可运行在CPU中,控制模块可用于在非受控模块需要调用受控模块(例如调用函数等)时,在受控模块运行之前,控制模块可通过向处理模块发送非受控类指令,来使处理模块执行该非受控类指令,以实现对受控模块内的指令的扫描。控制模块可扫描受控模块内的指令是否均为受控类指令,在控制模块检测到受控模块内的指令均为受控类指令时,则控制模块可通过向处理模块发送非受控类指令的方式,来对受控模块内的每个指令分配目标资源访问范围(可包括目标地址空间)。这样在受控模块运行后,处理模块在执行受控模块中的受控类指令时,只可以在该目标地址空间内进行资源访问。示例性的,该资源可以是图3a所示的内存资源。
需要说明的是,对受控模块限制访问范围的资源并不限于内存资源,还可包括但不限于内存方式访问外设时外设内的资源。其中,内存中可存储的资源可包括代码和数据,那么内存资源可包括代码资源和数据资源。
示例性的,在对受控模块所限制访问范围的资源为内存资源时,控制模块可对受控模块所访问的内存地址空间进行限制。
示例性的,在对受控模块所限制访问范围的资源为上述外设的资源时,控制模块可对受控模块所访问的外设中的地址空间进行限制。
为了便于说明,本申请各实施例以内存资源的访问限制为例进行说明,当资源为内存资源之外的其他可访问的资源时,方法同理,这里不再赘述。
示例性的,控制模块和受控模块可以是运行在本申请CPU中的软件程序。
可选地,控制模块也可以运行在传统的CPU中,本申请对此不做限制。
下面对受控类指令和非受控类指令进行介绍:
示例性的,受控类指令可包括本申请的自定义指令集,其中,自定义指令集中的指令在被CPU执行时,只可以访问特定的资源范围,而无法访问特定资源范围之外的资源。换言之,自定义指令集中的指令在被CPU执行时被限制了资源访问范围。
可选地,受控类指令还可包括对非受控模块的代码和数据的安全无影响的一些传统的指令(例如加法指令、减法指令等不需要访问内存资源的指令),这些对非受控模块中的代码和数据的安全无影响的指令可根据需要而灵活设置,本申请对此不做限制。
示例性的,对于受控类指令中与资源无关预设指令(即不需要访问资源的指令,以资源为内存资源为例),则控制模块无需对该预设指令分配目标资源访问范围,控制模块只需对受控模块内需要访问内存资源的每个受控类指令分配目标资源访问范围。这里以访问的资源为内存资源为例。
非受控类指令可以是除受控类指令之外的任意指令。
非受控类指令可包括但不限于:第三类指令和第四类指令。
示例性的,第三类指令在被CPU执行时,CPU可访问代码以及执行该代码。
示例性的,第三类指令可包括但不限于:jump(跳转)指令,本申请对此不做限制。
其中,jump指令用于指令跳转,可用于函数调用的场景,能够用于访问代码,也是一种内存访问指令。
示例性的,jump指令可归类为访问内存中代码的指令,jump指令可简称“非受控类的跳转指令”。
示例性的,第四类指令在被CPU执行时,CPU可访问数据。
第四类指令可包括但不限于:load(加载)指令、store(存储)指令、堆栈访问指令等,本申请对此不做限制。
其中,load指令在被执行时,CPU可按照指令中内存访问地址,将内存中的数据加载至CPU;store指令在被执行时,CPU可按照指令中的内存访问地址,将CPU中的数据写入内存。
堆栈访问指令可包括push(进栈)指令和pop(出栈)指令,其中,堆栈访问指令也是一种内存访问指令。
load指令、store指令、push指令、pop指令可归类为访问内存中数据的指令。
如上文所述,受控类指令可包括本申请的自定义指令集,可选地还可包括对非受控模块的代码和数据的安全无影响的一些传统的指令,为了便于说明,后文各个实施例,以受控类指令为这里的自定义指令集为例进行说明。
示例性的,对于受控类指令,自定义指令集的指令类型可包括但不限于:load_short指令、store_short指令,short_push指令、short_pop指令、short_jump指令。
以内存资源为例,自定义指令集中的指令只可以在特定的内存地址空间中访问数据或访问代码。
其中,load_short指令在被CPU执行时,CPU可基于该load_short指令的语义来执行指令,从而按照预设算法将特定的内存地址空间中的数据加载至CPU;
示例性的,load_short指令可分为多种编码的load_short指令,为了便于理解,可描述为load_shortN,N为正整数,不同编码的load_short指令对应的N取值不同。
不同编码的load_short指令,在被CPU执行时,CPU在将内存地址空间中的数据加载至CPU时,示例性的,加载过程可存在区别,但是不同编码的load_short指令在执行时均资源访问范围受限。同理,自定义指令集中的其他指令(例如store_short指令),也可以包括多种编码的同一类指令。
store_short指令在被CPU执行时,CPU可基于该store_short指令的语义来执行该store_short指令,以按照预设算法将CPU中的数据写入至特定的内存地址空间;
需要说明的是,load指令和load_short指令的指令编码不同,它们都是用于将内存中的数据加载至CPU的指令,但是load_short指令的资源范围范围受限;同理,store指令和store_short指令的指令编码不同,store_short指令的资源访问范围受限。
同理,short_push指令、short_pop指令是相较于传统的push指令、pop指令,short_push指令、short_pop指令在被CPU执行时,CPU可按照本申请的预设算法,在特定的堆栈地址空间内进行进栈和出栈的指令,以在受限的堆栈地址空间内进行资源访问。
同理,short_jump指令是相较于传统的jump指令,short_jump指令在被CPU执行时,CPU可按照本申请的预设算法,在特定的内存地址空间中进行代码访问的指令。
那么自定义指令集中的指令也可以分为两类指令:
第一类指令在被CPU执行时,CPU可访问代码资源并运行该代码资源。
第一类指令可包括但不限于:short_jump指令。
示例性的,第一类指令可简称“受控类的跳转指令”。
第二类指令在被CPU执行时,CPU可访问数据资源。
第二类指令可包括但不限于:load_short指令、store_short指令,short_push指令、short_pop指令等。
示例性的,为了便于说明,后文以受控类指令即为上述自定义指令集,以对受控类指令限制的资源访问范围为内存资源访问范围为例进行说明,那么受控类指令则均为内存访问指令,可分为上述第一类指令和第二类指令。
此外,为了行文简便,全文描述的“XX指令为用于访问代码资源的指令”,用于表示XX指令在被CPU(或者CPU中的处理模块)执行时,CPU(或者CPU中处理模块)可访问代码资源并运行该代码资源。同理,“XX指令为用于访问数据资源的指令”,用于表示XX指令在被CPU(或者CPU中的处理模块)执行时,CPU(或者CPU中处理模块)可访问数据资源。
继续参照图3a,控制模块可扫描受控模块中的指令是否均为受控类指令,示例性的,控制模块可包括上述自定义指令集,控制模块可通过扫描受控模块内的指令并与该自定义指令集内的指令进行对比,来检测受控模块内的指令是否均为受控类指令。
可选地,控制模块检测到受控模块内的指令均为自定义指令集内的指令,则控制模块可以确定受控模块内的指令均为受控类指令。
可选地,控制模块检测到受控模块内的指令中存在除该自定义指令集之外的指令,则控制模块可以确定受控模块内的指令不均为受控类指令。
示例性的,可参照图3a,在控制模块检测到受控模块中的指令均为受控类指令时,控制模块可通过向处理模块发送非受控类指令,来写入目标地址参数至处理模块(例如处理模块中的存储单元),以限制受控模块的目标资源访问范围,例如内存的目标地址空间。
具体而言,示例性的,在控制模块对所述受控模块内的每个指令分配目标资源访问范围时,控制模块可向处理模块发送非受控类指令,处理模块在执行该非受控类指令时,可对受控模块内的每个受控类指令,在内存中分配可访问的目标地址空间,以及确定该目标地址空间的目标地址参数。此外,控制模块还可向处理模块发送非受控类指令,处理模块在执行该非受控类指令时,可将上述目标地址参数写入存储单元。从而实现对受控模块内的每个指令的目标资源访问范围的分配。
本实施例中,通过处理模块执行非受控类指令来对受控模块内的每个受控类指令分配目标资源访问范围,其目的在于,如果受控类指令在被处理模块执行时,处理模块可对受控模块分配目标资源访问范围,那么受控模块就可通过发送通过扫描确认的受控类指令至处理模块,来使处理模块修改对受控模块内每条指令所分配的目标资源访问范围。例如,受控模块将目标资源访问范围修改为控制模块不允许受控模块访问的资源访问范围,使得受控模块的资源访问范围无法受控制模块所控制。从而无法达到通过控制模块来限制受控模块的目标资源访问范围的目的,使得受控模块容易访问到敏感内存资源(例如存储有用户账号数据等数据的内存空间)。那么本申请实施例中,控制模块作为对受控模块的资源访问范围的限制方,处理模块可通过执行控制模块内的非受控类指令,来对受控模块内的每个受控类指令分配目标资源访问范围,使得受控模块的资源访问范围是受控制模块控制的,受控模块自身无法修改其自身可访问的目标资源访问范围,从而确保受控模块对资源的安全访问。
可选地,用于存储该目标地址参数的存储单元,可以内置于CPU。
可选地,该存储单元可以内置于处理模块,或内置于CPU但外置于处理模块(其中,处理模块可与存储单元通信连接)。
可选地,存储单元也可以是独立于CPU之外的外置芯片中的存储单元,处理模块可访问外置芯片中的存储单元。
示例性的,存储单元可以是寄存器(包括但不限于段寄存器等)、磁头等。
考虑到非受控模块对所调用的不同受控模块所限制的资源访问范围可存在区别,该区别可根据需要而灵活配置。那么在受控模块运行在本申请的CPU之前(例如非受控模块调用受控模块之前),控制模块可运行在本申请的CPU中,并通过非受控类指令来更新存储单元中的目标地址参数,以确保非受控模块待调用的受控代码仅可以在该目标地址参数所限制的特定地址空间内访问内存资源。
可选地,目标地址参数可包括多组地址参数,控制模块可对受控模块中的受控类指令,按照指令类型,来对不同类型的受控类指令,分配不同的地址参数,以使受控模块中不同类型的受控类指令在被CPU执行时,CPU所访问的地址空间存在区别。示例性的,一组地址参数对应于一个地址空间。
可选地,在目标地址参数包括多组地址参数时,各组地址参数所存储至的存储单元可以相同或不同。
示例性的,目标地址参数可通过非受控类指令设置,而无法通过受控类指令设置,以避免受控模块通过发送受控类指令至处理模块,以修改其可访问的地址空间。
示例性的,目标地址参数可在受控模块运行之前,由控制模块通过发送非受控类指令来写入至存储单元。
可选地,在受控模块运行过程中,控制程序无法通过非受控类指令,来更新对该受控模块中的受控类指令所分配的目标地址参数。
可选地,在受控模块运行结束之后,控制程序可通过非受控类指令来将存储单元中针对该受控模块的目标地址参数清空,以便于处理模块执行下一个受控模块中的代码。
在控制模块写入目标地址参数至处理模块,由处理模块将目标地址参数写入存储单元之后,非受控模块可调用受控模块,以使受控模块运行在CPU中。
在受控模块运行过程中,处理模块可执行受控模块当前运行的受控类指令(例如目标指令),处理模块在执行该目标指令时,可将目标指令中的原内存访问地址映射至该目标指令对应的目标地址空间内,得到该原内存访问地址在该目标地址空间中对应的目标内存访问地址;处理模块按照该目标内存访问地址来访问内存资源。
示例性的,处理模块可对目标指令中的原内存访问地址进行处理,使得处理后的内存访问地址(即目标内存访问地址),在该目标指令对应的目标地址空间内,处理模块并按照目标内存访问地址来访问内存资源。
示例性的,处理模块可执行接收到的目标指令,在存储单元中读取对该受控模块内的该目标指令(一个受控类指令)所设置的目标地址参数,并按照预设算法,基于目标地址参数和目标指令中的原内存访问地址,来在该目标指令对应的目标地址空间中确定目标内存访问地址;处理模块在目标内存访问地址处访问内存资源。
示例性的,在原内存访问地址超出目标地址空间时,则处理模块可按照该目标地址参数来将原内存访问地址的部分高位置零,使得处理后的目标内存访问地址在目标地址空间内。简单来描述,例如目标地址空间为1至100,原内存访问地址为1000,则可将原内存访问地址的地址长度缩小10倍,得到目标内存访问地址100,使得目标内存访问地址在目标地址空间内。
在本申请实施例中,为了能够使目标指令在被处理模块执行时,只可以访问对该目标指令设定的目标地址空间内的资源,处理模块按照该目标指令的编码,在执行该目标指令时,可按照上述算法对原内存访问地址进行处理(例如多个高位地址置为零)。那么不论目标指令中的原内存访问地址是否在目标地址空间内,处理后的目标内存访问地址均在目标地址空间内。
例如,即便受控模块的一段代码请求调用目标地址空间之外的某个地址1处的代码资源,处理模块在执行该段代码对应的受控类指令时,则可将地址1按照上述算法映射到该目标地址空间内的地址2。那么无论受控模块请求访问的资源的地址在哪里,处理模块在执行受控模块的目标指令时,都可在目标地址空间内找到一个与该原内存访问地址对应的目标内存访问地址,并访问该目标内存访问地址处的资源作为对原内存访问地址的访问结果。
这样,本申请实施例的处理模块在执行目标指令时,并不是直接按照该目标指令的原内存访问地址进行资源访问,而是找到该原内存访问地址在目标地址空间内映射的目标内存访问地址,并在目标内存地址处访问子。能够从目标指令的访问地址的维度进行受控模块可访问资源的限制,目标内存访问地址所指向的资源是准确且唯一的,那么这种精细化维度的资源限制方式,能够确保受控模块的任意指令所访问的资源是已经预先确定好的唯一资源。
可选地,处理模块还可执行控制模块发送的非受控类指令,以在控制模块的内存访问权限内,访问内存中的任意地址空间。
可选地,在受控模块运行之前,如果控制模块扫描到受控模块包括非受控类指令时,则控制模块可提示错误,以拒绝执行受控模块,确保受控模块只可以访问由目标地址参数所限制的目标地址空间内的内存资源。
可选地,在受控模块运行之前,如果控制模块扫描到受控模块中包括非受控类指令时,并且,该非受控类指令为上述第三类指令(被处理模块执行时,处理模块可访问代码),例如非受控类的跳转指令。那么控制模块在检测到该非受控类的跳转指令所跳转访问的函数是预设函数(可包括下文所述的第一预设函数和第二预设函数)时,则也可以说明受控模块(例如插件)是安全的,控制模块允许受控模块运行。其中,预设函数为控制模块允许受控模块访问的在受控模块的资源访问范围之外的函数。
示例性的,图3a和图3b的系统,可结合以下示例来理解:
应用1(非受控模块的一个示例)中需要运行第三方开发的插件(受控模块的一个示例),以实现应用1的一项新功能,那么为了确保插件不会访问应用1中的敏感信息(例如用户信息等),应用1可内嵌本申请提供的控制程序(控制模块的一个示例)。
该控制程序可在应用1运行该插件之前,扫描插件中的指令,在扫描到插件中的指令均为受控类指令时,说明插件是安全的。然后,控制程序可对插件中的每个受控类指令设置内存资源访问范围,控制程序具体可通过非受控类指令,来将限制内存访问空间的地址参数写入本申请的CPU中的段寄存器(存储单元的一个示例)。
其中,将目标地址参数写入段寄存器的指令可为非受控类指令,而不可以是受控类指令,这样,可以避免上述插件在运行过程中,通过CPU执行受控类指令来修改段寄存器内的目标地址参数的情况。而目标地址参数可用于确定插件内的受控类指令可访问的目标地址空间,这样可以避免插件在运行过程中,篡改CPU内对应于该插件的指令的段寄存器内的数据,造成插件访问该目标地址空间之外的资源的情况。
然后,应用1可以调用插件,使得插件运行后,向处理模块发送受控类指令,以使处理模块执行该受控类指令,对受控类指令中的原内存访问地址,按照段寄存器中的地址参数,在所限制的内存访问空间中确定目标内存访问地址,并在内存中访问该目标内存访问地址。
这样,应用1在调用第三方开发的插件时,能够在使用插件的功能的同时,确保插件只可以在限制的内存地址空间中访问数据资源和代码资源,确保插件对应用1的资源的安全访问。
可选地,在控制程序扫描到插件中包括非受控指令时,说明插件不安全,控制程序可报错,以禁止插件运行。
可选地,在控制程序扫描到插件中包括非受控类指令时,且该非受控类指令为非受控类的跳转指令,那么若该跳转指令所访问的函数是预设函数,则也可以说明插件是安全的。然后执行上述分配内存资源访问范围等操作,这里不再赘述。
其中,预设函数为控制程序指定该插件可访问的外部函数,所谓外部函数即为非受控程序中的函数。
示例性的,受控模块为受控程序,该受控程序是编译后的程序(二进制数据文件,例如插件)。
可选地,控制模块可包括编译模块,示例性的,编译模块为编译器。
那么当第三方提供一款未编译的程序1时,非受控模块在调用该程序1之前,本申请的控制模块可通过编译器来对该程序1进行编译。示例性的,本申请的编译器,在对程序1内的高级语言的程序代码进行编译时,可按照受控类指令,来对程序代码进行编译,使得编译后的文件(后文也称指令文件)中只包括受控类指令。
示例性的,对于待编译的程序代码中表示将内存中的数据加载到CPU的代码,传统编译器可编译为load指令,本申请的编译器则编译为load_short指令。
示例性的,对于待编译的程序代码中表示将CPU中的数据写入内存的代码,传统编译器可编译为store指令,本申请的编译器则编译为store_short指令。
示例性的,对于待编译的程序代码中调用函数的程序代码,传统编译器可编译为jump指令,本申请的编译器编译为short_jump指令。
示例性的,对于待编译的程序代码中堆栈访问数据的程序代码,传统编译器可编译为push指令或pop指令,本申请的编译器编译为short_push指令或short_pop指令。
示例性的,受控模块为插件(已经编译完成),那么控制模块在扫描插件后,如果扫描到非受控类指令,则说明该可能插件采用了非法编译器,即非本申请提供的编译器,或者,经本申请提供的编译器编译后,编译后的程序被手工篡改。那么控制模块可拒绝执行该插件。
示例性的,受控模块为插件,那么本申请的编译器可按照受控类指令来对插件进行编译,生成编译后的受控代码。那么控制模块在扫描受控代码中的指令时,可以确定受控代码中均为受控类指令,可以在非受控代码中运行该受控代码。
可选地,受控模块也可以是不需要进行编译的模块,例如受控模块通过汇编语言编写,则在控制受控模块的资源访问范围时,可不使用本申请的编译器。
需要说明的是,图3a中控制模块来扫描受控模块中的指令是否均为受控类指令的步骤时,运行该受控模块的CPU可为传统的任意一种CPU。但是,控制模块在执行图3a所示的发送非受控类指令至处理模块,以将限制受控模块的资源访问范围的目标地址参数,写入至存储单元的过程,则在本申请提供的CPU中实现。
示例性的,同一个模块在不同环境下可为受控模块,也可以为非受控模块。
例如,浏览器App在用户的手机上运行,但是浏览器App不是手机平台开发的,那么手机的操作系统代码可为非受控模块,该浏览器App的代码可为受控模块,为了限制浏览器App在手机上的资源访问范围,手机操作系统可内嵌本申请提供的控制模块。那么在操作系统运行该浏览器App之前,操作系统中的控制模块可扫描浏览器App是否均为受控类指令,如果是,则允许浏览器App运行,否则报错不允许浏览器App运行,以确保操作系统的资源的安全访问。
再如,浏览器App希望加载一个动态库,调用动态库中的函数,那么浏览器App是非受控模块,该动态库是受控模块。浏览器App无法确保动态库中的代码是否越权访问浏览器App的内容。浏览器App为了确保动态库无法访问未分配给它的资源,浏览器App可内嵌有本申请提供的控制模块,以使浏览器App在调用任何第三方平台开发的程序时,该第三方平台开发的程序只可以使用受控类指令运行,使得第三方平台开发的程序可访问的资源内容是有限的。本例中,在浏览器App调用该动态库中的函数之前,浏览器App中的控制程序可扫描动态库中的函数是否均为受控类指令,如果是,则允许动态库中的函数运行,否则报错不允许动态库中的函数运行,以确保浏览器App的资源的安全访问。
本申请实施例中将CPU内的指令被划分为受控类指令和非受控类指令,可按照上述两类指令的不同执行方式进行执行,使得CPU可支持运行不受资源访问范围限制的模块(例如非受控模块,其中,非受控模块可用于调用受控模块),以及支持运行受资源访问范围限制的模块(例如上述受控模块),丰富了CPU可执行的指令的类型,并实现了对运行在CPU中的受控模块的资源范围的访问控制。
本申请实施例中,受控类指令在被CPU执行时,CPU只可以访问对该受控类指令所分配的有限的资源访问范围,那么在受控模块运行之前,由控制模块扫描受控模块内的指令是否均为受控类指令,可在受控模块运行之前,通过控制模块来实现对受控模块内指令类型的检查。若控制模块检测到受控模块内的指令均为受控类指令,则可以确定受控模块在运行时不会访问超出其资源访问范围的资源,以确保受控模块在运行时的资源安全访问。也即在受控模块运行前,通过控制模块对受控模块进行指令扫描,可以确定该受控模块是否是安全的,在确定受控模块安全的情况下,才会运行该受控模块。本申请实施例能够在受控模块运行前,实现对第三方提供的受控模块的安全检查,无需在受控模块运行过程中,实时检查每个待执行的指令是否安全,提升了对受控模块的运行效率。
本申请的控制模块可用于内嵌代码的场景下,即一个角色实例(包括但不限于用户态进程、虚拟机、操作系统等)中的非受控模块,需要执行内嵌该非受控模块的受控模块的场景,内嵌在非受控模块中的控制模块可区分受控类指令和非受控类指令,以在受控模块运行之前扫描受控模块是否包括非受控类指令,来决定受控模块是否可被非受控模块调用而运行,能够实现对外部模块的安全性校验。处理模块可执行的指令被划分为受控类指令和非受控类指令,处理模块在执行受控类指令时,可在控制模块对该受控类指令所设置的有限的地址空间内进行资源访问,以确保外部模块对非受控模块的资源的安全访问。
实施例2
可选地,图4a示例性的示出了本申请的系统的运行流程图,结合于图3a和图3b,请参照图4a和图4b,控制模块可实现为控制代码,受控模块可实现为受控代码,非受控模块可实现为非受控代码。
本申请的CPU包括处理模块,并且CPU可选地运行受控代码,可选地运行控制代码。处理模块可执行运行在CPU中的代码中的指令。
图4b示例性的示出了图4a实施例的内存地址空间的示意图。
在受控代码运行在本申请的CPU之前,CPU可运行控制代码的指令,那么控制代码通过处理模块来执行S101、S103以及S105。
S101,控制代码通过处理模块扫描受控代码中的指令,来确定受控代码中的指令是否均为受控类指令。
示例性的,以App1调用第三方开发的插件1为例进行说明,App1中内嵌有本申请的控制代码,如图4b所示,App1的非受控代码在内存中的地址空间为d0至d3,其中,内嵌在非受控代码中的控制代码的地址空间为d1至d2,App1的非受控代码在进程1内运行。处理模块在进程1的权限内执行App1的非受控类指令,其中,d0至d3地址空间存储的是非受控类指令。
示例性的,非受控代码可包括非受控类指令,可选地也可以包括受控类指令,本申请对此不做限制。
示例性的,控制代码可向处理模块发出非受控类指令,以访问进程1权限内的任意地址空间。可选地,控制代码也可以包括受控类指令,本申请对此不做限制。
示例性的,如图4b的虚线箭头所示,控制代码可访问内存中的地址空间d3至d4,地址空间d4至d5,地址空间d6至d7。需要说明的是,这只是示例,并不用于限制本申请。
可选地,App1或控制代码,可将插件1的代码(即受控代码)写入内存中,以实现处理模块从内存中读取控制代码的指令,以执行控制代码的指令来对插件1的指令的扫描。
其中,处理模块执行的指令为控制代码中的指令,该指令被处理模块执行时,处理模块可将插件1中的指令作为处理模块读取的数据进行扫描,扫描插件1中的指令是否均为受控类指令。
示例性的,如图4b所示,受控代码(例如插件1)在内存中存储的地址空间为d4至d5,那么控制代码可扫描地址空间d4至d5中的受控代码,以检测受控代码中的指令是否均为受控类指令。
可选地,在控制代码检测到受控代码中包括非受控类指令时,则提示错误,以拒绝执行受控代码。
示例性的,在控制代码检测到受控代码中的指令均为受控类指令时,则转至S103。
S103,控制代码对受控代码确定第一地址空间和第一地址参数,以及第二地址空间和第二地址参数。
如上述实施例所述,受控类指令可分为第一类指令和第二类指令。
示例性的,以限制访问范围的资源为内存资源为例,第一类指令在被CPU执行时,CPU可访问内存中的代码资源并运行该代码资源。
第一类指令可包括但不限于:short_jump指令。
第二类指令在被CPU执行时,CPU可访问数据资源。第二类指令包括但不限于:load_short指令、store_short指令,short_push指令、short_pop指令等。
那么控制代码在对受控代码中的每个受控类指令分配目标资源访问范围时,控制代码可对受控代码中的第一类指令分配第二资源访问范围,对第二类指令分配第三资源访问范围。其中,所述第二资源访问范围和所述第三资源访问范围之间的资源访问地址不同。
示例性的,控制代码在对受控代码中的第一类指令分配第二资源访问范围时,控制代码可对受控代码中的每个第一类指令分配第一地址空间,以及与该第一地址空间对应的第一地址参数。
其中,第一地址空间用于存储受控代码中受控类指令可访问的代码资源。
示例性的,第一地址参数可用于确定第一地址空间的地址范围。
示例性的,控制代码在对受控代码中的第一类指令分配第三资源访问范围时,控制代码可对受控代码中的每个第二类指令分配第二地址空间,以及与该第二地址空间对应的第二地址参数。
其中,第二地址空间用于存储受控代码中受控类指令可访问的数据资源。
示例性的,第二地址参数可用于确定第二地址空间的地址范围。
如图4b所示,在控制代码扫描受控代码之前,控制代码已经将受控代码写入至地址空间d4至d5,那么在控制代码检测到受控代码中的指令均为受控类指令时,可将地址空间d4至d5作为分配给受控代码的第一地址空间。
此外,控制代码还可在非受控代码可访问的内存的地址空间中,确定分配给受控代码的第二地址空间。
可选地,控制代码在对受控代码中的受控类指令,分配第一地址空间和第二地址空间时,对于所分配的地址空间的空间大小,可按照控制代码所内嵌至的非受控代码(例如控制代码所内嵌的上述App1)对该受控代码(例如插件1)所规定的预定大小的空间,或者根据受控代码的需求,来确定对受控代码所分配的第一地址空间和第二地址空间的大小。
如图4b所示,第一地址空间为地址空间d4至d5,即受控代码可访问的代码所存储的地址空间;第二地址空间为地址空间d6至d7,即受控代码可访问的数据(简称“受控数据”)所存储的地址空间。
需要说明的是,第一地址空间和第二地址空间之间的地址不同。受控代码可通过第一类指令,来访问内存中存储在第一地址空间内的代码,以及通过第二类指令,来访问内存中存储在第二地址空间中的数据。如果第一地址空间和第二地址空间存在重叠的地址,那么重叠的地址可存储代码以及数据,那么受控代码可在控制代码扫描其指令均为受控类指令之后,通过例如store_short指令,来访问该重叠的地址,并修改该重复的地址处的代码,使得受控代码中的代码(也即指令)被修改为非受控类指令,从而能够在所限制的第一地址空间和第二地址空间之外进行数据或代码的访问。本申请通过对受控代码中的受控类指令,配置不同的第一地址空间和第二地址空间,以免受控代码在经扫描通过允许运行后,受控代码再次修改内部代码,使受控代码包括非受控类指令,以访问未分配的内存资源,从而避过控制代码的扫描。
示例性的,控制代码对受控代码中的第一类指令分配了第一地址空间之后,控制代码可确定第一地址空间对应的第一地址参数。
示例性的,第一地址参数可用于确定第一地址空间的地址范围,可选地,第一地址参数用于对第一类指令中的第一访问地址,确定在该第一地址空间中映射的第二访问地址。
那么控制代码可基于第一地址空间的地址范围,按照第一预设算法来确定第一地址参数。
需要说明的是,第一预设算法的具体算法的差异,可使得所确定的第一地址参数的参数类型也可存在区别,并申请对于第一地址参数的具体参数不做限制,对于基于第一地址空间的地址范围来确定第一地址参数的第一预设算法也不做限制。第一预设算法以及后续实施例提及的第二预设算法、第三预设算法及第四预设算法,均可以是任意一种能够实现限制受控代码的资源访问范围的功能的算法,本申请对于具体算法不做限制。
示例性的,第一地址参数可包括code_base参数和code_limit参数。
其中,code_base参数可表示第一地址空间的起始地址(即首地址),code_limit参数可以是第一地址空间的地址范围参数(可理解为第一地址空间的长度),包括但不限于空间大小,或控制空间大小的二进制掩码等。
示例性的,控制代码,对受控代码中的第一类指令所分配的第一地址空间可以是连续或者不连续的地址空间,本申请对此不做限制。
同理,处理模块在执行控制代码中的第一类指令时,也可以按照相应的第一预设算法,来基于data_base参数和data_limit参数,对第一类指令中携带的第一访问地址进行计算,以得到限制在第一地址空间内的最终访问的第二访问地址。
例如,图4b中受控代码的第一地址空间为连续的地址空间d4至d5。
示例性的,对于受控代码中的第一类指令在分配第一地址空间时,可对第一类指令中的不同指令,来分配相同或不同的第一地址空间。
同理,控制代码对受控代码中的第二类指令分配了第二地址空间之后,控制代码可确定第二地址空间对应的第二地址参数。
控制代码确定第二地址空间对应的第二地址参数的原理,与上文描述的确定第一地址空间对应的第一地址参数的原理相同。
示例性的,第二地址参数可用于确定第二地址空间的地址范围,可选地,第二地址参数用于对第二类指令中的第三访问地址,确定在该第二地址空间中映射的第四访问地址。
那么控制代码可基于第二地址空间的地址范围,按照第三预设算法,来确定第二地址参数。
需要说明的是,第三预设算法的具体算法的差异,可使得所确定的第二地址参数的参数类型也可存在区别,并申请对于第二地址参数的具体参数不做限制,对于基于第二地址空间的地址范围来确定第二地址参数的第三预设算法也不做限制。
示例性的,第二地址参数可包括data_base参数和data_limit参数。
其中,data_base参数可表示第二地址空间的起始地址(即首地址),data_limit参数可以是第二地址空间的地址范围参数(可理解为第二地址空间的长度),包括但不限于空间大小,或控制空间大小的二进制掩码等。
示例性的,控制代码,对受控代码中的第二类指令所分配的第二地址空间可以是连续或者不连续的地址空间,本申请对此不做限制。
同理,处理模块在执行控制代码中的第二类指令时,也可以按照相应的第三预设算法,来基于data_base参数和data_limit参数,对第二类指令中携带的第三访问地址进行计算,以得到限制在第二地址空间内的最终访问的第四访问地址。
S105,控制代码写入第一地址参数和第二地址参数至处理模块中不同的存储单元。
示例性的,控制代码可将code_base参数和code_limit参数分别写入处理模块中的两个寄存器内,例如寄存器1和寄存器2,以及将data_base参数和data_limit参数分别写入处理模块中的另外两个寄存器内,例如寄存器3和寄存器4。
也就是说,第一地址参数和第二地址参数所对应的存储单元不同。
示例性的,上述寄存器可以是段寄存器,但是,本申请对于写入有第一地址参数或第二地址参数的存储单元的类型并不限制于寄存器,可以是处理模块内部的任何硬件存储单元,可选地,也可以是独立于处理模块之外的芯片内的硬件存储单元。
另外,本申请对于控制代码将第一地址参数和第二地址参数写入存储单元的时机不做限制,可以先后写入,也可以同时写入。
需要说明的是,将第一地址参数和第二地址参数写入存储单元的指令为控制代码中的非受控类指令,换言之,受控程序中并不包括用于写入第一地址参数和第二地址参数至存储单元的非受控类指令。例如App1所调用的插件,插件中不包括修改code_base参数和code_limit参数的非受控类指令,以及修改data_base参数和data_limit参数的非受控类指令,且插件也无法访问能够修改code_base参数和code_limit参数,以及data_base参数和data_limit参数的非受控类指令。
示例性的,受控的堆栈访问指令(例如short_push指令和short_pop指令),也是受控类指令,控制代码对该受控的堆栈访问指令执行的操作,与上述示例中对内存访问的指令执行的操作类似,这里不再一一赘述。
示例性的,控制代码可以对受控的堆栈访问指令分配地址空间,并确定该地址空间的地址参数,例如stack_base参数(表示栈的起始地址)和stack_limit参数(表示栈的空间的大小)。以及控制代码可将stack_base参数和stack_limit参数写入寄存器,使得处理模块在执行受控代码中的short_push指令或short_pop指令时,可对待访问的栈地址addr,在stack_base参数和stack_limit参数限制的栈的地址空间范围内确定最终访问的栈地址,并进行进栈,或出栈的操作。
在S105之后,控制代码将允许受控代码运行,那么非受控代码可调用受控代码,以使得本申请的图3a中的CPU可运行受控代码,那么处理模块可执行受控代码的指令。
对于上述S101至S105,以示例来说明:示例性的,可结合图4b来理解该示例,在App1调用插件1之前,App1的代码运行在进程1中,处理模块在进程1的权限内工作,那么处理模块可执行内嵌在App1中的控制代码中的非受控类指令,来执行以下操作:对插件1中的指令进行扫描,并在扫描确认均为受控类指令后,对插件1中的第一类指令分配可访问代码的第一地址空间d4至d5,以及对第二类指令分配可访问数据的第二地址空间d6至d7;以及确定第一地址空间的code_base参数和code_limit参数,第二地址空间的data_base参数和data_limit参数,并将这些参数写入处理模块的寄存器中,其中,不同参数可写入不同的寄存器。然后,App1可调用插件1,如果插件1(即受控代码)未写入内存,则处理模块可执行App1的非受控类指令,来将受控代码写入第一地址空间d4至d5。然后,经App1调用插件1,使得插件1运行后,处理模块可执行插件1中的受控类指令。
示例性的,如图4a所示,在S105之后,可选地包括S201、S203和S205。
S201,处理模块接收受控代码发送的用于访问代码资源的第一类指令。
示例性的,第一类指令为short_jump指令,该指令可携带第一访问地址addr。
S203和S205:处理模块可执行该第一类指令,来从第二存储单元读取第一地址参数,然后,基于该第一地址参数和第一访问地址,来在第一地址空间中确定第二访问地址,并从位于第一地址空间内的第二访问地址处访问代码资源。
示例性的,处理模块从第二访问地址处访问的代码资源为受控类的跳转指令,例如short_jump指令。
示例性的,处理模块可从寄存器1和寄存器2中分别读取code_base参数和code_limit参数。
示例性的,code_base参数为第一地址空间的首地址,code_limit参数为控制第一地址空间大小的二进制掩码。
示例性的,处理模块在执行第一类指令时,可按照第二预设算法code_base+[code_limit(mask)OR addr],来在由code_base和code_limit限制的第一地址空间中,对该第一类指令中的原内存访问地址addr进行映射,得到限制在第一地址空间内的目标访问地址。
例如,第一地址空间为0至ffff,那么可以确定code_base=0x00000000,code_limit=0x0000ffff。
例如受控代码中的short_jump指令访问的第一访问地址addr1为0x12345678,addr1并不在第一地址空间0至ffff的范围内,那么本申请的处理模块在执行该short_jump指令时,可对code_limit和addr1进行与运算,使得addr的高8位变为0,得到addr2为0x00005678。其中,addr2的地址长度在code_limit限制的长度内。然后,处理模块计算code_base+addr2,得到第二访问地址addr3,这里code_base为0,因此,addr3=addr2,显然short_jump指令的跳转地址被限制在addr3(这里为0x00005678),这不会产生错误,而且能够使受控代码仅访问第一地址空间内的资源。其中,addr3在0至ffff的地址范围内(code_base和code_limit限制的第一地址空间)。
相比于CPU处理每个指令,均进行查页表的遍历操作,本申请的CPU在执行受控类指令时,只需要对受控类指令中的原访问地址,按照相应算法,将该原访问地址映射到所限制的地址空间内,可得到在限制的地址空间内的目标地址,计算目标地址的速度相比于查页表的速度更快,CPU的指令执行效率更高。
需要说明的是,上述第一预设算法与这里的第二预设算法是相互对应的算法,在第一预设算法变化的情况下,第二预设算法同样发生变化。
需要说明的是,本申请对于上述第一预设算法、第二预设算法以及第一地址参数的参数类型均不作限制,可采用传统的任意一种能够实现本申请的功能的算法,来将超出限制的地址范围的地址进行处理,使得处理后的地址在该地址范围内。
此外,本申请对于受控类指令中所携带的内存访问地址(例如上述第一访问地址)的数量也不做限制,可以是一个或多个第一访问地址,但不论是多少个内存访问地址,处理模块在执行该受控类指令时,均需要基于第二预设算法来对受控类指令所携带的第一访问地址进行计算,来在对该受控类指令所分配的内存的第一地址空间中,确定该最终可访问的第二访问地址。
示例性的,例如S201中的第一类指令为short_jump指令,那么如图4b所示,受控代码可在受控代码内部进行跳转,例如受控代码内的函数调用。
本申请实施例的处理模块在接收到受控代码中的第一类指令,例如short_jump指令时,可在存储该short_jump指令的地址参数的段寄存器中(例如寄存器1和寄存器2)分别读取code_base参数和code_limit参数,以利用这两个参数对short_jump指令的访问地址(即跳转地址)进行处理,使得处理后的访问地址限制的第一地址空间,以实现代码资源的有限访问。
可选地,如图4a所示,在S105之后,可选地包括S301、S303和S305。
S301,处理模块接收受控代码发送的用于访问数据资源的第二类指令。
示例性的,第二类指令为load_short指令,该指令可携带第二访问地址addr。
S303和S305:处理模块可执行该第二类指令,来从第二存储单元读取第二地址参数,然后,基于该第二地址参数和第三访问地址,来在第二地址空间中确定第四访问地址,并从位于第二地址空间内的第四访问地址处访问数据资源。
示例性的,处理模块可从寄存器3和寄存器4中分别读取data_base参数和data_limit参数。
示例性的,data_base参数为第二地址空间的首地址,data_limit参数为控制第二地址空间大小的二进制掩码。
示例性的,处理模块在执行第二类指令时,可按照第四预设算法data_base+[data_limit(mask)OR addr],来得到该第二类指令中的内存访问地址addr,在由data_base和data_limit限制的第二地址空间中,对addr进行映射,得到可访问的内存地址。
例如,第二地址空间为0至ffff,那么可以确定data_base=0x00000000,data_limit=0x0000ffff。
例如受控代码中的load_short指令访问的第三访问地址addr1为0x12345678,addr1并不在第二地址空间0至ffff的范围内,那么本申请的处理模块在执行该load_short指令时,可对data_limit和addr1进行与运算,使得addr的高8位变为0,得到addr2为0x00005678。其中,addr2的地址长度在data_limit限制的长度内。然后,处理模块计算data_base+addr2,得到第四访问地址addr3,这里data_base为0,因此,addr3=addr2,显然addr3在0至ffff的地址范围内(data_base和data_limit限制的第二地址空间)。
需要说明的是,基于第二地址空间在确定第二地址参数时所用的第三预设算法的区别,可使第二地址参数存在差别,那么处理模块在执行第二类指令(例如读内存指令load_short)时,在基于第二地址参数来对第二类指令中的第三访问地址进行计算,来得到在第二地址空间中的第四访问地址时,所用的第四预设算法也可存在区别,并不限制于上述算法。
需要说明的是,本申请对于上述第三预设算法、第四预设算法以及第二地址参数的参数类型均不作限制,可采用传统的任意一种能够实现本申请的限制受控代码的资源访问范围的功能的算法,来作为本申请的算法。
此外,本申请对于受控类指令中所携带的内存访问地址(例如上述第三访问地址)的数量也不做限制,可以是一个或多个第三访问地址,但不论是多少个内存访问地址,处理模块在执行该受控类指令时,均需要基于第二预设算法来对受控类指令所携带的第三访问地址进行计算,来在对该受控类指令所分配的内存的第二地址空间中,确定该最终可访问的第访问地址。
示例性的,例如S301中的第二类指令为load_short指令或store_short指令,那么如图4b所示,受控代码可访问地址空间d6至d7内的受控数据进行读内存或写内存的操作。
本申请实施例的处理模块在接收到受控代码中的第二类指令,例如load_short指令或store_short指令时,可在存储该这两个指令的地址参数的段寄存器,例如寄存器3和寄存器4中读取data_base参数和data_limit参数,以利用这两个参数对oadshort指令或store_short指令所请求访问的地址(即访问地址)进行处理,使得处理后的访问地址限制的第二地址空间,以实现数据资源的有限访问。
示例性的,控制代码可对受控代码中第二类指令中的不同指令,分配不同的第二地址空间,使得受控代码对应的第二地址空间可为多个。
例如对load_short指令分配一组data_base参数1和data_limit参数1,以及对store_short指令分配一组data_base参数2和data_limit参数2,并且data_base参数1和data_limit参数1被处理模块写入寄存器21和寄存器22,data_base参数2和data_limit参数2被处理模块写入寄存器23和寄存器23。
示例性的,以受控类指令中的load_short指令为例,load_short指令可划分为多种load_short指令,例如load_shortN,N=1,2,3…n中的任意一个数值。对于其他受控类指令原理类似,这里不再赘述。
可选地,如上文所述load_short指令可包括CPU的执行方式不同的多种不同编码的load_short指令,那么控制代码可对不同编码的load_short指令分配不同的地址参数(包括data_base参数和data_limit参数),使得不同种load_short指令对应的地址参数的取值不同。进而使得不同种load_short指令可访问的地址空间不同。
可选地,控制代码也可以对一种load_short指令分配多组地址参数(即多组data_base参数和data_limit参数),以使得load_short指令可访问的地址空间是不连续的地址空间。
那么处理模块在接收到受控代码中的load_short指令时,就可以从寄存器21和寄存器22读取data_base参数1和data_limit参数1,以在data_base参数1和data_limit参数1限制的地址空间内执行数据读取。那么处理模块在接收到受控代码中的store_short指令时,就可以从寄存器231和寄存器23读取data_base参数2和data_limit参数2,以在data_base参数2和data_limit参数2限制的地址空间内执行数据写入。
在本申请实施例中,可在受控模块运行之前,例如受控模块中的指令执行之前,由控制模块通过处理模块来对受控模块中的指令进行扫描,在确定受控模块中的指令只包括受控类指令时,则可允许受控代码运行。在受控模块运行在CPU中时,处理模块不需要对受控模块发送的需要执行的每个指令进行查页表等操作,可按照受控类指令,和非受控类指令各自的编码,以不同解释执行方式进行执行。本申请不仅可将对受控代码在运行时的安全判断放到了受控代码运行前,实现了对受控模块的安全检查,同时还可提升受控代码的运行效率,降低硬件的实现和运行成本。
实施例3
可选地,结合于图3a和图3b,图4a和图4b,图5a示例性的示出了本申请的系统的运行流程图,图5b示例性的示出了图5a实施例的内存地址空间的示意图。
图4a和图5a中相同的步骤表示相同的含义,图4b和图5b中相同的图示和箭头也表示相同的含义,本实施例不再一一赘述,可参考图4a和图4b的实施例。
示例性的,非受控代码可包括非受控类指令,可选地也可以包括受控类指令,本申请对此不做限制。非受控代码包括控制代码,那么控制代码可包括非受控类指令,可选地也可以包括非受控类指令,本申请对此不做限制。
在本实施例中,对于允许运行的受控代码仍旧不可以包括非受控指令,只可以包括受控类指令,但是为了能够向受控代码提供非受控代码中的服务(例如获取系统时间的服务),那么本申请实施例可在受控代码的第一地址空间(例如code_base参数和code_limit参数所限定的内存地址空间)中补充代理代码(代理子模块的一种示例),该代理代码可用于跳转至第一地址空间之外的非受控代码中的第一预设地址。例如,受控代码在需要调用非受控代码中的函数(简称“外部函数”)时,可首先跳转到代理代码,然后,再通过代理代码跳转到所需要访问的外部函数,通过二次跳转来实现受控代码对外部函数的调用。
这里在介绍图5a和图5b之前,首先结合图5c对本实施例的受控代码的编译过程进行描述,如上文所述,本申请的编译器,可按照受控类指令,来对程序代码进行编译,使得编译后的指令文件中只包括受控类指令。
如图5c所示,在受控代码编译前,受控代码包括函数0的代码,函数0用于调用非受控代码中的函数1,示例性的,函数1是非受控代码允许受控代码访问的外部函数,那么利用传统的编译器对受控代码编译,则受控代码可包括非受控类的跳转指令。
但是,本申请可采用本申请提供的编译器,来对受控代码进行编译,使得受控代码中的函数0编译为受控类的跳转指令,这里为指令0,该指令0在被处理模块执行时可访问地址1,该地址1可为在内存中,位于编译后的受控代码所处的地址空间(例如图5b所示的地址空间d4至d5)的尾部位置d5之后的地址,例如地址1为图5b中的d51,此时地址d51还未链入有代理代码中的指令,即当前地址d51的内容为空。
下面对代理代码进行简要描述,从指令的角度来看,代理代码是指令序列,代理代码中的各个指令均为非受控类的跳转指令,这些非受控类的跳转指令的跳转目标即为非受控代码中允许受控代码访问的外部函数的地址。那么代理代码可包括:经非受控代码(或者说控制代码)允许,受控代码可访问的外部函数(例如函数1)的非受控类的跳转指令,例如指令1’。
在受控代码编译完成之后,则可将代理代码链入到内存中位于受控代码的尾部的位置,例如图5b所示的代理代码位于地址空间d5至d5’,这样,编译后的受控代码中的上述指令0在被处理模块执行时所访问的地址1处可存储有代理代码中的指令1’,内存的地址空间的存储图可参照图5b。指令1’的跳转目标即为非受控代码中的函数1的首地址,例如图5b中的地址d01。
编译器可配置有代理代码中的非受控类的跳转指令的地址(在对受控代码编译时,该地址还未写入代理代码中的指令),与非受控代码中可访问的预设函数之间的映射关系,例如图5c中的地址1与函数1(也即编译后的指令1’)的映射关系。
以受控代码中所调用的外部函数均为预设函数为例进行说明,在对受控代码进行编译时,编译器可按照上述映射关系,将调用函数1的代码编译为指令0,指令0在被处理模块执行时,可访问地址1。这样,编译后的受控代码在访问外部函数时,可首先访问代理代码中位于地址1处的非受控的跳转指令,例如指令1’。处理模块再通过执行指令1’,来访问非受控模块中函数1的首地址,以实现受控代码对非受控代码中函数1的访问。,需要说明的是,在对受控代码编译时,只需要确定代理代码中相应的非受控跳转指令即将写入至内存的地址,即可实现将受控代码中访问外部函数的代码,编译为受控类的跳转指令的目的。
而在受控代码运行之后,则控制代码对受控代码、代理代码均分配了地址空间,那么受控代码通过指令0就可以找到代理代码中指令1’在内存中的地址,从而通过指令1跳转到外部函数,这里的函数1。
需要说明的是,本申请对于代理代码的编译过程,以及生成过程不做限制,控制代码中已经预先设置有编译后的代理代码。
示例性的,非受控类指令可包括第一预设指令集和第二预设指令集,其中,第一预设指令集内的指令可为部分或全部的非受控类的跳转指令(jump指令)。第二预设指令集内的指令可为部分或全部的非受控类的跳转指令,本申请对此不做限制。
示例性的,第一预设指令集与第二预设指令集可以相同或不同,两个指令集可以存在相同的指令。
示例性的,对于非受控类的跳转指令(即jump指令)也可以分为多种编码的jump指令,不同编码的jump指令虽然在被CPU执行时都可以实现代码资源的访问,但是在对代码资源的访问方式上可存在区别,本申请对此不做限制。那么这里的第一预设指令集和第二预设指令集内的指令则均为jump指令,但是这两个预设指令集之间的jump指令的编码可以存在区别。例如第一预设指令集中的指令为jump1指令至jump5指令。第二预设指令集中的指令为jump6指令至jump10指令。
示例性的,如图5a所示,控制代码可包括代理代码(代理子模块的一种示例),参照上述图5c的介绍可知,代理代码可包括至少一个非受控类的跳转指令(即第二指令),该非受控类的跳转指令在被处理模块执行时,处理模块可访问第二预设代码资源的地址。
示例性的,代理代码中的非受控类的跳转指令,可为第二预设指令集中的jump6指令至jump10指令中的至少一个指令。
第二预设代码资源为位于第四资源访问范围内的代码资源。第四资源访问范围的访问地址,与目标资源访问范围(即上述第一地址空间和第二地址空间)的访问地址不重叠。
示例性的,第二预设代码资源为控制代码,或者非受控代码,允许受控代码访问的位于目标资源访问范围之外的代码资源。
示例性的,第二预设代码资源可以是第二预设函数(例如图5c中非受控代码内的函数1)。第二预设函数可以是一个或多个函数,本申请对此不做限制,那么该第二预设函数可为所述控制模块允许所述受控模块访问的外部函数。
示例性的,可参照图5b,代理代码可包括非受控类指令,具体包括非受控类的跳转指令(即jump指令)。代理代码中的非受控类的跳转指令的访问地址(即跳转地址)为非受控代码中第二预设代码资源的第一预设地址,第一预设地址为控制代码允许受控代码可访问的外部函数的访问地址。
下面结合图5a和图5b进行描述,在受控代码编译完成之后,在受控代码运行在本申请的CPU之前,控制代码可通过处理模块来执行S101、S103-1以及S105。
S101,控制代码通过处理模块扫描受控代码中的指令,来确定受控代码中的指令是否均为受控类指令。
本实施例的S101与实施例2中的图4a中的S101相同,执行原理也相同,这里不再赘述。
可选地,在控制代码检测到受控代码中包括非受控类指令时,则提示错误,以拒绝执行受控代码。
示例性的,在控制代码检测到受控代码中的指令均为受控类指令时,则转至S103-1。
S103-1,控制代码根据受控代码和代理代码各自占用的地址长度之和,对受控代码确定第一地址空间以及第一地址参数;以及,控制代码对受控代码确定第二地址空间以及第二地址参数。
其中,对受控代码中的用于访问数据的第二类指令,确定第二地址空间以及第二地址参数的方法,与实施例2中的S103的相同步骤的执行逻辑类似,这里不再赘述。
示例性的,如图5b所示,第二地址空间为内存中的地址空间d6至d7。
控制代码在对受控代码确定第一地址空间时,与实施例2的区别之处可对比图4b和图5b,在控制代码中不存在代理代码的情况下,对受控代码的访问代码的第一类指令分配的第一地址空间为地址空间d4至d5。在受控代码运行时,受控代码可被写入至地址空间d4至d5,使得受控代码可访问的是自己的代码,例如受控类的跳转指令。
而在本实施例中,如图5b所示,对受控代码中的第一类指令(即受控类的跳转指令)所分配的第一地址空间为地址空间d4至d5’,其中,第一地址空间的地址长度是受控代码所占的地址长度(例如d5-d4),与控制代码中的代理代码所占的地址长度(例如d5’-d5)之和。
那么在S105之后,或者S103-1之后,控制代码可将控制代码内的代理代码链入(例如写入)至地址空间d5至d5’。在受控代码运行时(例如S105之后),控制代码可将受控代码写入地址空间地址空间d4至d5’。这里代理代码位于受控代码的尾部位置,这样受控代码可访问代码的第一地址空间内就不仅包括受控代码,还包括代理代码。
示例性的,控制代码可通过向处理模块发送非受控类指令,来将受控代码以及控制代码中的代理代码,设置写入至地址空间d4至d5’。那么本实施例中,对受控代码中的第一类指令所分配的第一地址空间,不仅可用于存储受控代码,还可用于存储代理代码,使得第一类指令在被处理模块执行而访问代码资源时,不仅可以访问受控代码自身的代码资源,还可访问代理代码的代码资源。
需要说明的是,在图5b中,在内存地址空间中,代理代码位于受控代码的尾部,且存储受控代码的地址空间(d4至d5)与存储代理代码的地址空间(d5至d5’)之间是连续的地址空间,那么第一地址参数是一组,例如一组code_base参数和code_limit参数。
但是,本申请对于第一地址空间中受控代码与代理代码之间的存储顺序不做限制,例如在第一地址空间中,代理代码可以存储在受控代码的头部、尾部以及受控代码内部等位置。此外,存储代理代码的地址空间,与存储受控代码的地址空间之间可以是不连续的,那么第一地址参数可以是多组,例如多组code_base参数和code_limit参数。
那么受控代码中的受控类的跳转指令在进行代码跳转时,不仅可以在受控代码所处的地址空间d4至d5内跳转以访问代码,还可跳转至代理代码所处的地址空间d5至d5’内,以访问代理代码中的非受控类的跳转指令。进而受控代码可通过代理代码中的非受控类的跳转指令,跳转到非受控代码所处的地址空间d0至d3,以调用允许访问的外部函数。
继续参照图5a,在S103-1之后,转至S105,本实施例的S105,与实施例2中图4a中的S105原理相同,这里不再赘述。
在本申请实施例中,在控制代码中包括代理代码时,代理代码可配置有允许受控代码访问的非受控代码中的第二预设函数的非受控类的跳转指令,那么在对受控代码中的第一类指令,例如受控类的跳转指令,分配允许访问的第一地址空间以及第一地址参数时,可将代理代码也写入至受控代码可访问的第一地址空间中。那么控制代码在需要调用非受控代码中的第二预设函数时,可通过首先跳转至代理代码中的非受控类的跳转指令,再通过代理代码跳转至非受控代码中的第二预设函数,以实现对受控代码之外的外部函数的有限访问。
可选地,继续参照图5a和图5b,在S105之后,可选地包括S201、S203、S205以及S207-1。
S201,处理模块接收受控代码的用于访问代码资源的第一类指令。
示例性的,第一类指令包括用于访问代理代码中的所述第二指令(例如jump6指令)的第二跳转类指令。
示例性的,第二类跳转指令为short_jump指令,该指令可携带第一访问地址addr(也即原内存访问地址addr)。
在S201之后,所述处理模块可对所述第二跳转类指令中的原内存访问地址进行处理,并按照处理后的访问地址访问所述第二指令,具体可通过S203和S205来实现:
S203和S205:处理模块可执行该第一类指令,来从第二存储单元读取第一地址参数,然后,基于该第一地址参数和第一访问地址addr,来在第一地址空间中确定第二访问地址,并从代理代码中的第二访问地址处访问代码资源(即第二指令,jump6指令),这里为非受控类的跳转指令。
本实施例的S201、S203以及S205,与实施例2中图4a中的S201、S203以及S205原理相同,这里不再赘述。
S207-1,处理模块按照非受控类的跳转指令的跳转地址,从内存的第三地址空间中调用外部函数。
示例性的,所述处理模块可执行第二指令,从而按照所述第二指令(例如jump6指令)中的访问地址(即跳转地址),访问所述第二预设函数;其中,所述第二预设函数为所述控制模块允许所述受控模块访问的函数。第二预设函数为在第三地址空间中的函数。
其中,处理模块通过第一地址空间中受控代码内的受控类的跳转指令,跳转到第一地址空间中代理代码内的非受控类的跳转指令(位于第二访问地址);然后,处理模块执行该非受控类的跳转指令,该非受控类的跳转指令具有跳转地址,例如第五访问地址,那么处理模块可从第五访问地址处调用第二预设函数。
其中,第五访问地址为第三地址空间中的地址,第三地址空间不同于对受控代码所分配的第一地址空间以及第二地址空间。
示例性的,第三地址空间为非受控代码的存储空间。
示例性的,可结合参照图5b,例如本实施例中S201中的第一类指令为受控代码中的受控类的跳转指令,例如short_jump指令,处理模块通过执行受控代码中的该short_jump指令,可从地址空间d4至d5跳转到代理代码所处的地址空间d5至d5’中的第二访问地址d51。那么处理模块可从第二访问地址d51读取到代理代码中的非受控类的跳转指令,例如jump6指令。那么处理模块可通过执行从第二访问地址d51处读取到的jump6指令,进行代码跳转,跳转到jump6指令对应的跳转地址(即上述第五访问地址),例如jump6指令所调用的外部函数的地址d01,这样,就通过代理代码实现了受控代码对非受控代码中外部函数的访问。
另外,需要说明的是,代理代码中的非受控类的跳转指令只可以跳转到非受控代码中的第二预设函数的地址。
其中,第二预设函数为非受控代码或者控制代码允许受控代码访问的、且属于非受控代码中的指定函数。
可选地,上述第五访问地址可为上述第二预设函数的首地址,这样,可以避免受控代码通过代理代码跳转至非受控代码中指定函数的函数体内部,以防止受控代码在指定函数的函数体内部进行非法操作,例如篡改非受控代码等。
可选地,上述第五访问地址处的代码,可设置有逻辑检查代码。换言之,各个预设函数的首地址处可设置有逻辑检查代码,该逻辑检查代码可对访问该预设函数的请求进行相关检查,在检查通过后,则处理模块可执行预设函数的代码逻辑,以向受控代码提供相关的功能。
那么受控代码在通过代理代码跳转到非受控代码中,由非受控代码指定的各个外部函数的首地址位置后,这些首地址位置上的代码可以在执行外部函数的代码逻辑之前进行检查,根据检查是否通过来确定是否提供再决定是否提供各个外部函数的访问功能。
例如App1调用插件1,插件1在访问App1中的预设函数时,请求获取用户名以及密码信息,那么该预设函数的首地址可设置有检查代码,该检查代码的代码逻辑可为对访问该预设函数的请求进行检查,如果请求所需要获取的信息包括预设信息(可以是敏感信息),例如密码,则检查结果为不通过检查,从而拒绝向插件1提供该预设函数的调用,拒绝方式可包括但不限于报错等;如果请求获取的信息不包括预设信息,则执行该预设函数的代码逻辑,以允许插件1调用该预设函数。
再如,受控代码请求获取系统时间,而调用获取时间函数,在该函数的首地址处设置的逻辑检查代码的检查逻辑为在系统时间在预设时间段的情况下,允许访问该获取时间函数,则非受控代码可通过该逻辑检查代码,而在预设时间段内提供获取系统时间的功能。
可选地,代理代码中可包括控制代码提供的,且允许受控代码访问的全部预设函数的非受控类的跳转指令。
可选地,代理代码中也可以包括控制代码提供的,且允许受控代码访问的第二预设函数的非受控类的跳转指令,其中,第二预设函数可以是控制代码允许受控代码访问的外部函数中的部分或全部预设函数。
需要说明的是,如图5b所示,在本申请实施例中,处理模块通过执行受控代码中受控类的跳转指令,来跳转至代理代码中,以访问代理代码中的非受控类的跳转指令,以通过该非受控类的跳转指令实现外部函数的访问。但是,受控代码中用于访问数据的第二类指令(例如受控类的内存访问指令,load_short指令)所访问的地址空间限制在第二地址空间d6至d7,并不可以访问第一地址空间,从而不可以访问代理代码所处的地址空间d5至d5’,以防止受控代码通过第二类指令来修改代理代码中的代码,从而通过代理代码跳转至非法空间,防止受控代码非法调用未允许的服务。所谓非法空间即为控制代码不允许受控代码所访问的地址空间。
此外,需要说明的是,用于访问代码的第一类指令,可使CPU在内存中取代码;用于访问数据的第二类指令,可使CPU在内存中读写数据。那么控制代码在通过处理模块对受控代码分配地址空间时,对第一类指令分配的第一地址空间不可与对第二类指令分配的第二地址空间存在地址重叠。
另外,需要说明的是,本实施例3中,同样可包括实施例2中所述的S301、S303以及S305,原理类似,这里不再赘述。
在本申请实施例中,控制代码可在通过处理模块扫描受控代码的指令之后,在检测到受控代码中的指令均为受控类指令时,控制代码可通过处理模块在受控代码的第一地址空间中写入代理代码,使得第一地址空间中不仅包括受控代码,还可包括代理代码,那么受控代码就可以通过受控类的跳转指令跳转至代理代码,并通过代理代码中的非受控类的跳转指令,跳转到非受控代码允许受控代码访问的固定函数的位置,例如第二预设函数的首地址。这样受控代码只能进入非受控代码指定的各个函数的首地址位置上,这些位置上的代码可以做合适的检查,再决定是否提供相关的功能,以确保对第二预设函数的访问安全。
实施例4
可选地结合于图3a和图3b,图4a和图4b,图5a和图5b,图6a和图6b示例性的示出了本申请的系统的运行流程图,图6b示例性的示出了图6a实施例的内存地址空间的示意图。
图4a和图6a中相同的步骤表示相同的含义,图4b和图6b中相同的图示和箭头也表示相同的含义,本实施例不再一一赘述,可参考图4a和图4b的实施例。
在本实施例中,为了能够使受控代码可以获得一些非受控代码的服务(比如一个受控的插件执行,需要获得系统的时间),那么只需要确保受控代码中调用外部服务的非受控类指令,所访问的外部函数(即非受控代码中的函数)都是经过控制代码检查确认可以访问的第一预设函数,那么这些非受控类指令可以允许存在于受控代码中,这样,相比于实施例3,本实施例在调用非受控代码中的外部函数时,只需要进行一次跳转,就可以实现受控代码对外部函数的调用。
示例性的,对于非受控类的跳转指令(即jump指令)也可以分为多种编码的jump指令,不同编码的jump指令虽然在被CPU执行时都可以实现代码资源的访问,但是在对代码资源的访问方式上可存在区别,本申请对此不做限制。那么本实施例中允许受控代码包括的非受控类的跳转指令可以是第一预设指令集中的至少一个jump指令。第一预设指令集与实施例3中的第二预设指令集内的指令则均为jump指令,但是这两个预设指令集之间的jump指令的编码可以存在区别。例如第一预设指令集中的指令为jump1指令至jump5指令。第二预设指令集中的指令为jump6指令至jump10指令。当然,在其他实施例中,第一预设指令集与第二预设指令集之间也可以存在相同的非受控类的跳转指令,本申请对此不做限制。
下面介绍本申请实施例的技术方案,控制代码在扫描受控代码时,可结合重定向表来实现对受控代码中非受控类指令的检查:
示例性的,可参照图6a,在受控代码运行在本申请的CPU之前,控制代码可通过处理模块来执行S101、S102、S103-2以及S105。
S101,控制代码通过处理模块扫描受控代码中的指令,来确定受控代码中的指令是否均为受控类指令。
本实施例的S101与实施例2中的图4a中的S101相同,执行原理也相同,这里不再赘述。
可选地,在控制模块检测到受控代码中的指令均为受控类指令时,具体执行逻辑可参照图4a和图5a的实施例,这里不再赘述。
在本实施例中,控制代码通过通过处理模块对受控代码中的指令进行扫描,控制模块可检测到受控代码包括非受控类指令。如上述实施例2提及的,非受控类指令可包括但不限于用于访问代码的第三类指令和用于访问数据的第四类指令。
那么本申请实施例旨在允许受控代码访问非受控代码的指定函数服务,可选地,控制代码在检测到受控代码包括第四类指令,例如load指令时,则提示错误,以拒绝执行受控代码。
可选地,控制代码通过处理模块在检测到受控代码包括非受控类的跳转指令,即与第一预设指令集匹配的第一指令,例如jump1指令至jump5指令中的至少一个指令,则可进一步检测第一指令的跳转目标是否满足预设条件,在受控代码中的每个第一指令的跳转目标均满足预设条件时,则说明所述第一指令为用于访问第一预设代码资源的指令。那么控制代码允许受控代码运行,否则提示出错,拒绝运行。
示例性的,第一预设代码资源为控制代码,或者非受控代码,允许受控代码访问的位于目标资源访问范围之外的代码资源。
第一预设代码资源为位于第一资源访问范围内的代码资源。第一资源访问范围(例如第四地址空间)的访问地址,与目标资源访问范围(即上述第一地址空间和第二地址空间)的访问地址不重叠。
示例性的,第一预设代码资源可以是第一预设函数。第一预设函数可以是一个或多个函数,本申请对此不做限制,那么该第一预设函数可为所述控制模块允许所述受控模块访问的、且不属于第一地址空间和第二地址空间的外部函数。
示例性的,所述第一指令为用于访问所述第一预设函数的第一跳转类指令(例如jump1指令至jump5指令中的至少一个指令);
示例性的,受控代码中每个第一指令均为用于访问第一预设代码资源的指令,则控制代码可确定受控代码中每个第一指令的跳转目标满足预设条件,允许受控代码运行。
示例性的,所述第一预设代码资源包括第一预设函数,其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
例如受控代码中每个jump指令所跳转至的外部函数均为第一预设函数,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。再如受控代码中每个jump指令的跳转地址(例如第四访问地址)均为第二预设地址,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。其中,第二预设地址为控制代码允许受控代码访问的第二预设函数的地址。
示例性的,如图6c所示,当受控代码中包含了对受控代码之外的函数(即上述外部函数)的调用代码,其中,受控代码中的函数0的代码用于调用非受控代码中的函数1,则编译器(可以是传统的编译器)在对受控代码编译后,编译后的文件不仅可包括指令文件(即编译后的受控代码,表现为指令序列,指令序列可包括待执行指令),还可包括重定向表。
示例性的,受控代码中的函数0编译为非受控类的跳转指令,例如指令00,由于在受控代码运行前无法确定所访问的函数1的地址,因此,在指令文件中,指令00的跳转地址为空地址。同样的,编译后的受控代码中每个非受控类的跳转指令的跳转地址均为空地址。
该重定向表可以描述指令文件中需要调用外部函数的非受控类的跳转指令,在指令文件中的位置,以及该非受控类的跳转指令所需要跳转至的外部函数的标识(例如函数名)。并且,重定向表中的这些外部函数用于表示这些外部函数的地址,需要在受控代码运行前确定。示例性的,在指令文件中,这些非受控类的跳转指令的跳转地址均为空地址。
然后,控制代码可以扫描编译后的受控代码,在扫描到受控代码中指令后,在检测到受控代码中的非受控类指令均为非受控类的跳转指令时,可通过查询重定向表,来确定非受控类的跳转指令所需要跳转至的外部函数的标识;然后控制代码可依据该标识来确定这些待访问的外部函数是否都是第一预设函数,来确定是否允许控制代码运行。
其中,如果控制代码中待访问的外部函数均为第一预设函数,则可以允许受控代码运行,否则拒绝受控代码运行,提示出错。
其中,第一预设函数为控制代码(或者说非受控代码)允许受控代码,在非受控代码中可访问的位于第四地址空间的指定函数。
示例性的,在控制代码确定受控代码中待访问的外部函数均为一预设函数后,控制代码可从重定向表中读取调用该外部函数的非受控类的跳转指令在指令文件中的位置,例如图6c中指令00在指令文件中的位置。然后,控制代码按照该位置,将各需要调用的外部函数的地址信息(例如首地址)写入受控代码中相应的非受控类的跳转指令中,来作为各非受控类的跳转指令的跳转地址。例如可将函数1的首地址写入指令文件中指令00以作为指令00的访问地址(即跳转地址)。
需要说明的是,本申请对于控制代码获取各外部函数的地址信息的具体方式不做限制。
S102,控制代码通过处理模块检测到受控代码中的非受控类指令为访问代码资源的非受控类指令,且非受控类指令的跳转目标满足预设条件,则转至执行S103-2。
示例性的,控制代码在通过处理模块检测到受控代码中的每个用于访问代码资源的非受控类指令(例如每个jump指令)的跳转地址(例如第四访问地址)都是第二预设地址内的地址,则可以允许控制代码运行,以执行S103-2。
这里的第四访问地址是控制代码,按照重定向表,对受控代码中的非受控类的跳转指令的跳转地址更新后的地址(即允许访问的外部函数的地址)
或者,示例性的,控制代码在通过处理模块检测到受控代码中的每个用于访问代码资源的非受控类指令(例如jump指令)所需要跳转至的函数均为第一预设函数,则可以允许控制代码运行,以执行S103-2。
S103-2,控制代码通过处理模块对受控代码中的受控类指令,确定第一地址空间和第一地址参数,以及,对受控代码中的第二址空间和第二地址参数。
其中,本步骤的原理与图4a实施例的S103类似,相同之处不再赘述。
示例性的,控制代码可对受控代码中用于访问代码资源的第一类指令,确定第一地址空间,以及确定第一地址空间的第一地址参数。以及控制代码可对受控代码中用于访问数据资源的第二类指令,确定第二地址空间,以及确定第二地址空间的第二地址参数。
示例性的,如图6b所示,控制代码通过处理模块,对受控代码分配的第一地址空间为内存中地址空间d4至d5,第二地址空间为内存中的地址空间d6至d7。
示例性的,虽然控制代码包括非受控类的跳转指令,但是控制代码在对受控代码中的第一类指令分配第一地址空间时,仍旧根据包括非受控类的跳转指令的受控代码所占用的地址长度,来分配地址空间d4至d5。
那么在受控代码运行时,受控代码可被写入至地址空间d4至d5,使得受控代码不仅可访问的内部的受控类指令,还可访问内部的非受控类的跳转指令。
那么在S105之后,在受控代码运行时,控制代码可将受控代码写入至第一地址空间,即地址空间d4至d5’。示例性的,控制代码可通过向处理模块发送非受控类指令,来将受控代码写入至地址空间d4至d5。那么本实施例中,对受控代码中的第一类指令所分配的第一地址空间,不仅可用于存储受控代码中的受控类指令,还可以用于存储受控代码中的非受控类的跳转指令。
那么受控代码中的受控类的跳转指令在进行代码跳转时,如受控代码对应的访问代码的虚线箭头所示,受控代码在受控代码所处的地址空间d4至d5内跳转以访问代码资源时,不仅可以访问受控类指令,还可访问非受控类的跳转指令。进而受控代码可通过受控代码中的非受控类的跳转指令,跳转到非受控代码所处的地址空间d0至d3,以调用允许访问的外部函数。
继续参照图6a,在S103-2之后,转至S105,本实施例的S105,与实施例2中图4a中的S105原理相同,这里不再赘述。
在本申请实施例中,控制代码在扫描受控代码中的指令时,如果检测到非受控类指令,且非受控类指令均为与第一预设指令集匹配的非受控类的跳转指令(即第一指令),并且非受控类的跳转指令(第一指令)的跳转目标满足预设条件,例如受控代码中每个jump指令所跳转至的外部函数均为第一预设函数,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。再如受控代码中每个jump指令的跳转地址均为第二预设地址,则可以确定受控代码中每个第一指令的跳转目标满足预设条件。其中,第一预设地址为控制代码允许受控代码访问的第一预设函数的地址。那么在受控代码中非受控类指令只包括非受控类的跳转指令,且非受控类的跳转指令的跳转目标满足预设条件,则控制代码可以允许受控代码运行。本实施例中受控代码在访问外部函数时,只需要进行一次外部跳转,不需要通过代理代码进行二次跳转,受控代码的执行速度更快。只是控制代码在扫描受控代码时,扫描步骤相对实施例3更复杂,需要检查受控代码中的每个非受控类指令的跳转目标是否满足预设条件。
示例性的,控制代码在扫描受控代码中的指令时,如果检查到受控代码中不仅包括受控类指令,还包括能够跳转到非受控代码的非受控类的跳转指令,则控制代码可以对非受控类的跳转指令的跳转目标进行检查。如果控制代码检测到跳转目标与非受控代码允许受控代码访问的第一预设函数相匹配的,那么虽然受控代码中包括跳转至非受控代码的非受控类的跳转指令,但是非受控类的跳转指令只可以跳转到指定的外部函数的位置,则受控代码也是安全的,那么控制代码可允许受控代码运行。该方案可确保受控代码中所使用的非受控类指令的跳转目标都是经过检查的。
示例性的,控制代码在扫描到受控代码中的非受控类的跳转指令后,可查询重定向表确定每一个非受控类的跳转指令所需要跳转至的外部函数,如果这些外部函数都是调用受控代码的非受控代码允许,该受控代码跳转的第一预设函数。那么控制代码可以利用重定向表,在受控代码中找到非受控类的跳转指令的位置,在相应位置写入相应外部函数的地址(例如起始地址)。
可选地,实施例3和实施例4可作为并列的实施例则以执行,实施例3和实施例4也可以结合来同时实现。
示例性的,实施例4的第一预设代码资源与实施例3的第二预设代码资源可以相同。
那么受控代码可通过代理代码的方式(即实施例3的方式),或,在受控代码内包括访问第一预设代码资源的非受控类的跳转指令的方式(即实施例4的方式),来实现对外部代码资源的访问,本申请对此不做限制。
可选地,实施例3和实施例4的第一预设代码资源与第二预设代码资源可以不同。
那么受控代码可通过代理代码的方式(即实施例3的方式),和,在受控代码内包括访问第一预设代码资源的非受控类的跳转指令的方式(即实施例4的方式),来实现对外部代码资源的访问,本申请对此不做限制。
同理,第一预设函数与第二预设函数可以相同或不同,第一指令与第二指令也可以相同或不同。
可选地,继续参照图6a和图6b,在S105之后,非受控代码可调用受控代码,以使受控代码运行在CPU中,该方法可选地包括S201、S203、S205以及S207-2。
S201,处理模块接收受控代码发送的用于访问代码资源的第一类指令。
示例性的,第一类指令为short_jump指令,该指令可携带第一访问地址addr。
S203和S205:处理模块可执行该第一类指令,来从第二存储单元读取第一地址参数,然后,基于该第一地址参数和第一访问地址,来在第一地址空间中确定第二访问地址,并从第二访问地址处访问非受控类的跳转指令。这里与实施例3的区别之处在于,第二访问地址位于受控代码内部,并非代理代码内部,从而受控代码中的指令只需要完成一次外部跳转,就可以实现外部函数的调用。
本实施例的S201、S203以及S205,与实施例2中图4a中的S201、S203以及S205原理相同,这里不再赘述。
S207-2,处理模块按照非受控类的跳转指令的跳转地址,从内存的第四地址空间中调用外部函数。
其中,处理模块通过第一地址空间中受控代码内的受控类的跳转指令,跳转到第一地址空间中受控代码内的非受控类的跳转指令(位于第二访问地址),该跳转过程属于一次内部跳转;然后,处理模块执行该非受控类的跳转指令,该非受控类的跳转指令具有跳转地址,例如第六访问地址,那么处理模块可从第六访问地址处调用第一预设函数。
其中,第六访问地址为第四地址空间中的地址,第四地址空间不同于对受控代码所分配的第一地址空间以及第二地址空间。
示例性的,第四地址空间为非受控代码的存储空间。
示例性的,可结合参照图6b,例如本实施例中S201中的第一类指令为受控代码中的受控类的跳转指令,例如short_jump指令,处理模块通过执行受控代码中的该short_jump指令,可从地址空间d4至d5内进行受控代码的内部跳转,例如跳转到地址空间d4至d41中的非受控类的跳转指令。那么处理模块可执行地址空间d4至d41中的非受控类的跳转指令(例如jump1指令)进行代码跳转,跳转到jump1指令对应的跳转地址(即上述第六访问地址),即非受控代码中的第一预设函数的地址,这样,就通过受控代码内部的非受控类的跳转指令,实现了受控代码对非受控代码中外部函数的访问。
另外,需要说明的是,受控代码中的非受控类的跳转指令只可以跳转到非受控代码中的第一预设函数的地址。
其中,第一预设函数的限制可参考实施例3中的相关描述,以及第六访问地址与实施例3中的第五访问地址同理,相关描述同样可参考实施例3,这里不再一一赘述。
另外,需要说明的是,本实施例4中,同样可包括实施例2中所述的S301、S303以及S305,原理类似,这里不再赘述。
本实施例中受控代码在访问外部函数时,只需要进行一次外部跳转,不需要通过代理代码进行二次外部跳转,CPU对受控代码的执行速度更快。
实施例5
图7为示例性示出的本申请的中央处理器(CPU)的架构图,可对比于传统技术中的图2c来看本申请提供的图7所示的中央处理器的架构图。
本申请的CPU可包括运行在CPU中的任意程序实体,程序实体的可包括但不限于:一般用户程序代码、操作系统代码、虚拟机管理代码等。
该程序实体可包括安全区代码(即非受控代码)和非安全区代码(即受控代码),这里的非安全区代码包括非安全区代码1和非安全区代码2。
以程序实体为一般用户程序代码为例,一般用户程序(例如应用1)的代码在运行在进程中,在进程1中运行的应用1的代码为安全区代码,应用1需要调用动态库以及插件(调用动态库和插件的先后顺序不做限制),那么非安全区代码1可为这里的动态库,非安全区代码2可为这里的插件。
但是,应用1无法判断该动态库以及插件中的代码是否越权访问应用1的资源(例如内存资源),则可在应用1内部内嵌本申请提供的控制代码。
这样,在应用1调用动态库或插件之前,运行在CPU中的控制代码可通过向处理模块发送非受控类指令,来对动态库中的代码进行扫描,以确定动态库中只有受控类指令;同理,对插件中的代码进行扫描,以确定插件中只有受控类指令。
进一步的,控制代码还可为动态库分配可访问的资源的地址空间,以及为插件分配可访问的资源的地址空间,但如果我们控制这个动态库只能使用受控指令,那么这个动态库可以访问的内容就是有限的。
然后,安全区代码(例如这里的进程1)就可以调用非安全区代码1或非安全区代码2,以在应用1中嵌入非安全区代码1或非安全区代码2。那么非安全区代码1或非安全区代码2运行在CPU中,可向CPU中的处理模块发送受控类指令,以在有限的资源访问空间内进行资源的访问。这样,应用1可使用受控代码(即非安全区代码)提供的服务,但同时又确保了非安全区代码对应用1的资源的安全访问。
从图7以及上述描述可以看到,在确保非安全区代码(即受控代码)的资源安全访问时,本申请不需要对该非安全区代码单独创建角色实例,例如进程、容器、虚拟机等。也不需要将程序中的安全区代码(即非受控代码)与所调用的非安全区代码(即受控代码)进行分离,以将非安全区代码隔离在进程、容器、虚拟机等。也就是说,安全区代码和非安全区代码处于同一程序实体内,安全区代码与非安全区代码之间没有进行任何隔离,本申请在非安全区代码运行在CPU之前,通过控制代码扫描非安全区代码中的指令,实现了非安全区代码对安全区代码的资源范围的有限访问。这样,在任意一个实体中,就可以隔离不同代码的资源访问权限,这样CPU无需为待隔离的非安全区代码单独再创建进程、虚拟机等角色实例,降低了CPU的信令开销。
示例性的,本申请的上述方案可应用于Serverless(Serverless computing无服务器运算)场景。所谓Serverless,是一种云计算的场景,在这种场景中,用户可提供一个函数用于快速完成一个功能。
其中,用户不在云服务商上申请一台服务器,来持续运行该用户提供的某个服务。用户仅提供一个函数,该函数静态地存储在云服务商的某个存储上。其他的服务(比如Web前端)请求调用该函数,才会启动该函数,完成相关的计算。为了保证这个函数的计算过程是安全,通常需要为这个函数准备一个进程、容器甚至虚拟机,来运行该函数,以避免该函数访问超出该函数的权限范围的资源。
但是,在本申请中,控制模块只要检查到该函数只包含受控类指令,那么该函数在运行过程中就无法访问超出其权限范围的资源。此外,该函数的计算过程可以在调用该函数的服务(例如上述Web前端)中完成,也可以在一个用于聚合的其他进程、容器或虚拟机中完成。只需要在运行该函数的空间中分配了该函数可用的有限资源,该函数就可以完成相关计算,而无需为了运行该函数再额外创建资源(例如进程、容器、虚拟机等)。其中,创建进程、容器、虚拟机等角色实例的成本较高。
在一种可能的实施方式中,本申请实施例提供一种资源控制装置。资源控制装置包括控制模块和受控模块,资源控制装置中的指令被划分为受控类指令和非受控类指令,控制模块用于:在受控模块运行之前,对受控模块内的指令进行扫描,检测资源控制装置受控模块内的指令是否均为受控类指令;在检测到受控模块内的指令均为受控类指令时,对受控模块内的每个指令分配目标资源访问范围。该资源控制装置的结构和功能可参照图3a及其相关方法实施例的描述,这里不再赘述。
在一种可能的实施方式中,资源控制装置还包括处理模块;处理模块,用于对第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源;其中,第一访问地址为受控模块内当前运行的受控类指令中的资源访问地址;其中,处理后的第一访问地址,在当前运行的受控类指令对应的目标资源访问范围内。
在一种可能的实施方式中,控制模块,还用于在检测到受控模块内的指令不均为受控类指令之后,在检测到受控模块包括与第一预设指令集匹配的第一指令、且第一指令为用于访问第一预设代码资源的指令时,对受控模块内的每个受控类指令,分配目标资源访问范围;其中,非受控类指令包括第一预设指令集;第一预设代码资源位于第一资源访问范围,且第一资源访问范围与目标资源访问范围不同。
在一种可能的实施方式中,第一预设代码资源包括第一预设函数,第一指令为用于访问第一预设函数的第一跳转类指令;其中,第一预设函数为控制模块允许受控模块访问的函数。
在一种可能的实施方式中,受控模块内的受控类指令包括:用于访问代码资源的第一类指令和用于访问数据资源的第二类指令;控制模块,具体用于:对第一类指令分配第二资源访问范围;对第二类指令分配第三资源访问范围;其中,第二资源访问范围和第三资源访问范围之间的资源访问地址不同。
在一种可能的实施方式中,非受控类指令包括第二预设指令集,控制模块包括代理子模块,代理子模块包括与第二预设指令集匹配的第二指令;其中,第二指令为用于访问第二预设代码资源的指令,第二预设代码资源位于第四资源访问范围内,且第四资源访问范围与目标资源访问范围之间的资源访问地址不同;控制模块,还用于将代理子模块写入至第二资源访问范围。
在一种可能的实施方式中,第二预设代码资源包括第二预设函数,第一类指令包括用于访问第二指令的第二跳转类指令;处理模块,具体用于:对第二跳转类指令中的第二访问地址进行处理,并按照处理后的第二访问地址访问第二指令;按照第二指令中的第三访问地址,访问第二预设函数;其中,第二预设函数为控制模块允许受控模块访问的函数。
上述各实施方式的资源控制装置的效果和实现方式,与上述各实施方式的方法的效果类似,这里不再赘述。
下面介绍本申请实施例提供的一种装置。如图8所示:
图8为本申请实施例提供的一种资源控制装置的结构示意图。如图8所示,该资源控制装置500可包括:处理器501、收发器505,可选的还包括存储器502。
所述收发器505可以称为收发单元、收发机、或收发电路等,用于实现收发功能。收发器505可以包括接收器和发送器,接收器可以称为接收机或接收电路等,用于实现接收功能;发送器可以称为发送机或发送电路等,用于实现发送功能。
存储器502中可存储计算机程序或软件代码或指令504,该计算机程序或软件代码或指令504还可称为固件。处理器501可通过运行其中的计算机程序或软件代码或指令503,或通过调用存储器502中存储的计算机程序或软件代码或指令504,对MAC层和PHY层进行控制,以实现本申请各实施例提供的资源控制方法。其中,处理器501可以为中央处理器(central processing unit,CPU),存储器502例如可以为只读存储器(read-only memory,ROM),或为随机存取存储器(random access memory,RAM)。
本申请中描述的处理器501和收发器505可实现在集成电路(integratedcircuit,IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(applicationspecific integrated circuit,ASIC)、印刷电路板(printed circuit board,PCB)、电子设备等上。
上述资源控制装置500还可以包括天线506,该资源控制装置500所包括的各模块仅为示例说明,本申请不对此进行限制。
本申请中描述的资源控制装置的范围并不限于此,而且资源控制装置的结构可以不受图8的限制。资源控制装置可以是独立的设备或者可以是较大设备的一部分。例如所述资源控制装置的实现形式可以是:
(1)独立的集成电路IC,或芯片,或,芯片系统或子系统;(2)具有一个或多个IC的集合,可选的,该IC集合也可以包括用于存储数据,指令的存储部件;(3)可嵌入在其他设备内的模块;(4)电子设备等等;(5)其他等等。
对于资源控制装置的实现形式是芯片或芯片系统的情况,可参见图9所示的芯片的结构示意图。图9所示的芯片包括处理器601和接口602。其中,处理器601的数量可以是一个或多个,接口602的数量可以是多个。可选的,该芯片或芯片系统可以包括存储器603。
其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到资源控制装置的对应功能模块的功能描述,在此不再赘述。
基于相同的技术构思,本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质存储有计算机程序,该计算机程序包含至少一段代码,该至少一段代码可由计算机或处理器执行,以控制计算机或处理器用以实现上述方法实施例。
基于相同的技术构思,本申请实施例还提供一种计算机程序产品包括软件程序,当所述软件程序被计算机或处理器执行时,用以实现上述方法实施例。
所述程序可以全部或者部分存储在与处理器封装在一起的存储介质上,也可以部分或者全部存储在不与处理器封装在一起的存储器上。
基于相同的技术构思,本申请实施例还提供一种资源控制装置,包括一个或多个接口电路和一个或多个处理器;所述接口电路用于从存储器接收信号,并向所述处理器发送所述信号,所述信号包括存储器中存储的计算机指令;当所述处理器执行所述计算机指令时,所述处理器用于实现上述方法实施例。
结合本申请实施例公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于随机存取存储器(Random Access Memory,RAM)、闪存、只读存储器(Read Only Memory,ROM)、可擦除可编程只读存储器(Erasable Programmable ROM,EPROM)、电可擦可编程只读存储器(Electrically EPROM,EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
上面结合附图对本申请的实施例进行了描述,但是本申请并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本申请的启示下,在不脱离本申请宗旨和权利要求所保护的范围情况下,还可做出很多形式,均属于本申请的保护之内。

Claims (17)

1.一种资源控制方法,其特征在于,应用于资源控制装置,所述资源控制装置包括控制模块和受控模块,所述资源控制装置中的指令被划分为受控类指令和非受控类指令,所述方法包括:
在所述受控模块运行之前,所述控制模块对所述受控模块内的指令进行扫描,检测所述受控模块内的指令是否均为受控类指令;
在所述控制模块检测到所述受控模块内的指令均为所述受控类指令时,所述控制模块对所述受控模块内的每个指令分配目标资源访问范围。
2.根据权利要求1所述的方法,其特征在于,所述资源控制装置还包括处理模块,所述控制模块对所述受控模块内的每个指令分配目标资源访问范围之后,所述方法还包括:
所述处理模块对第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源;
其中,所述第一访问地址为所述受控模块内当前运行的受控类指令中的资源访问地址;
其中,所述处理后的第一访问地址,在所述当前运行的受控类指令对应的所述目标资源访问范围内。
3.根据权利要求1或2所述的方法,其特征在于,在所述控制模块检测到所述受控模块内的指令不均为所述受控类指令之后,所述方法还包括:
在所述控制模块检测到所述受控模块包括与第一预设指令集匹配的第一指令、且所述第一指令为用于访问第一预设代码资源的指令时,所述控制模块对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围;
其中,所述非受控类指令包括所述第一预设指令集;
所述第一预设代码资源位于第一资源访问范围,且所述第一资源访问范围与所述目标资源访问范围不同。
4.根据权利要求3所述的方法,其特征在于,所述第一预设代码资源包括第一预设函数,所述第一指令为用于访问所述第一预设函数的第一跳转类指令;
其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
5.根据权利要求1至4中任意一项所述的方法,其特征在于,所述受控模块内的所述受控类指令包括用于访问代码资源的第一类指令和用于访问数据资源的第二类指令,所述控制模块对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围,包括:
所述控制模块对所述第一类指令分配第二资源访问范围;
所述控制模块对所述第二类指令分配第三资源访问范围;
其中,所述第二资源访问范围和所述第三资源访问范围之间的资源访问地址不同。
6.根据权利要求1至5中任意一项所述的方法,其特征在于,所述非受控类指令包括第二预设指令集,所述控制模块包括代理子模块,所述代理子模块包括与所述第二预设指令集匹配的第二指令,其中,所述第二指令为用于访问第二预设代码资源的指令,所述第二预设代码资源位于第四资源访问范围内,且所述第四资源访问范围与所述目标资源访问范围之间的资源访问地址不同;
所述控制模块对所述受控模块内的每个指令分配目标资源访问范围之后,所述方法还包括:
所述控制模块将所述代理子模块写入至所述第二资源访问范围。
7.根据权利要求6所述的方法,其特征在于,所述第二预设代码资源包括第二预设函数,所述第一类指令包括用于访问所述第二指令的第二跳转类指令;
所述处理模块对所述第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源,包括:
所述处理模块对所述第二跳转类指令中的第二访问地址进行处理,并按照处理后的第二访问地址访问所述第二指令;
所述处理模块按照所述第二指令中的第三访问地址,访问所述第二预设函数;
其中,所述第二预设函数为所述控制模块允许所述受控模块访问的函数。
8.一种资源控制装置,其特征在于,所述资源控制装置包括控制模块和受控模块,所述资源控制装置中的指令被划分为受控类指令和非受控类指令;所述控制模块用于:
在所述受控模块运行之前,对所述受控模块内的指令进行扫描,检测所述受控模块内的指令是否均为受控类指令;
在检测到所述受控模块内的指令均为所述受控类指令时,对所述受控模块内的每个指令分配目标资源访问范围。
9.根据权利要求8所述的装置,其特征在于,所述资源控制装置还包括处理模块;
所述处理模块,用于对第一访问地址进行处理,并按照处理后的第一访问地址访问目标资源;
其中,所述第一访问地址为所述受控模块内当前运行的受控类指令中的资源访问地址;
其中,所述处理后的第一访问地址,在所述当前运行的受控类指令对应的所述目标资源访问范围内。
10.根据权利要求8或9所述的装置,其特征在于,
所述控制模块,还用于在检测到所述受控模块内的指令不均为所述受控类指令之后,在检测到所述受控模块包括与第一预设指令集匹配的第一指令、且所述第一指令为用于访问第一预设代码资源的指令时,对所述受控模块内的每个所述受控类指令,分配所述目标资源访问范围;
其中,所述非受控类指令包括所述第一预设指令集;
所述第一预设代码资源位于第一资源访问范围,且所述第一资源访问范围与所述目标资源访问范围不同。
11.根据权利要求10所述的装置,其特征在于,所述第一预设代码资源包括第一预设函数,所述第一指令为用于访问所述第一预设函数的第一跳转类指令;
其中,所述第一预设函数为所述控制模块允许所述受控模块访问的函数。
12.根据权利要求8至11中任意一项所述的装置,其特征在于,所述受控模块内的所述受控类指令包括:用于访问代码资源的第一类指令和用于访问数据资源的第二类指令;
所述控制模块,具体用于:
对所述第一类指令分配第二资源访问范围;
对所述第二类指令分配第三资源访问范围;
其中,所述第二资源访问范围和所述第三资源访问范围之间的资源访问地址不同。
13.根据权利要求8至12中任意一项所述的装置,其特征在于,所述非受控类指令包括第二预设指令集,所述控制模块包括代理子模块,所述代理子模块包括与所述第二预设指令集匹配的第二指令;
其中,所述第二指令为用于访问第二预设代码资源的指令,所述第二预设代码资源位于第四资源访问范围内,且所述第四资源访问范围与所述目标资源访问范围之间的资源访问地址不同;
所述控制模块,还用于将所述代理子模块写入至所述第二资源访问范围。
14.根据权利要求13所述的装置,其特征在于,所述第二预设代码资源包括第二预设函数,所述第一类指令包括用于访问所述第二指令的第二跳转类指令;
所述处理模块,具体用于:
对所述第二跳转类指令中的第二访问地址进行处理,并按照处理后的第二访问地址访问所述第二指令;
按照所述第二指令中的第三访问地址,访问所述第二预设函数;
其中,所述第二预设函数为所述控制模块允许所述受控模块访问的函数。
15.一种计算机可读存储介质,其特征在于,包括计算机程序,当所述计算机程序运行在计算机或处理器上时,使得所述计算机或所述处理器执行如权利要求1至7中任意一项所述的方法。
16.一种资源控制装置,其特征在于,包括一个或多个接口电路和一个或多个处理器;所述接口电路用于从存储器接收信号,并向所述处理器发送所述信号,所述信号包括存储器中存储的计算机指令;当所述处理器执行所述计算机指令时,所述处理器用于执行如权利要求1至7中任意一项所述的方法。
17.一种计算机程序产品,其特征在于,所述计算机程序产品包括软件程序,当所述软件程序被计算机或处理器执行时,使得权利要求1至7任一项所述的方法的步骤被执行。
CN202210262411.2A 2022-03-17 2022-03-17 资源控制方法及装置 Pending CN116795525A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210262411.2A CN116795525A (zh) 2022-03-17 2022-03-17 资源控制方法及装置
PCT/CN2023/071405 WO2023173915A1 (zh) 2022-03-17 2023-01-09 资源控制方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210262411.2A CN116795525A (zh) 2022-03-17 2022-03-17 资源控制方法及装置

Publications (1)

Publication Number Publication Date
CN116795525A true CN116795525A (zh) 2023-09-22

Family

ID=88022171

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210262411.2A Pending CN116795525A (zh) 2022-03-17 2022-03-17 资源控制方法及装置

Country Status (2)

Country Link
CN (1) CN116795525A (zh)
WO (1) WO2023173915A1 (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138238A (en) * 1997-12-11 2000-10-24 Sun Microsystems, Inc. Stack-based access control using code and executor identifiers
US7162743B1 (en) * 2001-10-04 2007-01-09 Hewlett-Packard Development Company, L.P. System and method of limiting access to protected hardware addresses and processor instructions
US7380276B2 (en) * 2004-05-20 2008-05-27 Intel Corporation Processor extensions and software verification to support type-safe language environments running with untrusted code
US20140041026A1 (en) * 2012-08-01 2014-02-06 SIFTEO, Inc. Hybrid Virtual Machine
CN109840410B (zh) * 2017-12-28 2021-09-21 中国科学院计算技术研究所 一种进程内数据隔离与保护的方法和系统
CN113886288A (zh) * 2021-09-29 2022-01-04 南方科技大学 基于arm架构的资源访问控制方法、系统、设备及存储介质

Also Published As

Publication number Publication date
WO2023173915A1 (zh) 2023-09-21

Similar Documents

Publication Publication Date Title
US10114958B2 (en) Protected regions
US10198578B2 (en) Secure privilege level execution and access protection
CN111651778B (zh) 基于risc-v指令架构的物理内存隔离方法
US7673109B2 (en) Restricting type access to high-trust components
US8429741B2 (en) Altered token sandboxing
US5832483A (en) Distributed control interface for managing the interoperability and concurrency of agents and resources in a real-time environment
US7926086B1 (en) Access control mechanism for shareable interface communication access control
US8327415B2 (en) Enabling byte-code based image isolation
US20070055837A1 (en) Memory protection within a virtual partition
US20050108516A1 (en) By-pass and tampering protection for application wrappers
US7647629B2 (en) Hosted code runtime protection
JP2000200192A (ja) 予期しないプラットフォ―ム・バリアント上の装置をコア・プラットフォ―ム・カ―ネル・ソフトウエアの再リリ―スなしにサポ―トする機構
CN112446032A (zh) 可信执行环境构建方法、系统及存储介质
US10628611B2 (en) Exclusive execution environment within a system-on-a-chip computing system
CN117693737A (zh) 为容器实例设立子目录和网络接口的过程的保护
US20230161484A1 (en) Dynamic management of a memory firewall
CN116795525A (zh) 资源控制方法及装置
Stilkerich et al. Memory protection at option
CN111666579A (zh) 计算机设备及其访问控制方法和计算机可读介质
WO2024082232A1 (zh) 一种内存访问控制方法和装置
CN118069337A (zh) 一种内存访问方法及相关设备
JP4638505B2 (ja) 電子デバイス内の安全なプログラム解釈方法
Zeng et al. Refinement-based Modeling and Formal Verification for Multiple Secure Partitions of TrustZone.
CN117349853A (zh) 用于管理存储区域的访问权限的方法和对应的片上系统
CN117313127A (zh) 数据访问权限控制方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication