Re: [PATCH v2] Fix fTPM on AMD Zen+ CPUs
> Eessentially what you want to do is to detach and backup the original > NVS resources and put them back to the list with insert_resource() when > tpm_crb is removed. At least I think this is what should be done but you > should CC your patch also to the ACPI list for feedback. > > /Jarkko Yes, you are right. But, what I really want to do is requesting command/response buffer regions from NVS driver and releasing them. To detach and backup the original NVS resources with insert_resource() or remove_resource() are not needed maybe. I have some idea about it, so I have sent an email to you. Would you check the email and give comments? The link is here, https://lkml.org/lkml/2019/9/16/112 . Seunghun
Re: [PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
Sorry for my mistake. I misunderstood some functions in nvs.c. So I have fixed it and sent my email again. My email is below. > > > Matthew pointed out that having a hook in NVS driver is better solution > > > because it is nil functionality if the TPM driver is loaded. We need > > > functions to: > > > > > > 1. Request a region from the NVS driver (when tpm_crb loads) > > > 2. Release a region back to the NVS Driver (when tpm_crb unloads). > > > > > > My proposal would unnecessarily duplicate code and also leave a > > > side-effect when TPM is not used in the first place. > > > > > > I see this as the overally best solution. If you can come up with a > > > patch for the NVS side and changes to CRB drivers to utilize the new > > > hooks, then combined with Vanya's changes we have a sustainable solution > > > for AMD fTPM. > > > > It's a great solution. I will update this patch on your advice and > > send it to you soon. > > > > By the way, I have a question about your advice. > > If we handle the NVS region with NVS driver, calling devm_ioremap() > > function is fine like crb_ioremap_resource() function in this patch? > > No, you should reclaim the resource that conflicts and return it back > when tpm_crb is unregistered (e.g. rmmod tpm_crb). > > I would try something like enumerating iomem resources with > walk_iomem_res_desc(). I would advice to peek at arch/x86/kernel/crash.c > for an example how to use this for NVS regions > > Then you could __release_region() to unallocate the source. When tpm_crb > is removed you can then allocate and insert a resource with data > matching it had. Thank you for your sincere advice, and I have some questions about it. As you know, the core reason of this ACPI NVS problem is that a busy bit is set to the ACPI NVS area. So, devm_ioremap_resource() function fails because of it. If we want to call devm_ioremap_resource() for this case, we maybe need to rearrange the existing memory layout from the child relationship to the sibling relationship below. We also need to get back when tpm_crb unloads. [ ACPI NVS (parent) [ TPM CMD buffer (child of NVS) ] [ TPM RSP buffer (child of NVS) ] ] <---> [ ACPI NVS head ] [ CMD buffer ] [ NVS middle ] [ RSP buffer ] [ NVS tails ] Our concern is a race condition between NVS driver and TPM CRB driver. In my view, we could solve this problem if we only make and call the functions you said, requesting and releasing a region from NVS driver. NVS driver doesn't rely on iomem layout, and it relies on internal nvs_region_list data. Therefore, I added some details to your guide. How about this sequence? 1) When tpm_crb driver loads, the driver checks if command/response buffers are in ACPI NVS area. If so, it requests (or removes) the buffer regions from NVS driver's nvs_region_list (with acpi_nvs_unregister() function I will add to the nvs.c driver). 2) If command/response buffers are in ACPI NVS area, tpm_crb driver calls devm_ioremap() instead of devm_ioremap_resource() like this patch. 3) When tpm_crb driver unloads, the driver releases (or adds) the buffer regions to NVS driver's nvs_region_list (with existing acpi_nvs_register() function in the nvs.c driver). I think the sequence could solve the problem we concerned. What do you think about the sequence? Seunghun
Re: [PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > > Matthew pointed out that having a hook in NVS driver is better solution > > > because it is nil functionality if the TPM driver is loaded. We need > > > functions to: > > > > > > 1. Request a region from the NVS driver (when tpm_crb loads) > > > 2. Release a region back to the NVS Driver (when tpm_crb unloads). > > > > > > My proposal would unnecessarily duplicate code and also leave a > > > side-effect when TPM is not used in the first place. > > > > > > I see this as the overally best solution. If you can come up with a > > > patch for the NVS side and changes to CRB drivers to utilize the new > > > hooks, then combined with Vanya's changes we have a sustainable solution > > > for AMD fTPM. > > > > It's a great solution. I will update this patch on your advice and > > send it to you soon. > > > > By the way, I have a question about your advice. > > If we handle the NVS region with NVS driver, calling devm_ioremap() > > function is fine like crb_ioremap_resource() function in this patch? > > No, you should reclaim the resource that conflicts and return it back > when tpm_crb is unregistered (e.g. rmmod tpm_crb). > > I would try something like enumerating iomem resources with > walk_iomem_res_desc(). I would advice to peek at arch/x86/kernel/crash.c > for an example how to use this for NVS regions > > Then you could __release_region() to unallocate the source. When tpm_crb > is removed you can then allocate and insert a resource with data > matching it had. Thank you for your sincere advice, and I have some questions about it. As you know, the core reason of this ACPI NVS problem is that a busy bit is set to the ACPI NVS area. So, devm_ioremap_resource() function fails because of it. If we want to call devm_ioremap_resource() for this case, we maybe need to rearrange the existing memory layout from the child relationship to the sibling relationship below. We also need to get back when tpm_crb unloads. [ ACPI NVS (parent) [ TPM CMD buffer (child of NVS) ] [ TPM RSP buffer (child of NVS) ] ] <---> [ ACPI NVS head ] [ CMD buffer ] [ NVS middle ] [ RSP buffer ] [ NVS tails ] Our concern is a race condition between NVS driver and TPM CRB driver. In my view, we could solve this problem if we only make and call the functions you said, requesting and releasing a region from NVS driver. NVS driver doesn't rely on iomem layout, and it relies on internal nvs_list data. Therefore, I added some details to your guide. How about this sequence? 1) When tpm_crb driver loads, the driver checks if command/response buffers are in ACPI NVS area. If so, it requests (or removes) the buffer regions from NVS driver's nvs_list (with suspend_nvs_unregister() function I will add to the nvs.c driver). 2) If command/response buffers are in ACPI NVS area, tpm_crb driver calls devm_ioremap() instead of devm_ioremap_resource() like this patch. 3) When tpm_crb driver unloads, the driver releases (or adds) the buffer regions to NVS driver's nvs_list (with existing suspend_nvs_register() function in the nvs.c driver). I think the sequence could solve the problem we concerned. What do you think about the sequence? Seunghun
Re: [PATCH v2] Fix fTPM on AMD Zen+ CPUs
> > On Fri, Sep 13, 2019 at 03:00:06PM +0100, Jarkko Sakkinen wrote: > > On Wed, Sep 11, 2019 at 02:17:48PM +0900, Seunghun Han wrote: > > > Vanya, > > > I also made a patch series to solve AMD's fTPM. My patch link is here, > > > https://lkml.org/lkml/2019/9/9/132 . > > > > > > The maintainer, Jarkko, wanted me to remark on your patch, so I would > > > like to cooperate with you. > > > > > > Your patch is good for me. If you are fine, I would like to take your > > > patch and merge it with my patch series. I also would like to change > > > some points Jason mentioned before. > > > > I rather handle the review processes separately because I can merge > > Vanyas's patch first. Bundling them into patch set would only slow > > down things. > > I did not ask to do anything. I just review code changes. I got it. I should concentrate on my ACPI NVS problem. Thank you. Seunghun
Re: [PATCH v2] Fix fTPM on AMD Zen+ CPUs
> > And why is this allocating memory inside the acpi table walker? It > > seems to me like the memory should be allocated once the mapping is > > made. > > > > Yes, this looks bad. Letting the walker build the list and then using > it is, probably, a better idea. > > > Maybe all the mappings should be created from the ACPI ranges right > > away? > > > > I don't know if it's a good idea to just map them all instead of doing > so only for relevant ones. Maybe it is safe, here I need an advice > from a more knowledgeable person. > Vanya, I also made a patch series to solve AMD's fTPM. My patch link is here, https://lkml.org/lkml/2019/9/9/132 . The maintainer, Jarkko, wanted me to remark on your patch, so I would like to cooperate with you. Your patch is good for me. If you are fine, I would like to take your patch and merge it with my patch series. I also would like to change some points Jason mentioned before. Of course, I will leave your commit message and sign-off-by note. According to the guideline below, I will just add co-developed-by and sign-off-by notes behind you. https://www.kernel.org/doc/html/v5.2/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by If you have any idea about our co-work, please let me know. I hope we can solve AMD's fTPM problem soon. Seunghun
Re: [PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > On Tue, Sep 10, 2019 at 03:42:15PM +0100, Jarkko Sakkinen wrote: > > On Mon, Sep 09, 2019 at 06:09:06PM +0900, Seunghun Han wrote: > > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > > mainboard, and I had a problem with AMD's fTPM. My machine showed an error > > > message below, and the fTPM didn't work because of it. > > > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > > [mem 0x79b4f000-0x79b4] > > > [ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 > > > > > > When I saw the iomem, I found two fTPM regions were in the ACPI NVS area. > > > The regions are below. > > > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > > 79b4b000-79b4bfff : MSFT0101:00 > > > 79b4f000-79b4 : MSFT0101:00 > > > > > > After analyzing this issue, I found that crb_map_io() function called > > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the TPM > > > CRB driver to assign a resource in it because a busy bit was set to > > > the ACPI NVS area. > > > > > > To support AMD's fTPM, I added a function to check intersects between > > > the TPM region and ACPI NVS before it mapped the region. If some > > > intersects are detected, the function just calls devm_ioremap() for > > > a workaround. If there is no intersect, it calls devm_ioremap_resource(). > > > > > > Signed-off-by: Seunghun Han > > > > This problem is still valid and not addressed by Vanya's patch (and > > should not be as it is a disjoint issue). However, calling > > devm_ioremap() is somewhat racy as the NVS driver is not aware of that. > > > > My take is that this should be fixed in the code that assigns regions to > > the NVS driver e.g. it could look up the regions assigned to the > > MSFT0101 and ignore those regions. In the end linux-acpi maintainers > > have the say on this but this would be the angle that I'd take to > > implement such patch probably. > > Matthew pointed out that having a hook in NVS driver is better solution > because it is nil functionality if the TPM driver is loaded. We need > functions to: > > 1. Request a region from the NVS driver (when tpm_crb loads) > 2. Release a region back to the NVS Driver (when tpm_crb unloads). > > My proposal would unnecessarily duplicate code and also leave a > side-effect when TPM is not used in the first place. > > I see this as the overally best solution. If you can come up with a > patch for the NVS side and changes to CRB drivers to utilize the new > hooks, then combined with Vanya's changes we have a sustainable solution > for AMD fTPM. It's a great solution. I will update this patch on your advice and send it to you soon. By the way, I have a question about your advice. If we handle the NVS region with NVS driver, calling devm_ioremap() function is fine like crb_ioremap_resource() function in this patch? > > /Jarkko
Re: [PATCH v2 1/2] tpm: tpm_crb: enhance command and response buffer size calculation code
> > On Mon, Sep 09, 2019 at 06:09:05PM +0900, Seunghun Han wrote: > > The purpose of crb_fixup_cmd_size() function is to work around broken > > BIOSes and get the trustable size between the ACPI region and register. > > When the TPM has a command buffer and response buffer independently, > > the crb_map_io() function calls crb_fixup_cmd_size() twice to calculate > > each buffer size. However, the current implementation of it considers > > one of two buffers. > > > > To support independent command and response buffers, I changed > > crb_check_resource() function for storing ACPI TPB regions to a list. > > I also changed crb_fixup_cmd_size() to use the list for calculating each > > buffer size. > > > > Signed-off-by: Seunghun Han > > I think as far as the tpm_crb goes I focus on getting Vanya's change > landed because it is better structured, more mature and the first > version was sent couple of weeks earlier. You are welcome to make > your remarks on that patch. Thank you for your review. I already knew Vanya's patch, https://lkml.org/lkml/2019/8/11/151, and this patch didn't work for me. I also couldn't agree on some points like memory allocating inside the ACPI walker and changing many parts of TPM driver. I would like to support AMD's fTPM with the smallest changes since this is a workaround as you know. I didn't understand clearly what your point is. Do you want me to change my patches structurally like Vanya's patch and make patch v3? or want me to give some advice to Vanya? > > /Jarkko
[PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
I got an AMD system which had a Ryzen Threadripper 1950X and MSI
mainboard, and I had a problem with AMD's fTPM. My machine showed an error
message below, and the fTPM didn't work because of it.
[ 5.732084] tpm_crb MSFT0101:00: can't request region for resource
[mem 0x79b4f000-0x79b4]
[ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16
When I saw the iomem, I found two fTPM regions were in the ACPI NVS area.
The regions are below.
79a39000-79b6afff : ACPI Non-volatile Storage
79b4b000-79b4bfff : MSFT0101:00
79b4f000-79b4 : MSFT0101:00
After analyzing this issue, I found that crb_map_io() function called
devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the TPM
CRB driver to assign a resource in it because a busy bit was set to
the ACPI NVS area.
To support AMD's fTPM, I added a function to check intersects between
the TPM region and ACPI NVS before it mapped the region. If some
intersects are detected, the function just calls devm_ioremap() for
a workaround. If there is no intersect, it calls devm_ioremap_resource().
Signed-off-by: Seunghun Han
---
Changes in v2: fix a warning of kbuild test robot. The link is below.
https://lkml.org/lkml/2019/8/31/217
drivers/char/tpm/tpm_crb.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 14f486c23af2..6b98a3a995b7 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -450,6 +450,27 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
return 1;
}
+static void __iomem *crb_ioremap_resource(struct device *dev,
+ const struct resource *res)
+{
+ int rc;
+ resource_size_t size = resource_size(res);
+
+ /* Broken BIOS assigns command and response buffers in ACPI NVS region.
+* Check intersections between a resource and ACPI NVS for W/A.
+*/
+ rc = region_intersects(res->start, size, IORESOURCE_MEM |
+ IORESOURCE_BUSY, IORES_DESC_ACPI_NV_STORAGE);
+ if (rc != REGION_DISJOINT) {
+ dev_err(dev,
+ FW_BUG "Resource overlaps with a ACPI NVS. %pr\n",
+ res);
+ return devm_ioremap(dev, res->start, size);
+ }
+
+ return devm_ioremap_resource(dev, res);
+}
+
static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
struct resource *io_res, u64 start, u32 size)
{
@@ -464,7 +485,7 @@ static void __iomem *crb_map_res(struct device *dev, struct
crb_priv *priv,
return (void __iomem *) ERR_PTR(-EINVAL);
if (!resource_contains(io_res, _res))
- return devm_ioremap_resource(dev, _res);
+ return crb_ioremap_resource(dev, _res);
return priv->iobase + (new_res.start - io_res->start);
}
@@ -536,7 +557,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
goto out_early;
}
- priv->iobase = devm_ioremap_resource(dev, _res);
+ priv->iobase = crb_ioremap_resource(dev, _res);
if (IS_ERR(priv->iobase)) {
ret = PTR_ERR(priv->iobase);
goto out_early;
--
2.21.0
[PATCH v2 0/2] Enhance support for the AMD's fTPM
This patch series enhances the support for the AMD's fTPM. The AMD system assigned a command buffer and response buffer independently in ACPI NVS region. ACPI NVS region allowed nothing to assign a resource in it. For supporting AMD's fTPM, I made a patch to enhance the code of command and response buffer size calculation. I also made a patch to detect TPM regions in ACPI NVS and work around it. Changes in v2: - fix a warning of kbuild test robot. The link is below. https://lkml.org/lkml/2019/8/31/217 Seunghun Han (2): tpm: tpm_crb: enhance command and response buffer size calculation code tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM drivers/char/tpm/tpm_crb.c | 69 -- 1 file changed, 59 insertions(+), 10 deletions(-) -- 2.21.0
[PATCH v2 1/2] tpm: tpm_crb: enhance command and response buffer size calculation code
The purpose of crb_fixup_cmd_size() function is to work around broken
BIOSes and get the trustable size between the ACPI region and register.
When the TPM has a command buffer and response buffer independently,
the crb_map_io() function calls crb_fixup_cmd_size() twice to calculate
each buffer size. However, the current implementation of it considers
one of two buffers.
To support independent command and response buffers, I changed
crb_check_resource() function for storing ACPI TPB regions to a list.
I also changed crb_fixup_cmd_size() to use the list for calculating each
buffer size.
Signed-off-by: Seunghun Han
---
Changes in v2: same as v1.
drivers/char/tpm/tpm_crb.c | 44 +++---
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..14f486c23af2 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -442,6 +442,9 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
acpi_dev_resource_address_space(ares, )) {
*io_res = *res;
io_res->name = NULL;
+
+ /* Add this TPM CRB resource to the list */
+ return 0;
}
return 1;
@@ -471,7 +474,7 @@ static void __iomem *crb_map_res(struct device *dev, struct
crb_priv *priv,
* region vs the registers. Trust the ACPI region. Such broken systems
* probably cannot send large TPM commands since the buffer will be truncated.
*/
-static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
+static u64 __crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
u64 start, u64 size)
{
if (io_res->start > start || io_res->end < start)
@@ -487,6 +490,26 @@ static u64 crb_fixup_cmd_size(struct device *dev, struct
resource *io_res,
return io_res->end - start + 1;
}
+static u64 crb_fixup_cmd_size(struct device *dev, struct list_head *resources,
+ u64 start, u64 size)
+{
+ struct resource_entry *pos;
+ struct resource *cur_res;
+ u64 ret = size;
+
+ /* Check all TPM CRB resources with the start and size values */
+ resource_list_for_each_entry(pos, resources) {
+ cur_res = pos->res;
+
+ ret = __crb_fixup_cmd_size(dev, cur_res, start, size);
+ /* Broken BIOS is detected. Trust the ACPI region. */
+ if (ret < size)
+ break;
+ }
+
+ return ret;
+}
+
static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
struct acpi_table_tpm2 *buf)
{
@@ -506,16 +529,18 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
_res);
if (ret < 0)
return ret;
- acpi_dev_free_resource_list();
if (resource_type(_res) != IORESOURCE_MEM) {
dev_err(dev, FW_BUG "TPM2 ACPI table does not define a memory
resource\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_early;
}
priv->iobase = devm_ioremap_resource(dev, _res);
- if (IS_ERR(priv->iobase))
- return PTR_ERR(priv->iobase);
+ if (IS_ERR(priv->iobase)) {
+ ret = PTR_ERR(priv->iobase);
+ goto out_early;
+ }
/* The ACPI IO region starts at the head area and continues to include
* the control area, as one nice sane region except for some older
@@ -532,7 +557,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
ret = __crb_request_locality(dev, priv, 0);
if (ret)
- return ret;
+ goto out_early;
priv->regs_t = crb_map_res(dev, priv, _res, buf->control_address,
sizeof(struct crb_regs_tail));
@@ -552,7 +577,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
pa_high = ioread32(>regs_t->ctrl_cmd_pa_high);
pa_low = ioread32(>regs_t->ctrl_cmd_pa_low);
cmd_pa = ((u64)pa_high << 32) | pa_low;
- cmd_size = crb_fixup_cmd_size(dev, _res, cmd_pa,
+ cmd_size = crb_fixup_cmd_size(dev, , cmd_pa,
ioread32(>regs_t->ctrl_cmd_size));
dev_dbg(dev, "cmd_hi = %X cmd_low = %X cmd_size %X\n",
@@ -566,7 +591,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
memcpy_fromio(&__rsp_pa, >regs_t->ctrl_rsp_pa, 8);
rsp_pa = le64_to_cpu(__rsp_pa);
- rsp_size = crb_fixup_cmd_size(dev, _res, rsp_pa,
+ rsp_size = crb_fixup_cmd_size(dev, , rsp_pa,
ioread32(>regs_t->ctrl_rsp_size));
if (cmd_
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > On Tue, 2019-09-03 at 18:56 +0900, Seunghun Han wrote: > > Thank you for your notification. I am sorry. I missed it and > > misunderstood Jarkko's idea. So, I would like to invite Matthew > > Garrett to this thread and attach my opinion on that. The problem is > > that command and response buffers are in ACPI NVS area. ACPI NVS area > > is saved and restored by drivers/acpi/nvs.c during hibernation, so > > command and response buffers in ACPI NVS are also handled by nvs.c > > file. However, TPM CRB driver uses the buffers to control a TPM > > device, therefore, something may break. > > > > I agree on that point. To remove uncertainty and find the solution, > > I read the threads we discussed and did research about two points, 1) > > the race condition and 2) the unexpected behavior of the TPM device. > > > > 1) The race condition concern comes from unknowing buffer access order > > while hibernation. > > If nvs.c and TPM CRB driver access the buffers concurrently, the race > > condition occurs. Then, we can't know the contents of the buffers > > deterministically, and it may occur the failure of TPM device. > > However, hibernation_snapshot() function calls dpm_suspend() and > > suspend_nvs_save() in order when the system enters into hibernation. > > It also calls suspend_nvs_restore() and dpm_resume() in order when the > > system exits from hibernation. So, no race condition occurs while > > hibernation, and we always guarantee the contents of buffers as we > > expect. > > > > 2) The unexpected behavior of the TPM device. > > If nvs.c saves and restores the contents of the TPM CRB buffers while > > hibernation, it may occur the unexpected behavior of the TPM device > > because the buffers are used to control the TPM device. When the > > system entered into hibernation, suspend_nvs_save() saved the command > > and response buffers, and they had the last command and response data. > > After exiting from hibernation, suspend_nvs_restore() restored the > > last command and response data into the buffers and nothing happened. > > I realized that they were just buffers. If we want to send a command > > to the TPM device, we have to set the CRB_START_INVOKE bit to a > > control_start register of a control area. The control area was not in > > the ACPI NVS area, so it was not affected by nvs.c file. We can > > guarantee the behavior of the TPM device. > > > > Because of these two reasons, I agreed on Jarkko's idea in > > https://lkml.org/lkml/2019/8/29/962 . It seems that removing or > > changing regions described in the ACPI table is not natural after > > setup. In my view, saving and restoring buffers was OK like other NVS > > areas were expected because the buffers were in ACPI NVS area. > > > > So, I made and sent this patch series. I would like to solve this > > AMD's fTPM problem because I have been doing research on TPM and this > > problem is critical for me (as you know fTPM doesn't work). If you > > have any other concern or advice on the patch I made, please let me > > know. > > Please take time to edit your responses. Nobody will read that properly > because it is way too exhausting. A long prose only indicates unclear > thoughts in the end. If you know what you are doing, you can put things > into nutshell only in few senteces. > > /Jarkko > I'm sorry about that. I would like to invite Matthew Garrett and discuss ACPI NVS and command/response buffer mapping again. So, I want to summarize my test result and explain my opinion on that. I think the data and result are important to make a decision clearly. According to my test results, it seems that intersects between ACPI NVS and command/response buffers will not make a problem. Additionally, according to Dave's test results, this patch series can cover not only an intersection with ACPI NVS area but also an intersection with the reserved area. Here is the link, https://lkml.org/lkml/2019/9/3/481 . Considering these results, my patch series can solve AMD's fTPM problems. Matthew, what do you think about test results and this patch? In my view, if the command/response buffers are in ACPI NVS area, saving and restoring the buffers are ok and couldn't break anything. I would like to get some feedback from you. Seunghun
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> I tried your patch out on my systems with a "reserved" but not "NVS" > region conflict, and you are correct - the region is not busy, and > the driver is able to map the buffers with your patch. > > > First of all, I misunderstood your message. > > I have to tell you about the buffer size exactly. The command and response > > buffer sizes in ACPI table were 0x1000 and this was 4K, not 1K. The sizes in > > the control register were 0x4000 and this was 16K (large buffer size), not > > 4K. > > I have been using the TPM for my research and the typical cases like > > creating > > public/private keys, encrypting/decrypting data, sealing/unsealing a > > secrete, > > and getting random numbers are not over 4K buffer. So, as you know, I think > > the 4K buffer can handle the most cases and the current implementation of > > crb_fixup_cmd_size() works well. If you concern the specific case that uses > > over 4K buffer, please let me know. > > I have read postings of some systems where ACPI says 1K, but in all of my > cases > that I can test, you are correct that ACPI is saying 4K instead of the > device's 16K. > I tried really hard, but couldn't send any valid requests over 4K, (I believe > that's > actually the max by the spec), and therefore never saw any failures on my > systems. I think the driver behavior is wrong for those other cases, but > perhaps > this should wait until someone can get access and do the testing. > > So I'm happy with your patches, other than what is decided for the nvs driver > conflict. I'm testing them on some production systems, and have seen no other > issues. > > dave Thank you for your help and testing. I would like to make patch v2 to change the point that kbuild robot told me. If you don't mind, may I add "tested-by" tag to patch v2 with your name and email address? Seunghun
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
>
> On Tue, 2019-09-03 at 07:42 +0900, Seunghun Han wrote:
> > I have a question. Do you think this patch is not enough to handle
> > AMD's fTPM problem? If so, would you tell me about it? I will change
> > my patch.
>
> I have no new feedback to give at this point and no absolutely time to
> brainstorm new ideas.
>
> You've now sent the same patch set version twice. The one that was
> sent 8-30 has the same patch version and no change log so no action
> taken from my part.
>
> Please version your patch sets and keep the change log in the cover
> letter.
>
> /Jarkko
>
Thank you for your advice. Then, is it enough that I change the point
the kbuild test robot told me below and resent the patch with
versioning?
coccinelle warnings: (new ones prefixed by >>)
>> drivers/char/tpm/tpm_crb.c:457:29-32: WARNING: Suspicious code.
>> resource_size is maybe missing with res
vim +457 drivers/char/tpm/tpm_crb.c
452
453 static void __iomem *crb_ioremap_resource(struct device *dev,
454const struct resource *res)
455 {
456 int rc;
> 457 resource_size_t size = res->end - res->start;
458
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > > From: Seunghun Han > > Sent: Friday, August 30, 2019 12:55 PM > > To: Safford, David (GE Global Research, US) > > Cc: Jason Gunthorpe ; Jarkko Sakkinen > > ; Peter Huewe ; > > open list:TPM DEVICE DRIVER ; Linux > > Kernel Mailing List > > Subject: EXT: Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping > > mechanism for supporting AMD's fTPM > > > > > > > > > From: linux-integrity-ow...@vger.kernel.org > > > ow...@vger.kernel.org> On Behalf Of Seunghun Han > > > > Sent: Friday, August 30, 2019 9:55 AM > > > > To: Jason Gunthorpe > > > > Cc: Jarkko Sakkinen ; Peter Huewe > > > > ; open list:TPM DEVICE DRIVER > > > integr...@vger.kernel.org>; Linux Kernel Mailing List > > > ker...@vger.kernel.org> > > > > Subject: EXT: Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping > > > > mechanism for supporting AMD's fTPM > > > > > > > > > > > > > > On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote: > > > > > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > > > > > mainboard, and I had a problem with AMD's fTPM. My machine > > > > > > showed > > > > an > > > > > > error message below, and the fTPM didn't work because of it. > > > > > > > > > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > > > > > [mem 0x79b4f000-0x79b4] [ 5.732089] tpm_crb: > > > > > > probe of MSFT0101:00 failed with error -16 > > > > > > > > > > > > When I saw the iomem, I found two fTPM regions were in the ACPI > > > > > > NVS > > > > area. > > > > > > The regions are below. > > > > > > > > > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > > > > > 79b4b000-79b4bfff : MSFT0101:00 > > > > > > 79b4f000-79b4 : MSFT0101:00 > > > > > > > > > > > > After analyzing this issue, I found that crb_map_io() function > > > > > > called > > > > > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow > > > > > > the TPM CRB driver to assign a resource in it because a busy bit > > > > > > was set to the ACPI NVS area. > > > > > > > > > > > > To support AMD's fTPM, I added a function to check intersects > > > > > > between the TPM region and ACPI NVS before it mapped the region. > > > > > > If some intersects are detected, the function just calls > > > > > > devm_ioremap() for a workaround. If there is no intersect, it > > > > > > calls > > > > devm_ioremap_resource(). > > > > > > > > > > > > Signed-off-by: Seunghun Han > > > > > > --- > > > > > > drivers/char/tpm/tpm_crb.c | 25 +++-- > > > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > > > > > This still seems to result in two drivers controlling the same memory. > > > > > Does this create bugs and races during resume? > > > > > > > > > > Jason > > > > > > > > When I tested this patch in my machine, it seemed that ACPI NVS was > > > > saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM > > > > while suspending. Then, ACPI NVS was restored while resuming. > > > > After resuming, PCRs didn't change and TPM2 tools such as > > > > tpm2_pcrlist, tpm2_extend, tpm2_getrandoms worked well. > > > > So, according to my test result, it seems that the patch doesn't > > > > create bugs and race during resume. > > > > > > > > Seunghun > > > > > > This was discussed earlier on the list. > > > The consensus was that, while safe now, this would be fragile, and > > > subject to unexpected changes in ACPI/NVS, and we really need to tell > > > NVS to exclude the regions for long term safety. > > > > Thank you for your advice. We also discussed earlier and concluded that > > checking and raw remapping are enough to work around this. The link is > > here, https://lkml.org/lkml/2019/8/29/962 . > > I don't see Matthew Garrett's agreement on that thread. Thank you for your notification. I am sorry. I missed it and misunderstoo
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > > From: Seunghun Han > > Sent: Friday, August 30, 2019 12:55 PM > > To: Safford, David (GE Global Research, US) > > Cc: Jason Gunthorpe ; Jarkko Sakkinen > > ; Peter Huewe ; > > open list:TPM DEVICE DRIVER ; Linux > > Kernel Mailing List > > Subject: EXT: Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping > > mechanism for supporting AMD's fTPM > > > > > > > > > From: linux-integrity-ow...@vger.kernel.org > > > ow...@vger.kernel.org> On Behalf Of Seunghun Han > > > > Sent: Friday, August 30, 2019 9:55 AM > > > > To: Jason Gunthorpe > > > > Cc: Jarkko Sakkinen ; Peter Huewe > > > > ; open list:TPM DEVICE DRIVER > > > integr...@vger.kernel.org>; Linux Kernel Mailing List > > > ker...@vger.kernel.org> > > > > Subject: EXT: Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping > > > > mechanism for supporting AMD's fTPM > > > > > > > > > > > > > > On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote: > > > > > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > > > > > mainboard, and I had a problem with AMD's fTPM. My machine > > > > > > showed > > > > an > > > > > > error message below, and the fTPM didn't work because of it. > > > > > > > > > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > > > > > [mem 0x79b4f000-0x79b4] [ 5.732089] tpm_crb: > > > > > > probe of MSFT0101:00 failed with error -16 > > > > > > > > > > > > When I saw the iomem, I found two fTPM regions were in the ACPI > > > > > > NVS > > > > area. > > > > > > The regions are below. > > > > > > > > > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > > > > > 79b4b000-79b4bfff : MSFT0101:00 > > > > > > 79b4f000-79b4 : MSFT0101:00 > > > > > > > > > > > > After analyzing this issue, I found that crb_map_io() function > > > > > > called > > > > > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow > > > > > > the TPM CRB driver to assign a resource in it because a busy bit > > > > > > was set to the ACPI NVS area. > > > > > > > > > > > > To support AMD's fTPM, I added a function to check intersects > > > > > > between the TPM region and ACPI NVS before it mapped the region. > > > > > > If some intersects are detected, the function just calls > > > > > > devm_ioremap() for a workaround. If there is no intersect, it > > > > > > calls > > > > devm_ioremap_resource(). > > > > > > > > > > > > Signed-off-by: Seunghun Han > > > > > > --- > > > > > > drivers/char/tpm/tpm_crb.c | 25 +++-- > > > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > > > > > This still seems to result in two drivers controlling the same memory. > > > > > Does this create bugs and races during resume? > > > > > > > > > > Jason > > > > > > > > When I tested this patch in my machine, it seemed that ACPI NVS was > > > > saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM > > > > while suspending. Then, ACPI NVS was restored while resuming. > > > > After resuming, PCRs didn't change and TPM2 tools such as > > > > tpm2_pcrlist, tpm2_extend, tpm2_getrandoms worked well. > > > > So, according to my test result, it seems that the patch doesn't > > > > create bugs and race during resume. > > > > > > > > Seunghun > > > > > > This was discussed earlier on the list. > > > The consensus was that, while safe now, this would be fragile, and > > > subject to unexpected changes in ACPI/NVS, and we really need to tell > > > NVS to exclude the regions for long term safety. > > > > Thank you for your advice. We also discussed earlier and concluded that > > checking and raw remapping are enough to work around this. The link is > > here, https://lkml.org/lkml/2019/8/29/962 . > > I don't see Matthew Garrett's agreement on that thread. Thank you for your notification. I am sorry. I missed it and misunderstoo
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > On Fri, Aug 30, 2019 at 05:58:39PM +, Safford, David (GE Global Research, > US) wrote: > > > Thank you for your advice. We also discussed earlier and concluded that > > > checking and raw remapping are enough to work around this. The link is > > > here, https://lkml.org/lkml/2019/8/29/962 . > > > > I don't see Matthew Garrett's agreement on that thread. > > No one has agreed on anything. > > /Jarkko Jarkko, you gave me good advice related to the NVS area and mapping like below. "A function that gets region and then checks if NVS driver has matching one and returns true/false based on that should be good enough. Then you raw ioremap() in the TPM driver." So, I made a patch on your advice and test it. According to my test result, command and response buffers were saved and restored while hibernation. And, there was no side-effect because they were just buffers and hibernation didn't affect the control area of TPM CRB driver. So, I think that saving and restoring buffers during sleep is no problem. I also think your advice and solution are clear and good to work around AMD's fTPM. I will attach my detailed test result soon. Jarkko, I have a question. Do you think this patch is not enough to handle AMD's fTPM problem? If so, would you tell me about it? I will change my patch. Seunghun
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > > From: linux-integrity-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Seunghun Han > > Sent: Friday, August 30, 2019 9:55 AM > > To: Jason Gunthorpe > > Cc: Jarkko Sakkinen ; Peter Huewe > > ; open list:TPM DEVICE DRIVER > integr...@vger.kernel.org>; Linux Kernel Mailing List > ker...@vger.kernel.org> > > Subject: EXT: Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping > > mechanism for supporting AMD's fTPM > > > > > > > > On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote: > > > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > > > mainboard, and I had a problem with AMD's fTPM. My machine showed > > an > > > > error message below, and the fTPM didn't work because of it. > > > > > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > > > [mem 0x79b4f000-0x79b4] [ 5.732089] tpm_crb: probe > > > > of MSFT0101:00 failed with error -16 > > > > > > > > When I saw the iomem, I found two fTPM regions were in the ACPI NVS > > area. > > > > The regions are below. > > > > > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > > > 79b4b000-79b4bfff : MSFT0101:00 > > > > 79b4f000-79b4 : MSFT0101:00 > > > > > > > > After analyzing this issue, I found that crb_map_io() function > > > > called > > > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the > > > > TPM CRB driver to assign a resource in it because a busy bit was set > > > > to the ACPI NVS area. > > > > > > > > To support AMD's fTPM, I added a function to check intersects > > > > between the TPM region and ACPI NVS before it mapped the region. If > > > > some intersects are detected, the function just calls devm_ioremap() > > > > for a workaround. If there is no intersect, it calls > > devm_ioremap_resource(). > > > > > > > > Signed-off-by: Seunghun Han > > > > --- > > > > drivers/char/tpm/tpm_crb.c | 25 +++-- > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > This still seems to result in two drivers controlling the same memory. > > > Does this create bugs and races during resume? > > > > > > Jason > > > > When I tested this patch in my machine, it seemed that ACPI NVS was saved > > after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM while > > suspending. Then, ACPI NVS was restored while resuming. > > After resuming, PCRs didn't change and TPM2 tools such as tpm2_pcrlist, > > tpm2_extend, tpm2_getrandoms worked well. > > So, according to my test result, it seems that the patch doesn't create bugs > > and race during resume. > > > > Seunghun > > This was discussed earlier on the list. > The consensus was that, while safe now, this would be fragile, and subject to > unexpected changes in ACPI/NVS, and we really need to tell NVS to exclude the > regions for long term safety. Thank you for your advice. We also discussed earlier and concluded that checking and raw remapping are enough to work around this. The link is here, https://lkml.org/lkml/2019/8/29/962 . > As separate issues, the patches do not work at all on some of my AMD systems. > First, you only force the remap if the overlap is with NVS, but I have systems > where the overlap is with other reserved regions. You should force the remap > regardless, but if it is NVS, grab the space back from NVS. I didn't know about that. I just found the case from your thread that AMD system assigned TPM region into the reserved area. However, as I know, the reserved area has no busy bit so that TPM CRB driver could assign buffer resources in it. Right? In my view, if you patched your TPM driver with my patch series, then it could work. Would you explain what happened in TPM CRB driver and reserved area? > > Second, the patch extends the wrong behavior of the current driver to both > buffer regions. If there is a conflict between what the device's control > register says, and what ACPI says, the existing driver explicitly "trusts the > ACPI". > This is just wrong. The actual device will use the areas as defined by its > control registers regardless of what ACPI says. I talked to Microsoft, and > their driver trusts the control register values, and doesn't even look at the > ACPI values. As you know, the original code trusts the ACPI table because of the workaround for broken BIOS, and this code has work
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > On Fri, Aug 30, 2019 at 10:54:59PM +0900, Seunghun Han wrote: > > > When I tested this patch in my machine, it seemed that ACPI NVS was > > saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM > > while suspending. Then, ACPI NVS was restored while resuming. > > After resuming, PCRs didn't change and TPM2 tools such as > > tpm2_pcrlist, tpm2_extend, tpm2_getrandoms worked well. > > So, according to my test result, it seems that the patch doesn't > > create bugs and race during resume. > > I have a feeling that is shear luck of link time ordering and not guarenteed?? > > Jason No, it is guaranteed. As you know, suspend_nvs_save() is called by acpi_pm_pre_suspend(), and it is called by platform_suspend_prepare_noirq(). platform_suspend_prepare_noirq() is also called by suspend_enter(), and it already suspends all devices like TPM CRB driver before calling platform_suspend_prepare_noirq(). This means that the order is guaranteed and we don't need to worry about it. Seunghun
Re: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> > On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote: > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > mainboard, and I had a problem with AMD's fTPM. My machine showed an error > > message below, and the fTPM didn't work because of it. > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > [mem 0x79b4f000-0x79b4] > > [ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 > > > > When I saw the iomem, I found two fTPM regions were in the ACPI NVS area. > > The regions are below. > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > 79b4b000-79b4bfff : MSFT0101:00 > > 79b4f000-79b4 : MSFT0101:00 > > > > After analyzing this issue, I found that crb_map_io() function called > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the TPM > > CRB driver to assign a resource in it because a busy bit was set to > > the ACPI NVS area. > > > > To support AMD's fTPM, I added a function to check intersects between > > the TPM region and ACPI NVS before it mapped the region. If some > > intersects are detected, the function just calls devm_ioremap() for > > a workaround. If there is no intersect, it calls devm_ioremap_resource(). > > > > Signed-off-by: Seunghun Han > > --- > > drivers/char/tpm/tpm_crb.c | 25 +++-- > > 1 file changed, 23 insertions(+), 2 deletions(-) > > This still seems to result in two drivers controlling the same > memory. Does this create bugs and races during resume? > > Jason When I tested this patch in my machine, it seemed that ACPI NVS was saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM while suspending. Then, ACPI NVS was restored while resuming. After resuming, PCRs didn't change and TPM2 tools such as tpm2_pcrlist, tpm2_extend, tpm2_getrandoms worked well. So, according to my test result, it seems that the patch doesn't create bugs and race during resume. Seunghun
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> > On Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote: > > > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote: > > > > > > > > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote: > > > > > > > > > > > I got your point. Is there any problem if some regions which don't > > > > > > need to be handled in NVS area are saved and restored? If there is a > > > > > > problem, how about adding code for ignoring the regions in NVS area > > > > > > to > > > > > > the nvs.c file like Jarkko said? If we add the code, we can save and > > > > > > restore NVS area without driver's interaction. > > > > > > > > > > The only thing that knows which regions should be skipped by the NVS > > > > > driver is the hardware specific driver, so the TPM driver needs to ask > > > > > the NVS driver to ignore that region and grant control to the TPM > > > > > driver. > > > > > > > > > > -- > > > > > Matthew Garrett | mj...@srcf.ucam.org > > > > > > > > Thank you, Matthew and Jarkko. > > > > It seems that the TPM driver needs to handle the specific case that > > > > TPM regions are in the NVS. I would make a patch that removes TPM > > > > regions from the ACPI NVS by requesting to the NVS driver soon. > > > > > > > > Jarkko, > > > > I would like to get some advice on it. What do you think about > > > > removing TPM regions from the ACPI NVS in TPM CRB driver? If you don't > > > > mind, I would make the patch about it. > > > > > > I'm not sure if ignoring is right call. Then the hibernation behaviour > > > for TPM regions would break. > > > > > > Thus, should be "ask access" rather than "grant control". > > I agree with your idea. It seems to make trouble. So, I would like to > do like your idea below. > > > Or "reserve access" as NVS driver does not have intelligence to do any > > policy based decision here. > > > > A function that gets region and then checks if NVS driver has matching > > one and returns true/false based on that should be good enough. Then > > you raw ioremap() in the TPM driver. > > > > /Jarkko > > This solution is great and clear to me. I will make a new patch on > your advice and test it in my machine. After that, I will send it > again soon. > I really appreciate it. > > Seunghun I have made and sent patches on your advice. The patch links are below and please review them. [PATCH 0/2] https://lkml.org/lkml/2019/8/30/372 [PATCH 1/2] https://lkml.org/lkml/2019/8/30/373 [PATCH 2/2] https://lkml.org/lkml/2019/8/30/374 Thank you again for your sincere advice. Seunghun
[PATCH 1/2] tpm: tpm_crb: enhance command and response buffer size calculation code
The purpose of crb_fixup_cmd_size() function is to work around broken
BIOSes and get the trustable size between the ACPI region and register.
When the TPM has a command buffer and response buffer independently,
the crb_map_io() function calls crb_fixup_cmd_size() twice to calculate
each buffer size. However, the current implementation of it considers
one of two buffers.
To support independent command and response buffers, I changed
crb_check_resource() function for storing ACPI TPB regions to a list.
I also changed crb_fixup_cmd_size() to use the list for calculating each
buffer size.
Signed-off-by: Seunghun Han
---
drivers/char/tpm/tpm_crb.c | 44 +++---
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..14f486c23af2 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -442,6 +442,9 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
acpi_dev_resource_address_space(ares, )) {
*io_res = *res;
io_res->name = NULL;
+
+ /* Add this TPM CRB resource to the list */
+ return 0;
}
return 1;
@@ -471,7 +474,7 @@ static void __iomem *crb_map_res(struct device *dev, struct
crb_priv *priv,
* region vs the registers. Trust the ACPI region. Such broken systems
* probably cannot send large TPM commands since the buffer will be truncated.
*/
-static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
+static u64 __crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
u64 start, u64 size)
{
if (io_res->start > start || io_res->end < start)
@@ -487,6 +490,26 @@ static u64 crb_fixup_cmd_size(struct device *dev, struct
resource *io_res,
return io_res->end - start + 1;
}
+static u64 crb_fixup_cmd_size(struct device *dev, struct list_head *resources,
+ u64 start, u64 size)
+{
+ struct resource_entry *pos;
+ struct resource *cur_res;
+ u64 ret = size;
+
+ /* Check all TPM CRB resources with the start and size values */
+ resource_list_for_each_entry(pos, resources) {
+ cur_res = pos->res;
+
+ ret = __crb_fixup_cmd_size(dev, cur_res, start, size);
+ /* Broken BIOS is detected. Trust the ACPI region. */
+ if (ret < size)
+ break;
+ }
+
+ return ret;
+}
+
static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
struct acpi_table_tpm2 *buf)
{
@@ -506,16 +529,18 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
_res);
if (ret < 0)
return ret;
- acpi_dev_free_resource_list();
if (resource_type(_res) != IORESOURCE_MEM) {
dev_err(dev, FW_BUG "TPM2 ACPI table does not define a memory
resource\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_early;
}
priv->iobase = devm_ioremap_resource(dev, _res);
- if (IS_ERR(priv->iobase))
- return PTR_ERR(priv->iobase);
+ if (IS_ERR(priv->iobase)) {
+ ret = PTR_ERR(priv->iobase);
+ goto out_early;
+ }
/* The ACPI IO region starts at the head area and continues to include
* the control area, as one nice sane region except for some older
@@ -532,7 +557,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
ret = __crb_request_locality(dev, priv, 0);
if (ret)
- return ret;
+ goto out_early;
priv->regs_t = crb_map_res(dev, priv, _res, buf->control_address,
sizeof(struct crb_regs_tail));
@@ -552,7 +577,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
pa_high = ioread32(>regs_t->ctrl_cmd_pa_high);
pa_low = ioread32(>regs_t->ctrl_cmd_pa_low);
cmd_pa = ((u64)pa_high << 32) | pa_low;
- cmd_size = crb_fixup_cmd_size(dev, _res, cmd_pa,
+ cmd_size = crb_fixup_cmd_size(dev, , cmd_pa,
ioread32(>regs_t->ctrl_cmd_size));
dev_dbg(dev, "cmd_hi = %X cmd_low = %X cmd_size %X\n",
@@ -566,7 +591,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
memcpy_fromio(&__rsp_pa, >regs_t->ctrl_rsp_pa, 8);
rsp_pa = le64_to_cpu(__rsp_pa);
- rsp_size = crb_fixup_cmd_size(dev, _res, rsp_pa,
+ rsp_size = crb_fixup_cmd_size(dev, , rsp_pa,
ioread32(>regs_t->ctrl_rsp_size));
if (cmd_pa != rsp_pa) {
@@ -596,6 +621,9 @@ stati
[PATCH 0/2] Enhance support for the AMD's fTPM
This patch series enhances the support for the AMD's fTPM. The AMD system assigned a command buffer and response buffer independently in ACPI NVS region. ACPI NVS region allowed nothing to assign a resource in it. For supporting AMD's fTPM, I made a patch to enhance the code of command and response buffer size calculation. I also made a patch to detect TPM regions in ACPI NVS and work around it. Seunghun Han (2): tpm: tpm_crb: enhance command and response buffer size calculation code tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM drivers/char/tpm/tpm_crb.c | 69 -- 1 file changed, 59 insertions(+), 10 deletions(-) -- 2.21.0
[PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
I got an AMD system which had a Ryzen Threadripper 1950X and MSI
mainboard, and I had a problem with AMD's fTPM. My machine showed an error
message below, and the fTPM didn't work because of it.
[ 5.732084] tpm_crb MSFT0101:00: can't request region for resource
[mem 0x79b4f000-0x79b4]
[ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16
When I saw the iomem, I found two fTPM regions were in the ACPI NVS area.
The regions are below.
79a39000-79b6afff : ACPI Non-volatile Storage
79b4b000-79b4bfff : MSFT0101:00
79b4f000-79b4 : MSFT0101:00
After analyzing this issue, I found that crb_map_io() function called
devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the TPM
CRB driver to assign a resource in it because a busy bit was set to
the ACPI NVS area.
To support AMD's fTPM, I added a function to check intersects between
the TPM region and ACPI NVS before it mapped the region. If some
intersects are detected, the function just calls devm_ioremap() for
a workaround. If there is no intersect, it calls devm_ioremap_resource().
Signed-off-by: Seunghun Han
---
drivers/char/tpm/tpm_crb.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 14f486c23af2..7b60cd594b92 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -450,6 +450,27 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
return 1;
}
+static void __iomem *crb_ioremap_resource(struct device *dev,
+ const struct resource *res)
+{
+ int rc;
+ resource_size_t size = res->end - res->start;
+
+ /* Broken BIOS assigns command and response buffers in ACPI NVS region.
+* Check intersections between a resource and ACPI NVS for W/A.
+*/
+ rc = region_intersects(res->start, size, IORESOURCE_MEM |
+ IORESOURCE_BUSY, IORES_DESC_ACPI_NV_STORAGE);
+ if (rc != REGION_DISJOINT) {
+ dev_err(dev,
+ FW_BUG "Resource overlaps with a ACPI NVS. %pr\n",
+ res);
+ return devm_ioremap(dev, res->start, size);
+ }
+
+ return devm_ioremap_resource(dev, res);
+}
+
static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
struct resource *io_res, u64 start, u32 size)
{
@@ -464,7 +485,7 @@ static void __iomem *crb_map_res(struct device *dev, struct
crb_priv *priv,
return (void __iomem *) ERR_PTR(-EINVAL);
if (!resource_contains(io_res, _res))
- return devm_ioremap_resource(dev, _res);
+ return crb_ioremap_resource(dev, _res);
return priv->iobase + (new_res.start - io_res->start);
}
@@ -536,7 +557,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
goto out_early;
}
- priv->iobase = devm_ioremap_resource(dev, _res);
+ priv->iobase = crb_ioremap_resource(dev, _res);
if (IS_ERR(priv->iobase)) {
ret = PTR_ERR(priv->iobase);
goto out_early;
--
2.21.0
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> > On Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote: > > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote: > > > > > > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote: > > > > > > > > > I got your point. Is there any problem if some regions which don't > > > > > need to be handled in NVS area are saved and restored? If there is a > > > > > problem, how about adding code for ignoring the regions in NVS area to > > > > > the nvs.c file like Jarkko said? If we add the code, we can save and > > > > > restore NVS area without driver's interaction. > > > > > > > > The only thing that knows which regions should be skipped by the NVS > > > > driver is the hardware specific driver, so the TPM driver needs to ask > > > > the NVS driver to ignore that region and grant control to the TPM > > > > driver. > > > > > > > > -- > > > > Matthew Garrett | mj...@srcf.ucam.org > > > > > > Thank you, Matthew and Jarkko. > > > It seems that the TPM driver needs to handle the specific case that > > > TPM regions are in the NVS. I would make a patch that removes TPM > > > regions from the ACPI NVS by requesting to the NVS driver soon. > > > > > > Jarkko, > > > I would like to get some advice on it. What do you think about > > > removing TPM regions from the ACPI NVS in TPM CRB driver? If you don't > > > mind, I would make the patch about it. > > > > I'm not sure if ignoring is right call. Then the hibernation behaviour > > for TPM regions would break. > > > > Thus, should be "ask access" rather than "grant control". I agree with your idea. It seems to make trouble. So, I would like to do like your idea below. > Or "reserve access" as NVS driver does not have intelligence to do any > policy based decision here. > > A function that gets region and then checks if NVS driver has matching > one and returns true/false based on that should be good enough. Then > you raw ioremap() in the TPM driver. > > /Jarkko This solution is great and clear to me. I will make a new patch on your advice and test it in my machine. After that, I will send it again soon. I really appreciate it. Seunghun
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote: > > > I got your point. Is there any problem if some regions which don't > > need to be handled in NVS area are saved and restored? If there is a > > problem, how about adding code for ignoring the regions in NVS area to > > the nvs.c file like Jarkko said? If we add the code, we can save and > > restore NVS area without driver's interaction. > > The only thing that knows which regions should be skipped by the NVS > driver is the hardware specific driver, so the TPM driver needs to ask > the NVS driver to ignore that region and grant control to the TPM > driver. > > -- > Matthew Garrett | mj...@srcf.ucam.org Thank you, Matthew and Jarkko. It seems that the TPM driver needs to handle the specific case that TPM regions are in the NVS. I would make a patch that removes TPM regions from the ACPI NVS by requesting to the NVS driver soon. Jarkko, I would like to get some advice on it. What do you think about removing TPM regions from the ACPI NVS in TPM CRB driver? If you don't mind, I would make the patch about it. Seunghun
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> On Tue, Aug 27, 2019 at 1:23 AM Seunghun Han wrote: > > If the regions allocated in the NVS region need to be handled by a > > driver, the callback mechanism is good for it. However, this case > > doesn't need it because the regions allocated in NVS are just I/O > > regions. > > > > In my opinion, if the driver wants to handle the region in the NVS > > while suspending or hibernating, it has to use register_pm_notifier() > > function and handle the event. We already had the mechanism that could > > ensure that the cases you worried about would be handled, so it seems > > to me that removing the busy bit from the NVS region is fine. > > No. The NVS regions are regions that need to be saved and restored > over hibernation, but which aren't otherwise handled by a driver - > that's why the NVS code exists. If drivers are allowed to bind to NVS > regions without explicit handling, they risk conflicting with that. I got your point. Is there any problem if some regions which don't need to be handled in NVS area are saved and restored? If there is a problem, how about adding code for ignoring the regions in NVS area to the nvs.c file like Jarkko said? If we add the code, we can save and restore NVS area without driver's interaction. Seunghun
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> > On Mon, Aug 26, 2019 at 10:40:25AM -0700, Matthew Garrett wrote: > > On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han wrote: > > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like > > > the reserved area so that AMD's fTPM regions could be assigned in it. > > > > drivers/acpi/nvs.c saves and restores the contents of NVS regions, and > > if other drivers use these regions without any awareness of this then > > things may break. I'm reluctant to say that just unilaterally marking > > these regions as available is a good thing, but it's clearly what's > > expected by AMD's implementation. One approach would be to have a > > callback into the nvs code to indicate that a certain region should be > > handed off to a driver, which would ensure that we can handle this on > > a case by case basis? > > What if E820 would just have a small piece of code just for fTPM's e.g. > it would check the ACPI tree for fTPM's and ignore TPM regions. > > /Jarkko It seems that it is possible. However, the memory layout is set by enumerating e820 table and ACPI table in order, and the memory regions are typically added and overlapped to the existing memory layout. I also worry about the direct interaction between the e820 table and ACPI table. As I know, they have no straightforward interface or relationship. So, if we make the code for identifying fTPM regions in ACPI table and write it to e820 code, we would meet other problems like "acpi=off" kernel option. In my view, it is natural that ACPI NVS allows device drivers to assign some regions in it if the hardware reports the regions there. Seunghun
Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
> > On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han wrote: > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like > > the reserved area so that AMD's fTPM regions could be assigned in it. > > drivers/acpi/nvs.c saves and restores the contents of NVS regions, and > if other drivers use these regions without any awareness of this then > things may break. I'm reluctant to say that just unilaterally marking > these regions as available is a good thing, but it's clearly what's > expected by AMD's implementation. One approach would be to have a > callback into the nvs code to indicate that a certain region should be > handed off to a driver, which would ensure that we can handle this on > a case by case basis? If the regions allocated in the NVS region need to be handled by a driver, the callback mechanism is good for it. However, this case doesn't need it because the regions allocated in NVS are just I/O regions. In my opinion, if the driver wants to handle the region in the NVS while suspending or hibernating, it has to use register_pm_notifier() function and handle the event. We already had the mechanism that could ensure that the cases you worried about would be handled, so it seems to me that removing the busy bit from the NVS region is fine. Seunghun
Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
> > From: linux-integrity-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Jarkko Sakkinen > > Sent: Monday, August 26, 2019 1:59 AM > > To: Seunghun Han > > Cc: Peter Huewe ; Thomas Gleixner > > ; linux-kernel@vger.kernel.org; linux- > > integr...@vger.kernel.org > > Subject: EXT: Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature > > > > On Mon, Aug 26, 2019 at 02:40:19AM +0900, Seunghun Han wrote: > > > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got > > > an AMD system which had a Ryzen Threadripper 1950X and MSI mainboard, > > > and I had a problem with AMD's fTPM. My machine showed an error > > > message below, and the fTPM didn't work because of it. > > > > > > [5.732084] tpm_crb MSFT0101:00: can't request region for resource > > >[mem 0x79b4f000-0x79b4] > > > [5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 > > > > > > When I saw the iomem areas and found two TPM CRB regions were in the > > > ACPI NVS area. The iomem regions are below. > > > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > > 79b4b000-79b4bfff : MSFT0101:00 > > > 79b4f000-79b4 : MSFT0101:00 > > > > > > After analyzing this issue, I found out that a busy bit was set to the > > > ACPI NVS area, and the current Linux kernel allowed nothing to be > > > assigned in it. I also found that the kernel couldn't calculate the > > > sizes of command and response buffers correctly when the TPM regions > > were two or more. > > > > > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area > > > so that AMD's fTPM regions could be assigned in it. I also fixed the > > > bug that did not calculate the sizes of command and response buffer > > correctly. > > The problem is that the acpi tables are _wrong_ in this and other cases. > They not only incorrectly report the area as reserved, but also report > the command and response buffer sizes incorrectly. If you look at > the addresses for the buffers listed in the crb control area, the sizes > are correct (4Kbytes). My patch uses the control area values, and > everything works. The remaining problem is that if acpi reports the > area as NVS, then the linux nvs driver will try to use the space. > I'm looking at how to fix that. I'm not sure, if simply removing > the busy bit is sufficient. > Dave Thank you for your reply. I have read your patch. However, I would like to solve this problem without a kernel parameter. In my view, I'd better change the crb_fixup_cmd_size() function because the TPM CRB driver wants to get the command buffer and response buffer sizes by using the function. I agree on that removing the busy bit is sufficient. Seunghun > > > > > > > Signed-off-by: Seunghun Han > > > > You need to split this into multiple patches e.g. if you think you've fixed > > a > > bug, please write a patch with just the bug fix and nothing else. > > > > For further information, read the section three of > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > > I'd also recommend to check out the earlier discussion on ACPI NVS: > > > > https://lore.kernel.org/linux- > > integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035EF7BC7@ALPMBAPA12.e > > 2k.ad.ge.com/ > > > > /Jarkko
Re: [PATCH] tpm: tpm_crb: Fix an improper buffer size calculation bug
>
> On Mon, Aug 26, 2019 at 04:44:00PM +0900, Seunghun Han wrote:
> > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I found
>
> You can drop the first sentence from the commit message. The SoB below
> is sufficient.
Thank you, and I will remove it from next version of the patch.
> > a bug related to improper buffer size calculation in crb_fixup_cmd_size
> > function.
>
> The purpose is to cap to the ACPI region when we partially overlap to
> workaround BIOS's reporting corrupted ACPI tables so that we don't get
> failure from devm_ioremap().
>
> The only funky thing in that function is that it lets through a buffer
> that is fully outside the ACPI region. There actually exists hardware
> with this configuration.
Yes, I know it. However, my machine has two ACPI regions (command
buffer and response buffer) below, and the crb_fixup_cmd_size()
function couldn't check the point, "a buffer that if fully outside the
ACPI region". I will explain the exact case at the end of my email.
79a39000-79b6afff : ACPI Non-volatile Storage
79b4b000-79b4bfff : MSFT0101:00
79b4f000-79b4 : MSFT0101:00
> > When the TPM CRB regions are two or more, the crb_map_io function calls
> > crb_fixup_cmd_size twice to calculate command buffer size and response
> > buffer size. The purpose of crb_fixup_cmd_size function is to trust
> > the ACPI region information.
>
> This is not true. The driver deals with only one ACPI region ATM.
Yes, the driver deals with only one ACPI region, and it works fine in
most cases. However, two ACPI regions are in the system like above,
then crb_map_io() function calls crb_map_res() function twice.
crb_map_res() function calls devm_ioremap_resouce(). So, TPM CRB
driver handles two separated regions, command buffer and response
buffer. I will also explain in detail at the end of my email.
>
> > However, the function compares only io_res argument with start and size
> > arguments. It means the io_res argument is one of command buffer and
> > response buffer regions. It also means the other region is not calculated
> > correctly by the function because io_res argument doesn't cover all TPM
> > CRB regions.
>
> The driver gets command and response buffer metrics from the TPM2 ACPI
> table, not from the ACPI region.
I'm sorry for my mistake. I checked it.
>
> > To fix this bug, I change crb_check_resource function for storing all TPB
> > CRB regions to a list and use the list to calculate command buffer size
> > and response buffer size correctly.
>
> This cannot be categorized as a bug. It is simply as new type of hardware.
> Can you explain in detail what type of hardware are you using?
I will also explain it at the end of my email.
>
> > ---
> > drivers/char/tpm/tpm_crb.c | 50 ++
> > 1 file changed, 34 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index e59f1f91d7f3..b0e94e02e5eb 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -442,6 +442,9 @@ static int crb_check_resource(struct acpi_resource
> > *ares, void *data)
> > acpi_dev_resource_address_space(ares, )) {
> > *io_res = *res;
> > io_res->name = NULL;
> > +
> > + /* Add this TPM CRB resource to the list */
> > + return 0;
> > }
> >
> > return 1;
> > @@ -471,20 +474,30 @@ static void __iomem *crb_map_res(struct device *dev,
> > struct crb_priv *priv,
> > * region vs the registers. Trust the ACPI region. Such broken systems
> > * probably cannot send large TPM commands since the buffer will be
> > truncated.
> > */
> > -static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
> > +static u64 crb_fixup_cmd_size(struct device *dev, struct list_head
> > *resources,
> > u64 start, u64 size)
>
> With a quick spin w/o knowing the details of the hardware I'm dealing
> with it you should probably reduce the fixup function as
>
> static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
> u64 start, u64 size)
> {
> if (start + size - 1 <= io_res->end)
> return size;
>
> dev_err(dev,
> FW_BUG "ACPI region does not cover the entire
> command/response buffer. %pr vs %llx %llx\n",
> io_res, start, size);
>
> return io_res->end - start + 1;
> }
>
> Then call this inside the loop.
Thank you for your advice. I will change it
Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
> > On Mon, Aug 26, 2019 at 02:40:19AM +0900, Seunghun Han wrote: > > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got an AMD > > system which had a Ryzen Threadripper 1950X and MSI mainboard, and I had > > a problem with AMD's fTPM. My machine showed an error message below, and > > the fTPM didn't work because of it. > > > > [5.732084] tpm_crb MSFT0101:00: can't request region for resource > >[mem 0x79b4f000-0x79b4] > > [5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 > > > > When I saw the iomem areas and found two TPM CRB regions were in the ACPI > > NVS area. The iomem regions are below. > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > 79b4b000-79b4bfff : MSFT0101:00 > > 79b4f000-79b4 : MSFT0101:00 > > > > After analyzing this issue, I found out that a busy bit was set to the ACPI > > NVS area, and the current Linux kernel allowed nothing to be assigned in > > it. I also found that the kernel couldn't calculate the sizes of command > > and response buffers correctly when the TPM regions were two or more. > > > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area > > so that AMD's fTPM regions could be assigned in it. I also fixed the bug > > that did not calculate the sizes of command and response buffer correctly. > > > > Signed-off-by: Seunghun Han > > You need to split this into multiple patches e.g. if you think you've > fixed a bug, please write a patch with just the bug fix and nothing > else. > > For further information, read the section three of > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > I'd also recommend to check out the earlier discussion on ACPI NVS: > > https://lore.kernel.org/linux-integrity/bca04d5d9a3b764c9b7405bba4d4a3c035ef7...@alpmbapa12.e2k.ad.ge.com/ > > /Jarkko Thank you for your advice. I have made two separated patches on your advice. Please check these patches, https://lkml.org/lkml/2019/8/26/125 and https://lkml.org/lkml/2019/8/26/163. In my opinion, the last link you gave me had two problems with AMD's fTPM. One problem was the ACPI NVS area was set to the busy area, and TPM regions of the ACPI table were in it. Therefore, TPM CRB driver couldn't allocate command and response buffers in it because ACPI NVS area was busy. The other problem was buffer size calculation bugs. Because of it, TPM CRB driver requested larger than the size ACPI table described. So, TPM CRB driver also couldn't map command and response buffers even though the reserved area was not busy. It seems that my separated patches could handle those two problems and enable AMD's fTPM in any case. Seunghun
[PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got an AMD system which had a Ryzen Threadripper 1950X and MSI mainboard, and I had a problem with AMD's fTPM. My machine showed an error message below, and the fTPM didn't work because of it. [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource [mem 0x79b4f000-0x79b4] [ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 When I saw the e820 map and iomem, I found two fTPM regions were in the ACPI NVS area. The regions are below. 79a39000-79b6afff : ACPI Non-volatile Storage 79b4b000-79b4bfff : MSFT0101:00 79b4f000-79b4 : MSFT0101:00 After analyzing this issue, I found out that a busy bit was set to the ACPI NVS area, and the Linux kernel didn't allow the TPM CRB driver to assign CRB regions in it. To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like the reserved area so that AMD's fTPM regions could be assigned in it. Signed-off-by: Seunghun Han --- arch/x86/kernel/e820.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 7da2bcd2b8eb..0d721df8900e 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1085,11 +1085,12 @@ static bool __init do_mark_busy(enum e820_type type, struct resource *res) case E820_TYPE_RESERVED: case E820_TYPE_PRAM: case E820_TYPE_PMEM: + /* AMD's fTPM regions are in the ACPI NVS area */ + case E820_TYPE_NVS: return false; case E820_TYPE_RESERVED_KERN: case E820_TYPE_RAM: case E820_TYPE_ACPI: - case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: default: return true; -- 2.21.0
[PATCH] tpm: tpm_crb: Fix an improper buffer size calculation bug
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I found
a bug related to improper buffer size calculation in crb_fixup_cmd_size
function.
When the TPM CRB regions are two or more, the crb_map_io function calls
crb_fixup_cmd_size twice to calculate command buffer size and response
buffer size. The purpose of crb_fixup_cmd_size function is to trust
the ACPI region information.
However, the function compares only io_res argument with start and size
arguments. It means the io_res argument is one of command buffer and
response buffer regions. It also means the other region is not calculated
correctly by the function because io_res argument doesn't cover all TPM
CRB regions.
To fix this bug, I change crb_check_resource function for storing all TPB
CRB regions to a list and use the list to calculate command buffer size
and response buffer size correctly.
Signed-off-by: Seunghun Han
---
drivers/char/tpm/tpm_crb.c | 50 ++
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..b0e94e02e5eb 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -442,6 +442,9 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
acpi_dev_resource_address_space(ares, )) {
*io_res = *res;
io_res->name = NULL;
+
+ /* Add this TPM CRB resource to the list */
+ return 0;
}
return 1;
@@ -471,20 +474,30 @@ static void __iomem *crb_map_res(struct device *dev,
struct crb_priv *priv,
* region vs the registers. Trust the ACPI region. Such broken systems
* probably cannot send large TPM commands since the buffer will be truncated.
*/
-static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
+static u64 crb_fixup_cmd_size(struct device *dev, struct list_head *resources,
u64 start, u64 size)
{
- if (io_res->start > start || io_res->end < start)
- return size;
+ struct resource_entry *pos;
+ struct resource *cur_res;
+
+ /* Check all TPM CRB resources with the start and size values */
+ resource_list_for_each_entry(pos, resources) {
+ cur_res = pos->res;
+
+ if (cur_res->start > start || cur_res->end < start)
+ continue;
- if (start + size - 1 <= io_res->end)
- return size;
+ if (start + size - 1 <= cur_res->end)
+ return size;
- dev_err(dev,
- FW_BUG "ACPI region does not cover the entire command/response
buffer. %pr vs %llx %llx\n",
- io_res, start, size);
+ dev_err(dev,
+ FW_BUG "ACPI region does not cover the entire
command/response buffer. %pr vs %llx %llx\n",
+ cur_res, start, size);
+
+ return cur_res->end - start + 1;
+ }
- return io_res->end - start + 1;
+ return size;
}
static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
@@ -506,16 +519,18 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
_res);
if (ret < 0)
return ret;
- acpi_dev_free_resource_list();
if (resource_type(_res) != IORESOURCE_MEM) {
dev_err(dev, FW_BUG "TPM2 ACPI table does not define a memory
resource\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_early;
}
priv->iobase = devm_ioremap_resource(dev, _res);
- if (IS_ERR(priv->iobase))
- return PTR_ERR(priv->iobase);
+ if (IS_ERR(priv->iobase)) {
+ ret = PTR_ERR(priv->iobase);
+ goto out_early;
+ }
/* The ACPI IO region starts at the head area and continues to include
* the control area, as one nice sane region except for some older
@@ -532,7 +547,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
ret = __crb_request_locality(dev, priv, 0);
if (ret)
- return ret;
+ goto out_early;
priv->regs_t = crb_map_res(dev, priv, _res, buf->control_address,
sizeof(struct crb_regs_tail));
@@ -552,7 +567,7 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
pa_high = ioread32(>regs_t->ctrl_cmd_pa_high);
pa_low = ioread32(>regs_t->ctrl_cmd_pa_low);
cmd_pa = ((u64)pa_high << 32) | pa_low;
- cmd_size = crb_fixup_cmd_size(dev, _res, cmd_pa,
+ cmd_size = crb_fixup_cmd_size(dev, , cmd_pa,
ioread32(>regs_t->ctrl_cmd_size));
[PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got an AMD
system which had a Ryzen Threadripper 1950X and MSI mainboard, and I had
a problem with AMD's fTPM. My machine showed an error message below, and
the fTPM didn't work because of it.
[5.732084] tpm_crb MSFT0101:00: can't request region for resource
[mem 0x79b4f000-0x79b4]
[5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16
When I saw the iomem areas and found two TPM CRB regions were in the ACPI
NVS area. The iomem regions are below.
79a39000-79b6afff : ACPI Non-volatile Storage
79b4b000-79b4bfff : MSFT0101:00
79b4f000-79b4 : MSFT0101:00
After analyzing this issue, I found out that a busy bit was set to the ACPI
NVS area, and the current Linux kernel allowed nothing to be assigned in
it. I also found that the kernel couldn't calculate the sizes of command
and response buffers correctly when the TPM regions were two or more.
To support AMD's fTPM, I removed the busy bit from the ACPI NVS area
so that AMD's fTPM regions could be assigned in it. I also fixed the bug
that did not calculate the sizes of command and response buffer correctly.
Signed-off-by: Seunghun Han
---
arch/x86/kernel/e820.c | 2 +-
drivers/char/tpm/tpm_crb.c | 50 ++
2 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7da2bcd2b8eb..79a99249b46f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1085,11 +1085,11 @@ static bool __init do_mark_busy(enum e820_type type,
struct resource *res)
case E820_TYPE_RESERVED:
case E820_TYPE_PRAM:
case E820_TYPE_PMEM:
+ case E820_TYPE_NVS:
return false;
case E820_TYPE_RESERVED_KERN:
case E820_TYPE_RAM:
case E820_TYPE_ACPI:
- case E820_TYPE_NVS:
case E820_TYPE_UNUSABLE:
default:
return true;
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..d970a2289def 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -442,6 +442,9 @@ static int crb_check_resource(struct acpi_resource *ares,
void *data)
acpi_dev_resource_address_space(ares, )) {
*io_res = *res;
io_res->name = NULL;
+
+ /* Add this TPM CRB resource to the list. */
+ return 0;
}
return 1;
@@ -471,20 +474,30 @@ static void __iomem *crb_map_res(struct device *dev,
struct crb_priv *priv,
* region vs the registers. Trust the ACPI region. Such broken systems
* probably cannot send large TPM commands since the buffer will be truncated.
*/
-static u64 crb_fixup_cmd_size(struct device *dev, struct resource *io_res,
+static u64 crb_fixup_cmd_size(struct device *dev, struct list_head *resources,
u64 start, u64 size)
{
- if (io_res->start > start || io_res->end < start)
- return size;
+ struct resource_entry *pos;
+ struct resource *cur_res;
+
+ /* Check all TPM CRB resources with the start and size values. */
+ resource_list_for_each_entry(pos, resources) {
+ cur_res = pos->res;
+
+ if (cur_res->start > start || cur_res->end < start)
+ continue;
- if (start + size - 1 <= io_res->end)
- return size;
+ if (start + size - 1 <= cur_res->end)
+ return size;
- dev_err(dev,
- FW_BUG "ACPI region does not cover the entire command/response
buffer. %pr vs %llx %llx\n",
- io_res, start, size);
+ dev_err(dev,
+ FW_BUG "ACPI region does not cover the entire
command/response buffer. %pr vs %llx %llx\n",
+ cur_res, start, size);
+
+ return cur_res->end - start + 1;
+ }
- return io_res->end - start + 1;
+ return size;
}
static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
@@ -506,16 +519,18 @@ static int crb_map_io(struct acpi_device *device, struct
crb_priv *priv,
_res);
if (ret < 0)
return ret;
- acpi_dev_free_resource_list();
if (resource_type(_res) != IORESOURCE_MEM) {
dev_err(dev, FW_BUG "TPM2 ACPI table does not define a memory
resource\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_early;
}
priv->iobase = devm_ioremap_resource(dev, _res);
- if (IS_ERR(priv->iobase))
- return PTR_ERR(priv->iobase);
+ if (IS_ERR(priv->iobase)) {
+ ret = PTR_ERR(priv->iobase);
+ goto out_early;
+ }
/* The ACPI IO region start
[tip:ras/urgent] x86/MCE: Serialize sysfs changes
Commit-ID: b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Gitweb: https://git.kernel.org/tip/b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 6 Mar 2018 15:21:43 +0100
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Thu, 8 Mar 2018 15:36:27 +0100
x86/MCE: Serialize sysfs changes
The check_interval file in
/sys/devices/system/machinecheck/machinecheck
directory is a global timer value for MCE polling. If it is changed by one
CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
mce_timer variable.
If more than one CPU writes a specific value to the check_interval file
concurrently, mce_timer is not protected from such concurrent accesses and
all kinds of explosions happen. Since only root can write to those sysfs
variables, the issue is not a big deal security-wise.
However, concurrent writes to these configuration variables is void of
reason so the proper thing to do is to serialize the access with a mutex.
Boris:
- Make store_int_with_restart() use device_store_ulong() to filter out
negative intervals
- Limit min interval to 1 second
- Correct locking
- Massage commit message
Signed-off-by: Seunghun Han <kkama...@gmail.com>
Signed-off-by: Borislav Petkov <b...@suse.de>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-edac <linux-e...@vger.kernel.org>
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180302202706.9434-1-kkama...@gmail.com
---
arch/x86/kernel/cpu/mcheck/mce.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b3323cab9139..466f47301334 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -56,6 +56,9 @@
static DEFINE_MUTEX(mce_log_mutex);
+/* sysfs synchronization */
+static DEFINE_MUTEX(mce_sysfs_mutex);
+
#define CREATE_TRACE_POINTS
#include
@@ -2088,6 +2091,7 @@ static ssize_t set_ignore_ce(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.ignore_ce ^ !!new) {
if (new) {
/* disable ce features */
@@ -2100,6 +2104,8 @@ static ssize_t set_ignore_ce(struct device *s,
on_each_cpu(mce_enable_ce, (void *)1, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2112,6 +2118,7 @@ static ssize_t set_cmci_disabled(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.cmci_disabled ^ !!new) {
if (new) {
/* disable cmci */
@@ -2123,6 +2130,8 @@ static ssize_t set_cmci_disabled(struct device *s,
on_each_cpu(mce_enable_ce, NULL, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2130,8 +2139,19 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
- ssize_t ret = device_store_int(s, attr, buf, size);
+ unsigned long old_check_interval = check_interval;
+ ssize_t ret = device_store_ulong(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+
+ if (check_interval < 1)
+ check_interval = 1;
+
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
+
return ret;
}
[tip:ras/urgent] x86/MCE: Serialize sysfs changes
Commit-ID: b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Gitweb: https://git.kernel.org/tip/b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Author: Seunghun Han
AuthorDate: Tue, 6 Mar 2018 15:21:43 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 8 Mar 2018 15:36:27 +0100
x86/MCE: Serialize sysfs changes
The check_interval file in
/sys/devices/system/machinecheck/machinecheck
directory is a global timer value for MCE polling. If it is changed by one
CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
mce_timer variable.
If more than one CPU writes a specific value to the check_interval file
concurrently, mce_timer is not protected from such concurrent accesses and
all kinds of explosions happen. Since only root can write to those sysfs
variables, the issue is not a big deal security-wise.
However, concurrent writes to these configuration variables is void of
reason so the proper thing to do is to serialize the access with a mutex.
Boris:
- Make store_int_with_restart() use device_store_ulong() to filter out
negative intervals
- Limit min interval to 1 second
- Correct locking
- Massage commit message
Signed-off-by: Seunghun Han
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Tony Luck
Cc: linux-edac
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180302202706.9434-1-kkama...@gmail.com
---
arch/x86/kernel/cpu/mcheck/mce.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b3323cab9139..466f47301334 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -56,6 +56,9 @@
static DEFINE_MUTEX(mce_log_mutex);
+/* sysfs synchronization */
+static DEFINE_MUTEX(mce_sysfs_mutex);
+
#define CREATE_TRACE_POINTS
#include
@@ -2088,6 +2091,7 @@ static ssize_t set_ignore_ce(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.ignore_ce ^ !!new) {
if (new) {
/* disable ce features */
@@ -2100,6 +2104,8 @@ static ssize_t set_ignore_ce(struct device *s,
on_each_cpu(mce_enable_ce, (void *)1, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2112,6 +2118,7 @@ static ssize_t set_cmci_disabled(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.cmci_disabled ^ !!new) {
if (new) {
/* disable cmci */
@@ -2123,6 +2130,8 @@ static ssize_t set_cmci_disabled(struct device *s,
on_each_cpu(mce_enable_ce, NULL, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2130,8 +2139,19 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
- ssize_t ret = device_store_int(s, attr, buf, size);
+ unsigned long old_check_interval = check_interval;
+ ssize_t ret = device_store_ulong(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+
+ if (check_interval < 1)
+ check_interval = 1;
+
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
+
return ret;
}
[tip:x86/pti] x86/pti: Fix a comment typo
Commit-ID: c5b679f5c9e3851ee118d95961def374bb3b4ce6
Gitweb: https://git.kernel.org/tip/c5b679f5c9e3851ee118d95961def374bb3b4ce6
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Wed, 7 Mar 2018 13:32:15 +0900
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Thu, 8 Mar 2018 12:33:21 +0100
x86/pti: Fix a comment typo
s/visinble/visible/
Signed-off-by: Seunghun Han <kkama...@gmail.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Link:
https://lkml.kernel.org/r/1520397135-132809-1-git-send-email-kkama...@gmail.com
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f165489b..631507f0c198 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7 @@ static void __init pti_clone_user_shared(void)
}
/*
- * Clone the ESPFIX P4D into the user space visinble page table
+ * Clone the ESPFIX P4D into the user space visible page table
*/
static void __init pti_setup_espfix64(void)
{
[tip:x86/pti] x86/pti: Fix a comment typo
Commit-ID: c5b679f5c9e3851ee118d95961def374bb3b4ce6
Gitweb: https://git.kernel.org/tip/c5b679f5c9e3851ee118d95961def374bb3b4ce6
Author: Seunghun Han
AuthorDate: Wed, 7 Mar 2018 13:32:15 +0900
Committer: Thomas Gleixner
CommitDate: Thu, 8 Mar 2018 12:33:21 +0100
x86/pti: Fix a comment typo
s/visinble/visible/
Signed-off-by: Seunghun Han
Signed-off-by: Thomas Gleixner
Link:
https://lkml.kernel.org/r/1520397135-132809-1-git-send-email-kkama...@gmail.com
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f165489b..631507f0c198 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7 @@ static void __init pti_clone_user_shared(void)
}
/*
- * Clone the ESPFIX P4D into the user space visinble page table
+ * Clone the ESPFIX P4D into the user space visible page table
*/
static void __init pti_setup_espfix64(void)
{
[PATCH] x86: mm: typo: fix a typo in a comment line
Fix a typo in a comment line of pti.c.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f16..631507f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7 @@ static void __init pti_clone_user_shared(void)
}
/*
- * Clone the ESPFIX P4D into the user space visinble page table
+ * Clone the ESPFIX P4D into the user space visible page table
*/
static void __init pti_setup_espfix64(void)
{
--
2.1.4
[PATCH] x86: mm: typo: fix a typo in a comment line
Fix a typo in a comment line of pti.c.
Signed-off-by: Seunghun Han
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f16..631507f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7 @@ static void __init pti_clone_user_shared(void)
}
/*
- * Clone the ESPFIX P4D into the user space visinble page table
+ * Clone the ESPFIX P4D into the user space visible page table
*/
static void __init pti_setup_espfix64(void)
{
--
2.1.4
[PATCH V3] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function in store_int_with_restart() function
and broadcasts the event to other CPUs to delete and restart MCE polling
timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang. Other functions
such as set_ignore_ce(), set_cmci_disabled(), and mce_enable_ce() also
have synchronization problems.
It could be a security problem because the attacker could make kernel panic
by writing a value to the check_interval file in userspace, and it could be
used for Denial-of-Service (DoS) attack.
To fix this problem, I added a mce_sysfs_mutex to serialize requests for
timer and sysfs functions.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
Changes since v2: add a mutex to sysfs functions according to review
result.
Changes since v1: add mce_sysfs_mutex according to review result.
arch/x86/kernel/cpu/mcheck/mce.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 706584681a4c..243f46a40efb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -55,6 +55,7 @@
#include "mce-internal.h"
static DEFINE_MUTEX(mce_log_mutex);
+static DEFINE_MUTEX(mce_sysfs_mutex);
#define CREATE_TRACE_POINTS
#include
@@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ mutex_lock(_sysfs_mutex);
__mcheck_cpu_init_timer();
+ mutex_unlock(_sysfs_mutex);
+ }
}
static struct bus_type mce_subsys = {
@@ -2090,6 +2094,7 @@ static ssize_t set_ignore_ce(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.ignore_ce ^ !!new) {
if (new) {
/* disable ce features */
@@ -2102,6 +2107,8 @@ static ssize_t set_ignore_ce(struct device *s,
on_each_cpu(mce_enable_ce, (void *)1, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2114,6 +2121,7 @@ static ssize_t set_cmci_disabled(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.cmci_disabled ^ !!new) {
if (new) {
/* disable cmci */
@@ -2125,6 +2133,8 @@ static ssize_t set_cmci_disabled(struct device *s,
on_each_cpu(mce_enable_ce, NULL, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2132,8 +2142,16 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
+ unsigned long old_check_interval = check_interval;
ssize_t ret = device_store_int(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
+
return ret;
}
--
2.16.2
[PATCH V3] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function in store_int_with_restart() function
and broadcasts the event to other CPUs to delete and restart MCE polling
timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang. Other functions
such as set_ignore_ce(), set_cmci_disabled(), and mce_enable_ce() also
have synchronization problems.
It could be a security problem because the attacker could make kernel panic
by writing a value to the check_interval file in userspace, and it could be
used for Denial-of-Service (DoS) attack.
To fix this problem, I added a mce_sysfs_mutex to serialize requests for
timer and sysfs functions.
Signed-off-by: Seunghun Han
---
Changes since v2: add a mutex to sysfs functions according to review
result.
Changes since v1: add mce_sysfs_mutex according to review result.
arch/x86/kernel/cpu/mcheck/mce.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 706584681a4c..243f46a40efb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -55,6 +55,7 @@
#include "mce-internal.h"
static DEFINE_MUTEX(mce_log_mutex);
+static DEFINE_MUTEX(mce_sysfs_mutex);
#define CREATE_TRACE_POINTS
#include
@@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ mutex_lock(_sysfs_mutex);
__mcheck_cpu_init_timer();
+ mutex_unlock(_sysfs_mutex);
+ }
}
static struct bus_type mce_subsys = {
@@ -2090,6 +2094,7 @@ static ssize_t set_ignore_ce(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.ignore_ce ^ !!new) {
if (new) {
/* disable ce features */
@@ -2102,6 +2107,8 @@ static ssize_t set_ignore_ce(struct device *s,
on_each_cpu(mce_enable_ce, (void *)1, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2114,6 +2121,7 @@ static ssize_t set_cmci_disabled(struct device *s,
if (kstrtou64(buf, 0, ) < 0)
return -EINVAL;
+ mutex_lock(_sysfs_mutex);
if (mca_cfg.cmci_disabled ^ !!new) {
if (new) {
/* disable cmci */
@@ -2125,6 +2133,8 @@ static ssize_t set_cmci_disabled(struct device *s,
on_each_cpu(mce_enable_ce, NULL, 1);
}
}
+ mutex_unlock(_sysfs_mutex);
+
return size;
}
@@ -2132,8 +2142,16 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
+ unsigned long old_check_interval = check_interval;
ssize_t ret = device_store_int(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
+
return ret;
}
--
2.16.2
Re: [PATCH V2] x86: mce: fix kernel panic when check_interval is changed
Hi, Borislav.
Thank you for your good advice.
According to your advice, I will make and send PATCH v3.
Best regards.
Seunghun.
2018-03-02 21:14 GMT+09:00 Borislav Petkov <b...@alien8.de>:
> On Thu, Mar 01, 2018 at 05:31:31AM +0900, Seunghun Han wrote:
>> Changes since v1: add mce_sysfs_mutex according to review result.
>
> Ok, we're getting there.
>
>> arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
>> b/arch/x86/kernel/cpu/mcheck/mce.c
>> index 706584681a4c..bee0795a3b8c 100644
>> --- a/arch/x86/kernel/cpu/mcheck/mce.c
>> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
>> @@ -55,6 +55,7 @@
>> #include "mce-internal.h"
>>
>> static DEFINE_MUTEX(mce_log_mutex);
>> +static DEFINE_MUTEX(mce_sysfs_mutex);
>>
>> #define CREATE_TRACE_POINTS
>> #include
>> @@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
>> return;
>> cmci_reenable();
>> cmci_recheck();
>> - if (all)
>> + if (all) {
>> + mutex_lock(_sysfs_mutex);
>> __mcheck_cpu_init_timer();
>> + mutex_unlock(_sysfs_mutex);
>> + }
>
> Instead of chasing all the places which need to grab the mutex, I was
> thinking of grabbing it in all those functions which modify MCA behavior
> non-trivially from sysfs. And those are:
>
> store_int_with_restart()
> set_ignore_ce()
> set_cmci_disabled()
>
> And you've done that already for store_int_with_restart() and I think
> doing the same in the other two will address the issue nicely and
> in the simplest way possible.
>
> All those sysfs operations should be synchronized anyway. Please reflect
> that in your commit message too.
>
> The aspect about DOS is not really important because you need to be root
> to write those so if you have root, there are gazillion ways to shoot
> yourself in the foot already.
>
>> static struct bus_type mce_subsys = {
>> @@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device
>> *s,
>> struct device_attribute *attr,
>> const char *buf, size_t size)
>> {
>> + unsigned long old_check_interval = check_interval;
>> ssize_t ret = device_store_int(s, attr, buf, size);
>> +
>> + if (check_interval == old_check_interval)
>> + return ret;
>
> < newline here.
>
>> + mutex_lock(_sysfs_mutex);
>> mce_restart();
>> + mutex_unlock(_sysfs_mutex);
>
> < newline here.
>
>> return ret;
>> }
>>
>> --
>> 2.16.2
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH V2] x86: mce: fix kernel panic when check_interval is changed
Hi, Borislav.
Thank you for your good advice.
According to your advice, I will make and send PATCH v3.
Best regards.
Seunghun.
2018-03-02 21:14 GMT+09:00 Borislav Petkov :
> On Thu, Mar 01, 2018 at 05:31:31AM +0900, Seunghun Han wrote:
>> Changes since v1: add mce_sysfs_mutex according to review result.
>
> Ok, we're getting there.
>
>> arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
>> b/arch/x86/kernel/cpu/mcheck/mce.c
>> index 706584681a4c..bee0795a3b8c 100644
>> --- a/arch/x86/kernel/cpu/mcheck/mce.c
>> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
>> @@ -55,6 +55,7 @@
>> #include "mce-internal.h"
>>
>> static DEFINE_MUTEX(mce_log_mutex);
>> +static DEFINE_MUTEX(mce_sysfs_mutex);
>>
>> #define CREATE_TRACE_POINTS
>> #include
>> @@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
>> return;
>> cmci_reenable();
>> cmci_recheck();
>> - if (all)
>> + if (all) {
>> + mutex_lock(_sysfs_mutex);
>> __mcheck_cpu_init_timer();
>> + mutex_unlock(_sysfs_mutex);
>> + }
>
> Instead of chasing all the places which need to grab the mutex, I was
> thinking of grabbing it in all those functions which modify MCA behavior
> non-trivially from sysfs. And those are:
>
> store_int_with_restart()
> set_ignore_ce()
> set_cmci_disabled()
>
> And you've done that already for store_int_with_restart() and I think
> doing the same in the other two will address the issue nicely and
> in the simplest way possible.
>
> All those sysfs operations should be synchronized anyway. Please reflect
> that in your commit message too.
>
> The aspect about DOS is not really important because you need to be root
> to write those so if you have root, there are gazillion ways to shoot
> yourself in the foot already.
>
>> static struct bus_type mce_subsys = {
>> @@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device
>> *s,
>> struct device_attribute *attr,
>> const char *buf, size_t size)
>> {
>> + unsigned long old_check_interval = check_interval;
>> ssize_t ret = device_store_int(s, attr, buf, size);
>> +
>> + if (check_interval == old_check_interval)
>> + return ret;
>
> < newline here.
>
>> + mutex_lock(_sysfs_mutex);
>> mce_restart();
>> + mutex_unlock(_sysfs_mutex);
>
> < newline here.
>
>> return ret;
>> }
>>
>> --
>> 2.16.2
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH V2] x86: mce: fix kernel panic when check_interval is changed
Hi, Borislav.
I made new patch according to your advice.
The patch is here, https://lkml.org/lkml/2018/2/28/1230.
If you have any advice about it, please let me know.
Best regards.
Seunghun.
2018-03-01 5:31 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> I am Seunghun Han and a senior security researcher at National Security
> Research Institute of South Korea.
>
> I found a security issue which can make kernel panic in userspace. After
> analyzing the issue carefully, I found that MCE driver in the kernel has a
> problem which can be occurred in SMP environment.
>
> The check_interval file in
> /sys/devices/system/machinecheck/machinecheck directory is a
> global timer value for MCE polling. If it is changed by one CPU, MCE driver
> in kernel calls mce_restart() function and broadcasts the event to other
> CPUs to delete and restart MCE polling timer.
>
> The __mcheck_cpu_init_timer() function which is called by mce_restart()
> function initializes the mce_timer variable, and the "lock" in mce_timer is
> also reinitialized. If more than one CPU write a specific value to
> check_interval file concurrently, one can initialize the "lock" in mce_timer
> while the others are handling "lock" in mce_timer. This problem causes some
> synchronization errors such as kernel panic and kernel hang.
>
> It is a security problem because the attacker can make kernel panic by
> writing a value to the check_interval file in userspace, and it can be used
> for Denial-of-Service (DoS) attack.
>
> To fix this problem, I added a mce_sysfs_mutex to serialize requests.
>
> Signed-off-by: Seunghun Han <kkama...@gmail.com>
> ---
> Changes since v1: add mce_sysfs_mutex according to review result.
>
> arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 706584681a4c..bee0795a3b8c 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -55,6 +55,7 @@
> #include "mce-internal.h"
>
> static DEFINE_MUTEX(mce_log_mutex);
> +static DEFINE_MUTEX(mce_sysfs_mutex);
>
> #define CREATE_TRACE_POINTS
> #include
> @@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
> return;
> cmci_reenable();
> cmci_recheck();
> - if (all)
> + if (all) {
> + mutex_lock(_sysfs_mutex);
> __mcheck_cpu_init_timer();
> + mutex_unlock(_sysfs_mutex);
> + }
> }
>
> static struct bus_type mce_subsys = {
> @@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device *s,
> struct device_attribute *attr,
> const char *buf, size_t size)
> {
> + unsigned long old_check_interval = check_interval;
> ssize_t ret = device_store_int(s, attr, buf, size);
> +
> + if (check_interval == old_check_interval)
> + return ret;
> + mutex_lock(_sysfs_mutex);
> mce_restart();
> + mutex_unlock(_sysfs_mutex);
> return ret;
> }
>
> --
> 2.16.2
>
Re: [PATCH V2] x86: mce: fix kernel panic when check_interval is changed
Hi, Borislav.
I made new patch according to your advice.
The patch is here, https://lkml.org/lkml/2018/2/28/1230.
If you have any advice about it, please let me know.
Best regards.
Seunghun.
2018-03-01 5:31 GMT+09:00 Seunghun Han :
> I am Seunghun Han and a senior security researcher at National Security
> Research Institute of South Korea.
>
> I found a security issue which can make kernel panic in userspace. After
> analyzing the issue carefully, I found that MCE driver in the kernel has a
> problem which can be occurred in SMP environment.
>
> The check_interval file in
> /sys/devices/system/machinecheck/machinecheck directory is a
> global timer value for MCE polling. If it is changed by one CPU, MCE driver
> in kernel calls mce_restart() function and broadcasts the event to other
> CPUs to delete and restart MCE polling timer.
>
> The __mcheck_cpu_init_timer() function which is called by mce_restart()
> function initializes the mce_timer variable, and the "lock" in mce_timer is
> also reinitialized. If more than one CPU write a specific value to
> check_interval file concurrently, one can initialize the "lock" in mce_timer
> while the others are handling "lock" in mce_timer. This problem causes some
> synchronization errors such as kernel panic and kernel hang.
>
> It is a security problem because the attacker can make kernel panic by
> writing a value to the check_interval file in userspace, and it can be used
> for Denial-of-Service (DoS) attack.
>
> To fix this problem, I added a mce_sysfs_mutex to serialize requests.
>
> Signed-off-by: Seunghun Han
> ---
> Changes since v1: add mce_sysfs_mutex according to review result.
>
> arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 706584681a4c..bee0795a3b8c 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -55,6 +55,7 @@
> #include "mce-internal.h"
>
> static DEFINE_MUTEX(mce_log_mutex);
> +static DEFINE_MUTEX(mce_sysfs_mutex);
>
> #define CREATE_TRACE_POINTS
> #include
> @@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
> return;
> cmci_reenable();
> cmci_recheck();
> - if (all)
> + if (all) {
> + mutex_lock(_sysfs_mutex);
> __mcheck_cpu_init_timer();
> + mutex_unlock(_sysfs_mutex);
> + }
> }
>
> static struct bus_type mce_subsys = {
> @@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device *s,
> struct device_attribute *attr,
> const char *buf, size_t size)
> {
> + unsigned long old_check_interval = check_interval;
> ssize_t ret = device_store_int(s, attr, buf, size);
> +
> + if (check_interval == old_check_interval)
> + return ret;
> + mutex_lock(_sysfs_mutex);
> mce_restart();
> + mutex_unlock(_sysfs_mutex);
> return ret;
> }
>
> --
> 2.16.2
>
[PATCH V2] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function and broadcasts the event to other
CPUs to delete and restart MCE polling timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang.
It is a security problem because the attacker can make kernel panic by
writing a value to the check_interval file in userspace, and it can be used
for Denial-of-Service (DoS) attack.
To fix this problem, I added a mce_sysfs_mutex to serialize requests.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
Changes since v1: add mce_sysfs_mutex according to review result.
arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 706584681a4c..bee0795a3b8c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -55,6 +55,7 @@
#include "mce-internal.h"
static DEFINE_MUTEX(mce_log_mutex);
+static DEFINE_MUTEX(mce_sysfs_mutex);
#define CREATE_TRACE_POINTS
#include
@@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ mutex_lock(_sysfs_mutex);
__mcheck_cpu_init_timer();
+ mutex_unlock(_sysfs_mutex);
+ }
}
static struct bus_type mce_subsys = {
@@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
+ unsigned long old_check_interval = check_interval;
ssize_t ret = device_store_int(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
return ret;
}
--
2.16.2
[PATCH V2] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function and broadcasts the event to other
CPUs to delete and restart MCE polling timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang.
It is a security problem because the attacker can make kernel panic by
writing a value to the check_interval file in userspace, and it can be used
for Denial-of-Service (DoS) attack.
To fix this problem, I added a mce_sysfs_mutex to serialize requests.
Signed-off-by: Seunghun Han
---
Changes since v1: add mce_sysfs_mutex according to review result.
arch/x86/kernel/cpu/mcheck/mce.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 706584681a4c..bee0795a3b8c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -55,6 +55,7 @@
#include "mce-internal.h"
static DEFINE_MUTEX(mce_log_mutex);
+static DEFINE_MUTEX(mce_sysfs_mutex);
#define CREATE_TRACE_POINTS
#include
@@ -2045,8 +2046,11 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ mutex_lock(_sysfs_mutex);
__mcheck_cpu_init_timer();
+ mutex_unlock(_sysfs_mutex);
+ }
}
static struct bus_type mce_subsys = {
@@ -2132,8 +2136,14 @@ static ssize_t store_int_with_restart(struct device *s,
struct device_attribute *attr,
const char *buf, size_t size)
{
+ unsigned long old_check_interval = check_interval;
ssize_t ret = device_store_int(s, attr, buf, size);
+
+ if (check_interval == old_check_interval)
+ return ret;
+ mutex_lock(_sysfs_mutex);
mce_restart();
+ mutex_unlock(_sysfs_mutex);
return ret;
}
--
2.16.2
Re: [PATCH] x86: mce: fix kernel panic when check_interval is changed
Hello, Borislav. 2018-02-28 18:32 GMT+09:00 Borislav Petkov <b...@alien8.de>: > On Mon, Feb 26, 2018 at 05:05:04AM +0900, Seunghun Han wrote: >> >> It is a critical security problem because the attacker can make kernel >> >> panic >> >> by writing a value to the check_interval file in userspace, and it can be >> >> used for Denial-of-Service (DoS) attack. >> > >> > As only root can write to that file, it's not that critical of an issue, >> > but yes, this is a problem. Nice find and fix. > > This is still the wrong fix. You need to: > > 1. check the old value of check_interval in store_int_with_restart() and > exit early if it is the same. > > 2. have mce_restart() grab a newly defined mutex, say, mce_sysfs_mutex > or so, which synchronizes all CPUs so that their timers get deleted and > reinitialized in the proper order. Thank you for your advice. I will change my patch like that and send it again. Best regard. Seunghun. > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] x86: mce: fix kernel panic when check_interval is changed
Hello, Borislav. 2018-02-28 18:32 GMT+09:00 Borislav Petkov : > On Mon, Feb 26, 2018 at 05:05:04AM +0900, Seunghun Han wrote: >> >> It is a critical security problem because the attacker can make kernel >> >> panic >> >> by writing a value to the check_interval file in userspace, and it can be >> >> used for Denial-of-Service (DoS) attack. >> > >> > As only root can write to that file, it's not that critical of an issue, >> > but yes, this is a problem. Nice find and fix. > > This is still the wrong fix. You need to: > > 1. check the old value of check_interval in store_int_with_restart() and > exit early if it is the same. > > 2. have mce_restart() grab a newly defined mutex, say, mce_sysfs_mutex > or so, which synchronizes all CPUs so that their timers get deleted and > reinitialized in the proper order. Thank you for your advice. I will change my patch like that and send it again. Best regard. Seunghun. > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] x86: mce: fix kernel panic when check_interval is changed
Hello, Greg. 2018-02-23 19:52 GMT+09:00 Greg Kroah-Hartman <gre...@linuxfoundation.org>: > On Fri, Feb 23, 2018 at 07:13:50PM +0900, Seunghun Han wrote: >> I am Seunghun Han and a senior security researcher at National Security >> Research Institute of South Korea. >> >> I found a critical security issue which can make kernel panic in userspace. >> After analyzing the issue carefully, I found that MCE driver in the kernel >> has a problem which can be occurred in SMP environment. >> >> The check_interval file in >> /sys/devices/system/machinecheck/machinecheck directory is a >> global timer value for MCE polling. If it is changed by one CPU, MCE driver >> in kernel calls mce_restart() function and broadcasts the event to other >> CPUs to delete and restart MCE polling timer. >> >> The __mcheck_cpu_init_timer() function which is called by mce_restart() >> function initializes the mce_timer variable, and the "lock" in mce_timer is >> also reinitialized. If more than one CPU write a specific value to >> check_interval file concurrently, one can initialize the "lock" in mce_timer >> while the others are handling "lock" in mce_timer. This problem causes some >> synchronization errors such as kernel panic and kernel hang. >> >> It is a critical security problem because the attacker can make kernel panic >> by writing a value to the check_interval file in userspace, and it can be >> used for Denial-of-Service (DoS) attack. > > As only root can write to that file, it's not that critical of an issue, > but yes, this is a problem. Nice find and fix. I agree with your opinion. Thank you for your advice. Best regards. Seunghun. >> >> To fix this problem, I changed the __mcheck_cpu_init_timer() function to >> reuse mce_timer instead of initializing it. The purpose of the function is >> to restart the timer and it can be archived by calling >> >> Signed-off-by: Seunghun Han <kkama...@gmail.com> > > Cc: stable <sta...@vger.kernel.org> > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> >
Re: [PATCH] x86: mce: fix kernel panic when check_interval is changed
Hello, Greg. 2018-02-23 19:52 GMT+09:00 Greg Kroah-Hartman : > On Fri, Feb 23, 2018 at 07:13:50PM +0900, Seunghun Han wrote: >> I am Seunghun Han and a senior security researcher at National Security >> Research Institute of South Korea. >> >> I found a critical security issue which can make kernel panic in userspace. >> After analyzing the issue carefully, I found that MCE driver in the kernel >> has a problem which can be occurred in SMP environment. >> >> The check_interval file in >> /sys/devices/system/machinecheck/machinecheck directory is a >> global timer value for MCE polling. If it is changed by one CPU, MCE driver >> in kernel calls mce_restart() function and broadcasts the event to other >> CPUs to delete and restart MCE polling timer. >> >> The __mcheck_cpu_init_timer() function which is called by mce_restart() >> function initializes the mce_timer variable, and the "lock" in mce_timer is >> also reinitialized. If more than one CPU write a specific value to >> check_interval file concurrently, one can initialize the "lock" in mce_timer >> while the others are handling "lock" in mce_timer. This problem causes some >> synchronization errors such as kernel panic and kernel hang. >> >> It is a critical security problem because the attacker can make kernel panic >> by writing a value to the check_interval file in userspace, and it can be >> used for Denial-of-Service (DoS) attack. > > As only root can write to that file, it's not that critical of an issue, > but yes, this is a problem. Nice find and fix. I agree with your opinion. Thank you for your advice. Best regards. Seunghun. >> >> To fix this problem, I changed the __mcheck_cpu_init_timer() function to >> reuse mce_timer instead of initializing it. The purpose of the function is >> to restart the timer and it can be archived by calling >> >> Signed-off-by: Seunghun Han > > Cc: stable > Acked-by: Greg Kroah-Hartman >
[PATCH] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a critical security issue which can make kernel panic in userspace.
After analyzing the issue carefully, I found that MCE driver in the kernel
has a problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function and broadcasts the event to other
CPUs to delete and restart MCE polling timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang.
It is a critical security problem because the attacker can make kernel panic
by writing a value to the check_interval file in userspace, and it can be
used for Denial-of-Service (DoS) attack.
To fix this problem, I changed the __mcheck_cpu_init_timer() function to
reuse mce_timer instead of initializing it. The purpose of the function is
to restart the timer and it can be archived by calling
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
arch/x86/kernel/cpu/mcheck/mce.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3d8c573a9a27..d72f2f74f4d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1771,7 +1771,6 @@ static void __mcheck_cpu_init_timer(void)
{
struct timer_list *t = this_cpu_ptr(_timer);
- timer_setup(t, mce_timer_fn, TIMER_PINNED);
mce_start_timer(t);
}
@@ -2029,8 +2028,10 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ del_timer_sync(this_cpu_ptr(_timer));
__mcheck_cpu_init_timer();
+ }
}
static struct bus_type mce_subsys = {
--
2.11.0
[PATCH] x86: mce: fix kernel panic when check_interval is changed
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a critical security issue which can make kernel panic in userspace.
After analyzing the issue carefully, I found that MCE driver in the kernel
has a problem which can be occurred in SMP environment.
The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function and broadcasts the event to other
CPUs to delete and restart MCE polling timer.
The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang.
It is a critical security problem because the attacker can make kernel panic
by writing a value to the check_interval file in userspace, and it can be
used for Denial-of-Service (DoS) attack.
To fix this problem, I changed the __mcheck_cpu_init_timer() function to
reuse mce_timer instead of initializing it. The purpose of the function is
to restart the timer and it can be archived by calling
Signed-off-by: Seunghun Han
---
arch/x86/kernel/cpu/mcheck/mce.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3d8c573a9a27..d72f2f74f4d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1771,7 +1771,6 @@ static void __mcheck_cpu_init_timer(void)
{
struct timer_list *t = this_cpu_ptr(_timer);
- timer_setup(t, mce_timer_fn, TIMER_PINNED);
mce_start_timer(t);
}
@@ -2029,8 +2028,10 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
- if (all)
+ if (all) {
+ del_timer_sync(this_cpu_ptr(_timer));
__mcheck_cpu_init_timer();
+ }
}
static struct bus_type mce_subsys = {
--
2.11.0
[PATCH] acpi: acpica: fix acpi operand cache leak in dsutils.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/dsutils.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c
index 0dabd9b..2c8a060 100644
--- a/drivers/acpi/acpica/dsutils.c
+++ b/drivers/acpi/acpica/dsutils.c
@@ -705,6 +705,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS];
u32 arg_count = 0;
u32 index = walk_state->num_operands;
+ u32 prev_num_operands = walk_state->num_operands;
+ u32 new_num_operands;
u32 i;
ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg);
@@ -733,6 +735,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
/* Create the interpreter arguments, in reverse order */
+ new_num_operands = index;
index--;
for (i = 0; i < arg_count; i++) {
arg = arguments[index];
@@ -757,7 +760,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
* pop everything off of the operand stack and delete those
* objects
*/
- acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state);
+ walk_state->num_operands = i;
+ acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state);
+
+ /* Restore operand count */
+ walk_state->num_operands = prev_num_operands;
ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index));
return_ACPI_STATUS(status);
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak in dsutils.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/dsutils.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c
index 0dabd9b..2c8a060 100644
--- a/drivers/acpi/acpica/dsutils.c
+++ b/drivers/acpi/acpica/dsutils.c
@@ -705,6 +705,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS];
u32 arg_count = 0;
u32 index = walk_state->num_operands;
+ u32 prev_num_operands = walk_state->num_operands;
+ u32 new_num_operands;
u32 i;
ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg);
@@ -733,6 +735,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
/* Create the interpreter arguments, in reverse order */
+ new_num_operands = index;
index--;
for (i = 0; i < arg_count; i++) {
arg = arguments[index];
@@ -757,7 +760,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
* pop everything off of the operand stack and delete those
* objects
*/
- acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state);
+ walk_state->num_operands = i;
+ acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state);
+
+ /* Restore operand count */
+ walk_state->num_operands = prev_num_operands;
ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index));
return_ACPI_STATUS(status);
--
2.1.4
[tip:x86/urgent] x86/ioapic: Pass the correct data to unmask_ioapic_irq()
Commit-ID: e708e35ba6d89ff785b225cd07dcccab04fa954a
Gitweb: http://git.kernel.org/tip/e708e35ba6d89ff785b225cd07dcccab04fa954a
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 20 Jul 2017 10:28:10 +0200
x86/ioapic: Pass the correct data to unmask_ioapic_irq()
One of the rarely executed code pathes in check_timer() calls
unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
interrupt 0. irq_get_chip_data(0) returns NULL, so the following
dereference in unmask_ioapic_irq() causes a kernel panic.
The issue went unnoticed in the first place because irq_get_chip_data()
returns a void pointer so the compiler cannot do a type check on the
argument. The code path was added for machines with broken configuration,
but it seems that those machines are either not running current kernels or
simply do not longer exist.
Hand in irq_get_irq_data(0) as argument which provides the correct data.
[ tglx: Rewrote changelog ]
Fixes: 4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
Signed-off-by: Seunghun Han <kkama...@gmail.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkama...@gmail.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
arch/x86/kernel/apic/io_apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b4f5f73..237e9c2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2093,7 +2093,7 @@ static inline void __init check_timer(void)
int idx;
idx = find_irq_entry(apic1, pin1, mp_INT);
if (idx != -1 && irq_trigger(idx))
- unmask_ioapic_irq(irq_get_chip_data(0));
+ unmask_ioapic_irq(irq_get_irq_data(0));
}
irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
[tip:x86/urgent] x86/ioapic: Pass the correct data to unmask_ioapic_irq()
Commit-ID: e708e35ba6d89ff785b225cd07dcccab04fa954a
Gitweb: http://git.kernel.org/tip/e708e35ba6d89ff785b225cd07dcccab04fa954a
Author: Seunghun Han
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Ingo Molnar
CommitDate: Thu, 20 Jul 2017 10:28:10 +0200
x86/ioapic: Pass the correct data to unmask_ioapic_irq()
One of the rarely executed code pathes in check_timer() calls
unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
interrupt 0. irq_get_chip_data(0) returns NULL, so the following
dereference in unmask_ioapic_irq() causes a kernel panic.
The issue went unnoticed in the first place because irq_get_chip_data()
returns a void pointer so the compiler cannot do a type check on the
argument. The code path was added for machines with broken configuration,
but it seems that those machines are either not running current kernels or
simply do not longer exist.
Hand in irq_get_irq_data(0) as argument which provides the correct data.
[ tglx: Rewrote changelog ]
Fixes: 4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
Signed-off-by: Seunghun Han
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkama...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/io_apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b4f5f73..237e9c2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2093,7 +2093,7 @@ static inline void __init check_timer(void)
int idx;
idx = find_irq_entry(apic1, pin1, mp_INT);
if (idx != -1 && irq_trigger(idx))
- unmask_ioapic_irq(irq_get_chip_data(0));
+ unmask_ioapic_irq(irq_get_irq_data(0));
}
irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
[PATCH V2] acpi: acpica: fix acpi operand cache leak in dswstate.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
Changes since V1: move stack_top into loop and change loop condition.
drivers/acpi/acpica/dswstate.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..882a3d1 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -402,7 +402,8 @@ void
acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
struct acpi_walk_state *walk_state)
{
- s32 i;
+ u32 i;
+ s32 stack_top;
union acpi_operand_object *obj_desc;
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
- for (i = (s32)pop_count - 1; i >= 0; i--) {
+ /* Calculate curruent top of the stack */
+
+ stack_top = (s32)walk_state->num_operands + walk_state->operand_index -
1;
+
+ for (i = 0; i < pop_count ; i++) {
if (walk_state->num_operands == 0) {
return;
}
@@ -419,11 +424,12 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
/* Pop the stack and delete an object if present in this stack
entry */
walk_state->num_operands--;
- obj_desc = walk_state->operands[i];
+ obj_desc = walk_state->operands[stack_top];
if (obj_desc) {
- acpi_ut_remove_reference(walk_state->operands[i]);
- walk_state->operands[i] = NULL;
+
acpi_ut_remove_reference(walk_state->operands[stack_top]);
+ walk_state->operands[stack_top] = NULL;
}
+ stack_top--;
}
ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Count=%X State=%p #Ops=%X\n",
--
2.1.4
[PATCH V2] acpi: acpica: fix acpi operand cache leak in dswstate.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
Changes since V1: move stack_top into loop and change loop condition.
drivers/acpi/acpica/dswstate.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..882a3d1 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -402,7 +402,8 @@ void
acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
struct acpi_walk_state *walk_state)
{
- s32 i;
+ u32 i;
+ s32 stack_top;
union acpi_operand_object *obj_desc;
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
- for (i = (s32)pop_count - 1; i >= 0; i--) {
+ /* Calculate curruent top of the stack */
+
+ stack_top = (s32)walk_state->num_operands + walk_state->operand_index -
1;
+
+ for (i = 0; i < pop_count ; i++) {
if (walk_state->num_operands == 0) {
return;
}
@@ -419,11 +424,12 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
/* Pop the stack and delete an object if present in this stack
entry */
walk_state->num_operands--;
- obj_desc = walk_state->operands[i];
+ obj_desc = walk_state->operands[stack_top];
if (obj_desc) {
- acpi_ut_remove_reference(walk_state->operands[i]);
- walk_state->operands[i] = NULL;
+
acpi_ut_remove_reference(walk_state->operands[stack_top]);
+ walk_state->operands[stack_top] = NULL;
}
+ stack_top--;
}
ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Count=%X State=%p #Ops=%X\n",
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak in nseval.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.464168] ACPI: Added _OSI(Module Device)
>[0.467022] ACPI: Added _OSI(Processor Device)
>[0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.471647] ACPI: Added _OSI(Processor Aggregator Device)
>[0.477997] ACPI Error: Null stack entry at 880215c0aad8
>(20170303/exresop-174)
>[0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for
>[OpcodeName unavailable] (20170303/dswexec-461)
>[0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node
>88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node
>88021710a618), AE_AML_INTERNAL (20170303/psparse-543)
>[0.497683] ACPI: Interpreter enabled
>[0.499385] ACPI: (supports S0)
>[0.501151] ACPI: Using IOAPIC for interrupt routing
>[0.503342] ACPI Error: Null stack entry at 880215c0aad8
>(20170303/exresop-174)
>[0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for
>[OpcodeName unavailable] (20170303/dswexec-461)
>[0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node
>88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node
>88021710ab18), AE_AML_INTERNAL (20170303/psparse-543)
>[0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC
>(20170303/bus-991)
>[0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.526795] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.529668] Call Trace:
>[0.530811] ? dump_stack+0x5c/0x81
>[0.532240] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.533905] ? acpi_os_delete_cache+0xa/0x10
>[0.535497] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.537237] ? acpi_terminate+0xa/0x14
>[0.538701] ? acpi_init+0x2af/0x34f
>[0.540008] ? acpi_sleep_proc_init+0x27/0x27
>[0.541593] ? do_one_initcall+0x4e/0x1a0
>[0.543008] ? kernel_init_freeable+0x19e/0x21f
>[0.546202] ? rest_init+0x80/0x80
>[0.547513] ? kernel_init+0xa/0x100
>[0.548817] ? ret_from_fork+0x25/0x30
>[0.550587] vgaarb: loaded
>[0.551716] EDAC MC: Ver: 3.0.0
>[0.553744] PCI: Probing PCI hardware
>[0.555038] PCI host bridge to bus :00
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ns_evaluate() function
only removes info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
occur, the status value is not AE_CTRL_RETURN_VALUE, and info->return_object is
also not null. Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/nseval.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index d22167c..f13d3cf 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -308,6 +308,14 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info
*info)
/* Map AE_CTRL_RETURN_VALUE to AE_OK, we are done with it */
status = AE_OK;
+ } else if (ACPI_FAILURE(status)) {
+
+ /* If return_object exists, delete it */
+
+ if (info->return_object) {
+ acpi_ut_remove_reference(info->return_object);
+ info->return_object = NULL;
+ }
}
ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak in nseval.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.464168] ACPI: Added _OSI(Module Device)
>[0.467022] ACPI: Added _OSI(Processor Device)
>[0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.471647] ACPI: Added _OSI(Processor Aggregator Device)
>[0.477997] ACPI Error: Null stack entry at 880215c0aad8
>(20170303/exresop-174)
>[0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for
>[OpcodeName unavailable] (20170303/dswexec-461)
>[0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node
>88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node
>88021710a618), AE_AML_INTERNAL (20170303/psparse-543)
>[0.497683] ACPI: Interpreter enabled
>[0.499385] ACPI: (supports S0)
>[0.501151] ACPI: Using IOAPIC for interrupt routing
>[0.503342] ACPI Error: Null stack entry at 880215c0aad8
>(20170303/exresop-174)
>[0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for
>[OpcodeName unavailable] (20170303/dswexec-461)
>[0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node
>88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node
>88021710ab18), AE_AML_INTERNAL (20170303/psparse-543)
>[0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC
>(20170303/bus-991)
>[0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.526795] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.529668] Call Trace:
>[0.530811] ? dump_stack+0x5c/0x81
>[0.532240] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.533905] ? acpi_os_delete_cache+0xa/0x10
>[0.535497] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.537237] ? acpi_terminate+0xa/0x14
>[0.538701] ? acpi_init+0x2af/0x34f
>[0.540008] ? acpi_sleep_proc_init+0x27/0x27
>[0.541593] ? do_one_initcall+0x4e/0x1a0
>[0.543008] ? kernel_init_freeable+0x19e/0x21f
>[0.546202] ? rest_init+0x80/0x80
>[0.547513] ? kernel_init+0xa/0x100
>[0.548817] ? ret_from_fork+0x25/0x30
>[0.550587] vgaarb: loaded
>[0.551716] EDAC MC: Ver: 3.0.0
>[0.553744] PCI: Probing PCI hardware
>[0.555038] PCI host bridge to bus :00
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ns_evaluate() function
only removes info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
occur, the status value is not AE_CTRL_RETURN_VALUE, and info->return_object is
also not null. Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/nseval.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index d22167c..f13d3cf 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -308,6 +308,14 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info
*info)
/* Map AE_CTRL_RETURN_VALUE to AE_OK, we are done with it */
status = AE_OK;
+ } else if (ACPI_FAILURE(status)) {
+
+ /* If return_object exists, delete it */
+
+ if (info->return_object) {
+ acpi_ut_remove_reference(info->return_object);
+ info->return_object = NULL;
+ }
}
ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak in dswstate.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/dswstate.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..fde6d78 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -403,6 +403,7 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
struct acpi_walk_state *walk_state)
{
s32 i;
+ s32 stack_top;
union acpi_operand_object *obj_desc;
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
- for (i = (s32)pop_count - 1; i >= 0; i--) {
+ /* Calculate curruent top of the stack */
+
+ stack_top = (s32)walk_state->num_operands + walk_state->operand_index -
1;
+
+ for (i = stack_top; i >= 0; i--) {
if (walk_state->num_operands == 0) {
return;
}
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak in dswstate.c
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K:
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063] ? dump_stack+0x5c/0x81
>[0.68] ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[0.613906] ? acpi_os_delete_cache+0xa/0x10
>[0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293] ? acpi_terminate+0xa/0x14
>[0.620394] ? acpi_init+0x2af/0x34f
>[0.621616] ? __class_create+0x4c/0x80
>[0.623412] ? video_setup+0x7f/0x7f
>[0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[0.625861] ? do_one_initcall+0x4e/0x1a0
>[0.627513] ? kernel_init_freeable+0x19e/0x21f
>[0.628972] ? rest_init+0x80/0x80
>[0.630043] ? kernel_init+0xa/0x100
>[0.631084] ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io 0x-0x]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/dswstate.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..fde6d78 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -403,6 +403,7 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
struct acpi_walk_state *walk_state)
{
s32 i;
+ s32 stack_top;
union acpi_operand_object *obj_desc;
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
- for (i = (s32)pop_count - 1; i >= 0; i--) {
+ /* Calculate curruent top of the stack */
+
+ stack_top = (s32)walk_state->num_operands + walk_state->operand_index -
1;
+
+ for (i = stack_top; i >= 0; i--) {
if (walk_state->num_operands == 0) {
return;
}
--
2.1.4
[tip:x86/urgent] x86/ioapic: Pass the correct data to unmask_ioapic_irq()
Commit-ID: afabde6986911394c95c596f96d2ac833eef04cc
Gitweb: http://git.kernel.org/tip/afabde6986911394c95c596f96d2ac833eef04cc
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Tue, 18 Jul 2017 17:39:54 +0200
x86/ioapic: Pass the correct data to unmask_ioapic_irq()
One of the rarely executed code pathes in check_timer() calls
unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
interrupt 0. irq_get_chip_data(0) returns NULL, so the following
dereference in unmask_ioapic_irq() causes a kernel panic.
The issue went unnoticed in the first place because irq_get_chip_data()
returns a void pointer so the compiler cannot do a type check on the
argument. The code path was added for machines with broken configuration,
but it seems that those machines are either not running current kernels or
simply do not longer exist.
Hand in irq_get_irq_data(0) as argument which provides the correct data.
[ tglx: Rewrote changelog ]
Fixes: 4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
Signed-off-by: Seunghun Han <kkama...@gmail.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkama...@gmail.com
---
arch/x86/kernel/apic/io_apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b4f5f73..237e9c2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2093,7 +2093,7 @@ static inline void __init check_timer(void)
int idx;
idx = find_irq_entry(apic1, pin1, mp_INT);
if (idx != -1 && irq_trigger(idx))
- unmask_ioapic_irq(irq_get_chip_data(0));
+ unmask_ioapic_irq(irq_get_irq_data(0));
}
irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
[tip:x86/urgent] x86/ioapic: Pass the correct data to unmask_ioapic_irq()
Commit-ID: afabde6986911394c95c596f96d2ac833eef04cc
Gitweb: http://git.kernel.org/tip/afabde6986911394c95c596f96d2ac833eef04cc
Author: Seunghun Han
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Thomas Gleixner
CommitDate: Tue, 18 Jul 2017 17:39:54 +0200
x86/ioapic: Pass the correct data to unmask_ioapic_irq()
One of the rarely executed code pathes in check_timer() calls
unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
interrupt 0. irq_get_chip_data(0) returns NULL, so the following
dereference in unmask_ioapic_irq() causes a kernel panic.
The issue went unnoticed in the first place because irq_get_chip_data()
returns a void pointer so the compiler cannot do a type check on the
argument. The code path was added for machines with broken configuration,
but it seems that those machines are either not running current kernels or
simply do not longer exist.
Hand in irq_get_irq_data(0) as argument which provides the correct data.
[ tglx: Rewrote changelog ]
Fixes: 4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
Signed-off-by: Seunghun Han
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkama...@gmail.com
---
arch/x86/kernel/apic/io_apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b4f5f73..237e9c2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2093,7 +2093,7 @@ static inline void __init check_timer(void)
int idx;
idx = find_irq_entry(apic1, pin1, mp_INT);
if (idx != -1 && irq_trigger(idx))
- unmask_ioapic_irq(irq_get_chip_data(0));
+ unmask_ioapic_irq(irq_get_irq_data(0));
}
irq_domain_deactivate_irq(irq_data);
irq_domain_activate_irq(irq_data);
[PATCH] x86: kernel: acpi: fix an invalid argument passing in io_apic.c
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I found a kernel panic while I tested latest kernel version. The kernel panic log is as follows: >[0.058851] BUG: unable to handle kernel NULL pointer dereference at >0010 >[0.06] IP: io_apic_modify_irq+0x11/0x80 >[0.06] PGD 0 >[0.06] P4D 0 >[0.06] >[0.06] Oops: [#1] SMP >[0.06] Modules linked in: >[0.06] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[0.06] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >VirtualBox 12/01/2006 >[0.06] task: 88021619acc0 task.stack: c9c5 >[0.06] RIP: 0010:io_apic_modify_irq+0x11/0x80 >[0.06] RSP: :c9c53e40 EFLAGS: 00010046 >[0.06] RAX: 0082 RBX: RCX: > >[0.06] RDX: RSI: fffe RDI: > >[0.06] RBP: R08: 8802170cda00 R09: >0117 >[0.06] R10: R11: 0116 R12: > >[0.06] R13: R14: 8802170cda58 R15: >8802170cec00 >[0.06] FS: () GS:88021fc0() >knlGS: >[0.06] CS: 0010 DS: ES: CR0: 80050033 >[0.06] CR2: 0010 CR3: 01a09000 CR4: >06f0 >[0.06] Call Trace: >[0.06] ? unmask_ioapic_irq+0x2b/0x40 >[0.06] ? setup_IO_APIC+0x79b/0x7a3 >[0.06] ? clear_IO_APIC_pin+0x93/0x130 >[0.06] ? apic_bsp_setup+0xa2/0xac >[0.06] ? native_smp_prepare_cpus+0x245/0x2b1 >[0.06] ? kernel_init_freeable+0xd0/0x21f >[0.06] ? rest_init+0x80/0x80 >[0.06] ? kernel_init+0xa/0x100 >[0.06] ? ret_from_fork+0x25/0x30 >[0.06] Code: 47 04 83 c6 10 25 ff 0f 00 00 48 2d 00 10 80 00 48 29 c8 >89 30 89 50 10 c3 90 0f 1f 44 00 00 41 55 41 54 49 89 cd 55 53 48 89 fb <23> >77 10 09 d6 89 73 10 4c 8b 27 89 f5 4c 39 e7 74 4f 41 8b 44 >[0.06] RIP: io_apic_modify_irq+0x11/0x80 RSP: c9c53e40 >[0.06] CR2: 0010 >[0.06] ---[ end trace c0d793cf886c6f59 ]--- >[0.06] Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0009 >[0.06] >[0.06] ---[ end Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0009 >[0.06] I analyzed this kernel panic in detail and found that check_timer() function passed an invalid argument to unmask_ioapic_irq() function. The code is as follows: > int idx; > idx = find_irq_entry(apic1, pin1, mp_INT); > if (idx != -1 && irq_trigger(idx)) > unmask_ioapic_irq(irq_get_chip_data(0)); The unmask_ioapic_irq() function wants a "struct irq_data *" argument, but the code, irq_get_chip_data(0), passes a "struct irq_chip *" value. To fix an invalid argument passing, I made a patch which passes a return value of irq_get_irq_data(0). Thank you. Signed-off-by: Seunghun Han <kkama...@gmail.com> --- arch/x86/kernel/apic/io_apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index b4f5f73..237e9c2 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -2093,7 +2093,7 @@ static inline void __init check_timer(void) int idx; idx = find_irq_entry(apic1, pin1, mp_INT); if (idx != -1 && irq_trigger(idx)) - unmask_ioapic_irq(irq_get_chip_data(0)); + unmask_ioapic_irq(irq_get_irq_data(0)); } irq_domain_deactivate_irq(irq_data); irq_domain_activate_irq(irq_data); -- 2.1.4
[PATCH] x86: kernel: acpi: fix an invalid argument passing in io_apic.c
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I found a kernel panic while I tested latest kernel version. The kernel panic log is as follows: >[0.058851] BUG: unable to handle kernel NULL pointer dereference at >0010 >[0.06] IP: io_apic_modify_irq+0x11/0x80 >[0.06] PGD 0 >[0.06] P4D 0 >[0.06] >[0.06] Oops: [#1] SMP >[0.06] Modules linked in: >[0.06] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[0.06] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >VirtualBox 12/01/2006 >[0.06] task: 88021619acc0 task.stack: c9c5 >[0.06] RIP: 0010:io_apic_modify_irq+0x11/0x80 >[0.06] RSP: :c9c53e40 EFLAGS: 00010046 >[0.06] RAX: 0082 RBX: RCX: > >[0.06] RDX: RSI: fffe RDI: > >[0.06] RBP: R08: 8802170cda00 R09: >0117 >[0.06] R10: R11: 0116 R12: > >[0.06] R13: R14: 8802170cda58 R15: >8802170cec00 >[0.06] FS: () GS:88021fc0() >knlGS: >[0.06] CS: 0010 DS: ES: CR0: 80050033 >[0.06] CR2: 0010 CR3: 01a09000 CR4: >06f0 >[0.06] Call Trace: >[0.06] ? unmask_ioapic_irq+0x2b/0x40 >[0.06] ? setup_IO_APIC+0x79b/0x7a3 >[0.06] ? clear_IO_APIC_pin+0x93/0x130 >[0.06] ? apic_bsp_setup+0xa2/0xac >[0.06] ? native_smp_prepare_cpus+0x245/0x2b1 >[0.06] ? kernel_init_freeable+0xd0/0x21f >[0.06] ? rest_init+0x80/0x80 >[0.06] ? kernel_init+0xa/0x100 >[0.06] ? ret_from_fork+0x25/0x30 >[0.06] Code: 47 04 83 c6 10 25 ff 0f 00 00 48 2d 00 10 80 00 48 29 c8 >89 30 89 50 10 c3 90 0f 1f 44 00 00 41 55 41 54 49 89 cd 55 53 48 89 fb <23> >77 10 09 d6 89 73 10 4c 8b 27 89 f5 4c 39 e7 74 4f 41 8b 44 >[0.06] RIP: io_apic_modify_irq+0x11/0x80 RSP: c9c53e40 >[0.06] CR2: 0010 >[0.06] ---[ end trace c0d793cf886c6f59 ]--- >[0.06] Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0009 >[0.06] >[0.06] ---[ end Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0009 >[0.06] I analyzed this kernel panic in detail and found that check_timer() function passed an invalid argument to unmask_ioapic_irq() function. The code is as follows: > int idx; > idx = find_irq_entry(apic1, pin1, mp_INT); > if (idx != -1 && irq_trigger(idx)) > unmask_ioapic_irq(irq_get_chip_data(0)); The unmask_ioapic_irq() function wants a "struct irq_data *" argument, but the code, irq_get_chip_data(0), passes a "struct irq_chip *" value. To fix an invalid argument passing, I made a patch which passes a return value of irq_get_irq_data(0). Thank you. Signed-off-by: Seunghun Han --- arch/x86/kernel/apic/io_apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index b4f5f73..237e9c2 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -2093,7 +2093,7 @@ static inline void __init check_timer(void) int idx; idx = find_irq_entry(apic1, pin1, mp_INT); if (idx != -1 && irq_trigger(idx)) - unmask_ioapic_irq(irq_get_chip_data(0)); + unmask_ioapic_irq(irq_get_irq_data(0)); } irq_domain_deactivate_irq(irq_data); irq_domain_activate_irq(irq_data); -- 2.1.4
Re: [PATCH V4] acpi: acpica: fix acpi parse and parseext cache leaks
Hello, Andy.
Thank you for your reply.
Patch V4 is the last patch which is applied all changes from original code.
Due to maintainer's advice, Patch V1, V2, V3 have reverted and I made
the latest patch, Patch V4.
(the review is here, https://github.com/acpica/acpica/pull/278)
Therefore, it seems that incremental patch is not needed.
If you have any request, please let me know.
Best regards.
ps) I am sending email again after removing HTML part.
2017-06-26 7:12 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> Hello, Andy.
>
> Thank you for your reply.
>
> Patch V4 is the last patch which is applied all changes from original code.
> Due to reviewer's advice, Patch V1, V2, V3 has reverted and I made the
> latest patch, Patch V4.
> Therefore, it seems that incremental patch is not needed.
>
> If you have any requests, please let me know.
>
> Best regards.
>
>
> 2017년 6월 26일 (월) 오전 1:13, Andy Shevchenko <andy.shevche...@gmail.com>님이 작성:
>>
>> On Fri, Jun 23, 2017 at 12:36 PM, Seunghun Han <kkama...@gmail.com> wrote:
>> > I'm Seunghun Han, and I work for National Security Research Institute of
>> > South Korea.
>>
>>
>> > - /* Clean up */
>> > - do {
>> > - if (op) {
>> > - status2 =
>> > -
>> > acpi_ps_complete_this_op
>> > - (walk_state,
>> > op);
>> > - if (ACPI_FAILURE
>> > - (status2)) {
>> > -
>> > return_ACPI_STATUS
>> > -
>> > (status2);
>> > - }
>> > - }
>> > -
>> > - acpi_ps_pop_scope(&
>> > -
>> > (walk_state->
>> > -
>> > parser_state),
>> > - ,
>> > -
>> > _state->
>> > -
>> > arg_types,
>> > -
>> > _state->
>> > -
>> > arg_count);
>> > -
>> > - } while (op);
>>
>> I didn't get, do you send an incremental patch as a new version?!
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
Re: [PATCH V4] acpi: acpica: fix acpi parse and parseext cache leaks
Hello, Andy.
Thank you for your reply.
Patch V4 is the last patch which is applied all changes from original code.
Due to maintainer's advice, Patch V1, V2, V3 have reverted and I made
the latest patch, Patch V4.
(the review is here, https://github.com/acpica/acpica/pull/278)
Therefore, it seems that incremental patch is not needed.
If you have any request, please let me know.
Best regards.
ps) I am sending email again after removing HTML part.
2017-06-26 7:12 GMT+09:00 Seunghun Han :
> Hello, Andy.
>
> Thank you for your reply.
>
> Patch V4 is the last patch which is applied all changes from original code.
> Due to reviewer's advice, Patch V1, V2, V3 has reverted and I made the
> latest patch, Patch V4.
> Therefore, it seems that incremental patch is not needed.
>
> If you have any requests, please let me know.
>
> Best regards.
>
>
> 2017년 6월 26일 (월) 오전 1:13, Andy Shevchenko 님이 작성:
>>
>> On Fri, Jun 23, 2017 at 12:36 PM, Seunghun Han wrote:
>> > I'm Seunghun Han, and I work for National Security Research Institute of
>> > South Korea.
>>
>>
>> > - /* Clean up */
>> > - do {
>> > - if (op) {
>> > - status2 =
>> > -
>> > acpi_ps_complete_this_op
>> > - (walk_state,
>> > op);
>> > - if (ACPI_FAILURE
>> > - (status2)) {
>> > -
>> > return_ACPI_STATUS
>> > -
>> > (status2);
>> > - }
>> > - }
>> > -
>> > - acpi_ps_pop_scope(&
>> > -
>> > (walk_state->
>> > -
>> > parser_state),
>> > - ,
>> > -
>> > _state->
>> > -
>> > arg_types,
>> > -
>> > _state->
>> > -
>> > arg_count);
>> > -
>> > - } while (op);
>>
>> I didn't get, do you send an incremental patch as a new version?!
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
[PATCH V4] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
[PATCH V4] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
[PATCH V3] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
[PATCH V3] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
[PATCH V2] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
[PATCH V2] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could
Re: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
Hello, Robert. My research system are based on virtual machine and Intel NUC machine, and they are still working despite of ACPI subsystem shutdown. So, I can find the acpi memory leaks by using "dmesg" command. Best regards. 2017-06-16 4:52 GMT+09:00 Moore, Robert <robert.mo...@intel.com>: > This might be a dumb question, but isn't the system basically hosed once the > ACPI subsystem is shutdown? > > >> -----Original Message- >> From: Seunghun Han [mailto:kkama...@gmail.com] >> Sent: Wednesday, June 14, 2017 4:08 AM >> To: Zheng, Lv <lv.zh...@intel.com>; Moore, Robert >> <robert.mo...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com> >> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- >> ker...@vger.kernel.org; Seunghun Han <kkama...@gmail.com> >> Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks >> >> I'm Seunghun Han, and I work for National Security Research Institute of >> South Korea. >> >> I have been doing a research on ACPI and found an ACPI cache leak in >> ACPI early abort cases. >> >> Boot log of ACPI cache leak is as follows: >> [0.352414] ACPI: Added _OSI(Module Device) >> [0.353182] ACPI: Added _OSI(Processor Device) >> [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) >> [0.353182] ACPI: Added _OSI(Processor Aggregator Device) >> [0.356028] ACPI: Unable to start the ACPI Interpreter >> [0.356799] ACPI Error: Could not remove SCI handler >> (20170303/evmisc-281) >> [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has >> objects >> [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4-next-20170608+ #10 >> [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >> VirtualBox 12/01/2006 >> [0.361873] Call Trace: >> [0.362243] ? dump_stack+0x5c/0x81 >> [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 >> [0.362944] ? acpi_sleep_proc_init+0x27/0x27 >> [0.363296] ? acpi_os_delete_cache+0xa/0x10 >> [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b >> [0.364000] ? acpi_terminate+0xa/0x14 >> [0.364000] ? acpi_init+0x2af/0x34f >> [0.364000] ? __class_create+0x4c/0x80 >> [0.364000] ? video_setup+0x7f/0x7f >> [0.364000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.364000] ? do_one_initcall+0x4e/0x1a0 >> [0.364000] ? kernel_init_freeable+0x189/0x20a >> [0.364000] ? rest_init+0xc0/0xc0 >> [0.364000] ? kernel_init+0xa/0x100 >> [0.364000] ? ret_from_fork+0x25/0x30 >> >> I analyzed this memory leak detailed. I found that “Acpi-State” cache >> and “Acpi-Parse” cache were merged because the size of cache objects was >> same slab cache size. >> >> I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked >> using SLAB_NEVER_MERGE flag in kmem_cache_create() function. >> >> Real ACPI cache leak point is as follows: >> [0.360101] ACPI: Added _OSI(Module Device) >> [0.360101] ACPI: Added _OSI(Processor Device) >> [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) >> [0.361043] ACPI: Added _OSI(Processor Aggregator Device) >> [0.364016] ACPI: Unable to start the ACPI Interpreter >> [0.365061] ACPI Error: Could not remove SCI handler >> (20170303/evmisc-281) >> [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has >> objects >> [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4-next-20170608+ #8 >> [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >> VirtualBox 12/01/2006 >> [0.372000] Call Trace: >> [0.372000] ? dump_stack+0x5c/0x81 >> [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 >> [0.372000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.372000] ? acpi_os_delete_cache+0xa/0x10 >> [0.372000] ? acpi_ut_delete_caches+0x56/0x7b >> [0.372000] ? acpi_terminate+0xa/0x14 >> [0.372000] ? acpi_init+0x2af/0x34f >> [0.372000] ? __class_create+0x4c/0x80 >> [0.372000] ? video_setup+0x7f/0x7f >> [0.372000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.372000] ? do_one_initcall+0x4e/0x1a0 >> [0.372000] ? kernel_init_freeable+0x189/0x20a >> [0.372000] ? rest_init+0xc0/0xc0 >> [0.372000] ? kernel_init+0xa/0x100 >> [0.372000] ? ret_from_fork+0x25/0x30 >> [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has >> objects >> [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4
Re: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
Hello, Robert. My research system are based on virtual machine and Intel NUC machine, and they are still working despite of ACPI subsystem shutdown. So, I can find the acpi memory leaks by using "dmesg" command. Best regards. 2017-06-16 4:52 GMT+09:00 Moore, Robert : > This might be a dumb question, but isn't the system basically hosed once the > ACPI subsystem is shutdown? > > >> -Original Message- >> From: Seunghun Han [mailto:kkama...@gmail.com] >> Sent: Wednesday, June 14, 2017 4:08 AM >> To: Zheng, Lv ; Moore, Robert >> ; Wysocki, Rafael J >> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- >> ker...@vger.kernel.org; Seunghun Han >> Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks >> >> I'm Seunghun Han, and I work for National Security Research Institute of >> South Korea. >> >> I have been doing a research on ACPI and found an ACPI cache leak in >> ACPI early abort cases. >> >> Boot log of ACPI cache leak is as follows: >> [0.352414] ACPI: Added _OSI(Module Device) >> [0.353182] ACPI: Added _OSI(Processor Device) >> [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) >> [0.353182] ACPI: Added _OSI(Processor Aggregator Device) >> [0.356028] ACPI: Unable to start the ACPI Interpreter >> [0.356799] ACPI Error: Could not remove SCI handler >> (20170303/evmisc-281) >> [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has >> objects >> [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4-next-20170608+ #10 >> [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >> VirtualBox 12/01/2006 >> [0.361873] Call Trace: >> [0.362243] ? dump_stack+0x5c/0x81 >> [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 >> [0.362944] ? acpi_sleep_proc_init+0x27/0x27 >> [0.363296] ? acpi_os_delete_cache+0xa/0x10 >> [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b >> [0.364000] ? acpi_terminate+0xa/0x14 >> [0.364000] ? acpi_init+0x2af/0x34f >> [0.364000] ? __class_create+0x4c/0x80 >> [0.364000] ? video_setup+0x7f/0x7f >> [0.364000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.364000] ? do_one_initcall+0x4e/0x1a0 >> [0.364000] ? kernel_init_freeable+0x189/0x20a >> [0.364000] ? rest_init+0xc0/0xc0 >> [0.364000] ? kernel_init+0xa/0x100 >> [0.364000] ? ret_from_fork+0x25/0x30 >> >> I analyzed this memory leak detailed. I found that “Acpi-State” cache >> and “Acpi-Parse” cache were merged because the size of cache objects was >> same slab cache size. >> >> I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked >> using SLAB_NEVER_MERGE flag in kmem_cache_create() function. >> >> Real ACPI cache leak point is as follows: >> [0.360101] ACPI: Added _OSI(Module Device) >> [0.360101] ACPI: Added _OSI(Processor Device) >> [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) >> [0.361043] ACPI: Added _OSI(Processor Aggregator Device) >> [0.364016] ACPI: Unable to start the ACPI Interpreter >> [0.365061] ACPI Error: Could not remove SCI handler >> (20170303/evmisc-281) >> [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has >> objects >> [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4-next-20170608+ #8 >> [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >> VirtualBox 12/01/2006 >> [0.372000] Call Trace: >> [0.372000] ? dump_stack+0x5c/0x81 >> [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 >> [0.372000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.372000] ? acpi_os_delete_cache+0xa/0x10 >> [0.372000] ? acpi_ut_delete_caches+0x56/0x7b >> [0.372000] ? acpi_terminate+0xa/0x14 >> [0.372000] ? acpi_init+0x2af/0x34f >> [0.372000] ? __class_create+0x4c/0x80 >> [0.372000] ? video_setup+0x7f/0x7f >> [0.372000] ? acpi_sleep_proc_init+0x27/0x27 >> [0.372000] ? do_one_initcall+0x4e/0x1a0 >> [0.372000] ? kernel_init_freeable+0x189/0x20a >> [0.372000] ? rest_init+0xc0/0xc0 >> [0.372000] ? kernel_init+0xa/0x100 >> [0.372000] ? ret_from_fork+0x25/0x30 >> [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has >> objects >> [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.12.0-rc4-next-20170608+ #8 >> [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >> VirtualBox 12/01/2006 >> [0.3
[PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak detailed. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this informat
[PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [0.352414] ACPI: Added _OSI(Module Device) [0.353182] ACPI: Added _OSI(Processor Device) [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [0.353182] ACPI: Added _OSI(Processor Aggregator Device) [0.356028] ACPI: Unable to start the ACPI Interpreter [0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #10 [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.361873] Call Trace: [0.362243] ? dump_stack+0x5c/0x81 [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [0.362944] ? acpi_sleep_proc_init+0x27/0x27 [0.363296] ? acpi_os_delete_cache+0xa/0x10 [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [0.364000] ? acpi_terminate+0xa/0x14 [0.364000] ? acpi_init+0x2af/0x34f [0.364000] ? __class_create+0x4c/0x80 [0.364000] ? video_setup+0x7f/0x7f [0.364000] ? acpi_sleep_proc_init+0x27/0x27 [0.364000] ? do_one_initcall+0x4e/0x1a0 [0.364000] ? kernel_init_freeable+0x189/0x20a [0.364000] ? rest_init+0xc0/0xc0 [0.364000] ? kernel_init+0xa/0x100 [0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak detailed. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [0.360101] ACPI: Added _OSI(Module Device) [0.360101] ACPI: Added _OSI(Processor Device) [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [0.361043] ACPI: Added _OSI(Processor Aggregator Device) [0.364016] ACPI: Unable to start the ACPI Interpreter [0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.372000] Call Trace: [0.372000] ? dump_stack+0x5c/0x81 [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? acpi_os_delete_cache+0xa/0x10 [0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [0.372000] ? kernel_init+0xa/0x100 [0.372000] ? ret_from_fork+0x25/0x30 [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 4.12.0-rc4-next-20170608+ #8 [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [0.392000] Call Trace: [0.392000] ? dump_stack+0x5c/0x81 [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? acpi_os_delete_cache+0xa/0x10 [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [0.392000] ? acpi_terminate+0xa/0x14 [0.392000] ? acpi_init+0x2af/0x34f [0.392000] ? __class_create+0x4c/0x80 [0.392000] ? video_setup+0x7f/0x7f [0.392000] ? acpi_sleep_proc_init+0x27/0x27 [0.392000] ? do_one_initcall+0x4e/0x1a0 [0.392000] ? kernel_init_freeable+0x189/0x20a [0.392000] ? rest_init+0xc0/0xc0 [0.392000] ? kernel_init+0xa/0x100 [0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this informat
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hello, Lv and Rafael. I checked that my patch was merged to ACPICA project. Thank you for your notice. I added an analysis report which has the root cause of this problem below. 2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>: > Hi, Rafael > >> From: linux-acpi-ow...@vger.kernel.org >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. >> Wysocki >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote: >> > Hi, Rafael. >> > >> > I agree with you and I added my opinion below. >> > >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote: >> >>> Hi, Rafeal. >> >>> >> >>> I added my opinion below. >> >>> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> >>> >> Hi, Rafael. >> >>> >> >> >>> >> I added my opinion below. >> >>> >> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >>> >> >> Hi, Lv Zheng. >> >>> >> >> >> >>> >> >> I added my handcrafted ACPI table under your request, because >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >>> >> >> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>: >> >>> >> >> > Hello, >> >>> >> >> > >> >>> >> >> > I attached the test results below, >> >>> >> >> > >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki >> >>> >> >> > <r...@rjwysocki.net>: >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> >> >> >>> Hi, >> >>> >> >> >>> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On >> Behalf Of Seunghun >> >>> >> >> >>> > Han >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >>> >> >> >>> > >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >>> >> >> >>> > Institute of >> >>> >> >> >>> > South Korea. >> >>> >> >> >>> > >> >>> >> >> >>> > I have been doing a research on ACPI and making a >> >>> >> >> >>> > handcrafted ACPI table >> >>> >> >> >>> > for my research. >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux >> >>> >> >> >>> > kernel while boot >> >>> >> >> >>> > process, and Linux kernel goes well without critical >> >>> >> >> >>> > problems. >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early >> >>> >> >> >>> > abort cases. >> >>> >> >> >>> > >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >>> >> >> &g
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hello, Lv and Rafael. I checked that my patch was merged to ACPICA project. Thank you for your notice. I added an analysis report which has the root cause of this problem below. 2017-02-27 11:45 GMT+09:00 Zheng, Lv : > Hi, Rafael > >> From: linux-acpi-ow...@vger.kernel.org >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. >> Wysocki >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han wrote: >> > Hi, Rafael. >> > >> > I agree with you and I added my opinion below. >> > >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki : >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote: >> >>> Hi, Rafeal. >> >>> >> >>> I added my opinion below. >> >>> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki : >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> >>> >> Hi, Rafael. >> >>> >> >> >>> >> I added my opinion below. >> >>> >> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki : >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >>> >> >> Hi, Lv Zheng. >> >>> >> >> >> >>> >> >> I added my handcrafted ACPI table under your request, because >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >>> >> >> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han : >> >>> >> >> > Hello, >> >>> >> >> > >> >>> >> >> > I attached the test results below, >> >>> >> >> > >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki >> >>> >> >> > : >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> >> >> >>> Hi, >> >>> >> >> >>> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On >> Behalf Of Seunghun >> >>> >> >> >>> > Han >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >>> >> >> >>> > >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >>> >> >> >>> > Institute of >> >>> >> >> >>> > South Korea. >> >>> >> >> >>> > >> >>> >> >> >>> > I have been doing a research on ACPI and making a >> >>> >> >> >>> > handcrafted ACPI table >> >>> >> >> >>> > for my research. >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux >> >>> >> >> >>> > kernel while boot >> >>> >> >> >>> > process, and Linux kernel goes well without critical >> >>> >> >> >>> > problems. >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early >> >>> >> >> >>> > abort cases. >> >>> >> >> >>> > >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to >> >>> >> >> >>> > >install System Control >> Interrupt
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafael. I agree with you and I added my opinion below. 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: > On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote: >> Hi, Rafeal. >> >> I added my opinion below. >> >> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> >> Hi, Rafael. >> >> >> >> I added my opinion below. >> >> >> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >> >> Hi, Lv Zheng. >> >> >> >> >> >> I added my handcrafted ACPI table under your request, because >> >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> >> >> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>: >> >> >> > Hello, >> >> >> > >> >> >> > I attached the test results below, >> >> >> > >> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>: >> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >> >> >>> > Han >> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> >> >>> > >> >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >> >> >>> > Institute of >> >> >> >>> > South Korea. >> >> >> >>> > >> >> >> >>> > I have been doing a research on ACPI and making a handcrafted >> >> >> >>> > ACPI table >> >> >> >>> > for my research. >> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux >> >> >> >>> > kernel while boot >> >> >> >>> > process, and Linux kernel goes well without critical problems. >> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort >> >> >> >>> > cases. >> >> >> >>> > >> >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to >> >> >> >>> > >install System Control Interrupt handler >> >> >> >>> > (20160930/evevent-131) >> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >> >> >>> > >(20160930/evmisc-281) >> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache >> >> >> >>> > >still has objects >> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> >> >> >>> > >4.10.0-rc3 #2 >> >> >> >>> > >[0.186820] Hardware name: innotek GmbH >> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 >> >> >> >>> > >[0.188000] Call Trace: >> >> >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >> >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >> >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >> >&g
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafael. I agree with you and I added my opinion below. 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki : > On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote: >> Hi, Rafeal. >> >> I added my opinion below. >> >> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki : >> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> >> Hi, Rafael. >> >> >> >> I added my opinion below. >> >> >> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki : >> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >> >> Hi, Lv Zheng. >> >> >> >> >> >> I added my handcrafted ACPI table under your request, because >> >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> >> >> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han : >> >> >> > Hello, >> >> >> > >> >> >> > I attached the test results below, >> >> >> > >> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki : >> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >> >> >>> > Han >> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> >> >>> > >> >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >> >> >>> > Institute of >> >> >> >>> > South Korea. >> >> >> >>> > >> >> >> >>> > I have been doing a research on ACPI and making a handcrafted >> >> >> >>> > ACPI table >> >> >> >>> > for my research. >> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux >> >> >> >>> > kernel while boot >> >> >> >>> > process, and Linux kernel goes well without critical problems. >> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort >> >> >> >>> > cases. >> >> >> >>> > >> >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to >> >> >> >>> > >install System Control Interrupt handler >> >> >> >>> > (20160930/evevent-131) >> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >> >> >>> > >(20160930/evmisc-281) >> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache >> >> >> >>> > >still has objects >> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> >> >> >>> > >4.10.0-rc3 #2 >> >> >> >>> > >[0.186820] Hardware name: innotek GmbH >> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 >> >> >> >>> > >[0.188000] Call Trace: >> >> >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >> >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >> >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >> >> >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >> >> >> >>> > >[0.18
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafeal. I added my opinion below. 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> Hi, Rafael. >> >> I added my opinion below. >> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >> Hi, Lv Zheng. >> >> >> >> I added my handcrafted ACPI table under your request, because >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>: >> >> > Hello, >> >> > >> >> > I attached the test results below, >> >> > >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>: >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >>> Hi, >> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >> >>> > Han >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> >>> > >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >> >>> > Institute of >> >> >>> > South Korea. >> >> >>> > >> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI >> >> >>> > table >> >> >>> > for my research. >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel >> >> >>> > while boot >> >> >>> > process, and Linux kernel goes well without critical problems. >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >> >> >>> > >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install >> >> >>> > >System Control Interrupt handler >> >> >>> > (20160930/evevent-131) >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >> >>> > >(20160930/evmisc-281) >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still >> >> >>> > >has objects >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> >> >>> > >4.10.0-rc3 #2 >> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, >> >> >>> > >BIOS VirtualBox 12/01/2006 >> >> >>> > >[0.188000] Call Trace: >> >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >> >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >> >> >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >> >> >>> > >[0.188000] ? acpi_terminate+0x5/0xf >> >> >>> > >[0.188000] ? acpi_init+0x288/0x32e >> >> >>> > >[0.188000] ? __class_create+0x4c/0x80 >> >> >>> > >[0.188000] ? video_setup+0x7a/0x7a >> >> >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >> >> >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >> >> >>> > >[0.188000] ? rest_init+0x80/0x80 >> >> >>> > >[0.188000] ? kernel_init+0xa/0x100 >> >>
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafeal. I added my opinion below. 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki : > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote: >> Hi, Rafael. >> >> I added my opinion below. >> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki : >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> >> Hi, Lv Zheng. >> >> >> >> I added my handcrafted ACPI table under your request, because >> >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han : >> >> > Hello, >> >> > >> >> > I attached the test results below, >> >> > >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki : >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >>> Hi, >> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >> >>> > Han >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >> >>> > >> >> >>> > I'm Seunghun Han, and I work for National Security Research >> >> >>> > Institute of >> >> >>> > South Korea. >> >> >>> > >> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI >> >> >>> > table >> >> >>> > for my research. >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel >> >> >>> > while boot >> >> >>> > process, and Linux kernel goes well without critical problems. >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >> >> >>> > >> >> >>> > Boot log of ACPI operand cache leak is as follows: >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install >> >> >>> > >System Control Interrupt handler >> >> >>> > (20160930/evevent-131) >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >> >>> > >(20160930/evmisc-281) >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still >> >> >>> > >has objects >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> >> >>> > >4.10.0-rc3 #2 >> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, >> >> >>> > >BIOS VirtualBox 12/01/2006 >> >> >>> > >[0.188000] Call Trace: >> >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >> >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >> >> >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >> >> >>> > >[0.188000] ? acpi_terminate+0x5/0xf >> >> >>> > >[0.188000] ? acpi_init+0x288/0x32e >> >> >>> > >[0.188000] ? __class_create+0x4c/0x80 >> >> >>> > >[0.188000] ? video_setup+0x7a/0x7a >> >> >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >> >> >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >> >> >>> > >[0.188000] ? rest_init+0x80/0x80 >> >> >>> > >[0.188000] ? kernel_init+0xa/0x100 >> >> >>> > >[0.188000] ? ret_from_fork+0x25/0x30 >> >> >>> >
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafael. I added my opinion below. 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>: > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> Hi, Lv Zheng. >> >> I added my handcrafted ACPI table under your request, because >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>: >> > Hello, >> > >> > I attached the test results below, >> > >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>: >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> Hi, >> >>> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >>> > Han >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >>> > >> >>> > I'm Seunghun Han, and I work for National Security Research Institute >> >>> > of >> >>> > South Korea. >> >>> > >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI >> >>> > table >> >>> > for my research. >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel >> >>> > while boot >> >>> > process, and Linux kernel goes well without critical problems. >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >> >>> > >> >>> > Boot log of ACPI operand cache leak is as follows: >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install >> >>> > >System Control Interrupt handler >> >>> > (20160930/evevent-131) >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >>> > >(20160930/evmisc-281) >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has >> >>> > >objects >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, >> >>> > >BIOS VirtualBox 12/01/2006 >> >>> > >[0.188000] Call Trace: >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >> >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >> >>> > >[0.188000] ? acpi_terminate+0x5/0xf >> >>> > >[0.188000] ? acpi_init+0x288/0x32e >> >>> > >[0.188000] ? __class_create+0x4c/0x80 >> >>> > >[0.188000] ? video_setup+0x7a/0x7a >> >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >> >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >> >>> > >[0.188000] ? rest_init+0x80/0x80 >> >>> > >[0.188000] ? kernel_init+0xa/0x100 >> >>> > >[0.188000] ? ret_from_fork+0x25/0x30 >> >>> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error. >> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c >> >>> on" and "acpidump -c off" output? >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux. >> Here are raw dumps of table. > > So, excuse me, but what's the security issue here? > > You hacked your ACPI tables into pieces which requires root privileges anyway. > > Thanks, > Rafael > As you mentioned earlier, I hacked my ACPI table for research, so it seems that it is not a security issue. But, if new mainboard are released and they have a vendor-specific ACPI table which has invalid data, the old version of kernel (<=4.9) will possibly expose kernel address and KASLR will be neutralized unintentionally. I know the vendors collaborate with Linux kernel developers, but the problem can still occur. Hardware vendors release so many kinds of mainboard in a year, and the major Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time. For this reason, I think this issue has a security aspect. Thank you. Best regards.
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Rafael. I added my opinion below. 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki : > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote: >> Hi, Lv Zheng. >> >> I added my handcrafted ACPI table under your request, because >> "acpidump -c on" and "acpidump -c off" doesn't work. >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han : >> > Hello, >> > >> > I attached the test results below, >> > >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki : >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> Hi, >> >>> >> >>> > From: linux-acpi-ow...@vger.kernel.org >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >> >>> > Han >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >> >>> > >> >>> > I'm Seunghun Han, and I work for National Security Research Institute >> >>> > of >> >>> > South Korea. >> >>> > >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI >> >>> > table >> >>> > for my research. >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel >> >>> > while boot >> >>> > process, and Linux kernel goes well without critical problems. >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >> >>> > >> >>> > Boot log of ACPI operand cache leak is as follows: >> >>> > >[0.174332] ACPI: Added _OSI(Module Device) >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install >> >>> > >System Control Interrupt handler >> >>> > (20160930/evevent-131) >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler >> >>> > >(20160930/evmisc-281) >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has >> >>> > >objects >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, >> >>> > >BIOS VirtualBox 12/01/2006 >> >>> > >[0.188000] Call Trace: >> >>> > >[0.188000] ? dump_stack+0x5c/0x7d >> >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >> >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >> >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >> >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >> >>> > >[0.188000] ? acpi_terminate+0x5/0xf >> >>> > >[0.188000] ? acpi_init+0x288/0x32e >> >>> > >[0.188000] ? __class_create+0x4c/0x80 >> >>> > >[0.188000] ? video_setup+0x7a/0x7a >> >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >> >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >> >>> > >[0.188000] ? rest_init+0x80/0x80 >> >>> > >[0.188000] ? kernel_init+0xa/0x100 >> >>> > >[0.188000] ? ret_from_fork+0x25/0x30 >> >>> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error. >> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c >> >>> on" and "acpidump -c off" output? >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux. >> Here are raw dumps of table. > > So, excuse me, but what's the security issue here? > > You hacked your ACPI tables into pieces which requires root privileges anyway. > > Thanks, > Rafael > As you mentioned earlier, I hacked my ACPI table for research, so it seems that it is not a security issue. But, if new mainboard are released and they have a vendor-specific ACPI table which has invalid data, the old version of kernel (<=4.9) will possibly expose kernel address and KASLR will be neutralized unintentionally. I know the vendors collaborate with Linux kernel developers, but the problem can still occur. Hardware vendors release so many kinds of mainboard in a year, and the major Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time. For this reason, I think this issue has a security aspect. Thank you. Best regards.
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Lv Zheng. I added my handcrafted ACPI table under your request, because "acpidump -c on" and "acpidump -c off" doesn't work. 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>: > Hello, > > I attached the test results below, > > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>: >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >>> Hi, >>> >>> > From: linux-acpi-ow...@vger.kernel.org >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >>> > Han >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >>> > >>> > I'm Seunghun Han, and I work for National Security Research Institute of >>> > South Korea. >>> > >>> > I have been doing a research on ACPI and making a handcrafted ACPI table >>> > for my research. >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while >>> > boot >>> > process, and Linux kernel goes well without critical problems. >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >>> > >>> > Boot log of ACPI operand cache leak is as follows: >>> > >[0.174332] ACPI: Added _OSI(Module Device) >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System >>> > >Control Interrupt handler >>> > (20160930/evevent-131) >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >>> > >[0.181125] ACPI Error: Could not remove SCI handler >>> > >(20160930/evmisc-281) >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has >>> > >objects >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >>> > >VirtualBox 12/01/2006 >>> > >[0.188000] Call Trace: >>> > >[0.188000] ? dump_stack+0x5c/0x7d >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >>> > >[0.188000] ? acpi_terminate+0x5/0xf >>> > >[0.188000] ? acpi_init+0x288/0x32e >>> > >[0.188000] ? __class_create+0x4c/0x80 >>> > >[0.188000] ? video_setup+0x7a/0x7a >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >>> > >[0.188000] ? rest_init+0x80/0x80 >>> > >[0.188000] ? kernel_init+0xa/0x100 >>> > >[0.188000] ? ret_from_fork+0x25/0x30 >>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error. >>> So could you send us the handcrafted ACPI table or both the "acpidump -c >>> on" and "acpidump -c off" output? I modified FACP, FACS, APIC table in VirtualBox for Linux. Here are raw dumps of table. [0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX VBOXFACP 0001 ASL 0061) [0.00] FACP DUMP [0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20 [0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20 [0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41 [0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00 [0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00 [0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00 [0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00 [0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00 [0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF [0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00 [0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02 [0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01 [0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00F0: 00 00 0
Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
Hi, Lv Zheng. I added my handcrafted ACPI table under your request, because "acpidump -c on" and "acpidump -c off" doesn't work. 2017-02-21 19:36 GMT+09:00 Seunghun Han : > Hello, > > I attached the test results below, > > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki : >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >>> Hi, >>> >>> > From: linux-acpi-ow...@vger.kernel.org >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun >>> > Han >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak >>> > >>> > I'm Seunghun Han, and I work for National Security Research Institute of >>> > South Korea. >>> > >>> > I have been doing a research on ACPI and making a handcrafted ACPI table >>> > for my research. >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while >>> > boot >>> > process, and Linux kernel goes well without critical problems. >>> > But I found some ACPI operand cache leaks in ACPI early abort cases. >>> > >>> > Boot log of ACPI operand cache leak is as follows: >>> > >[0.174332] ACPI: Added _OSI(Module Device) >>> > >[0.175504] ACPI: Added _OSI(Processor Device) >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device) >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System >>> > >Control Interrupt handler >>> > (20160930/evevent-131) >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter >>> > >[0.181125] ACPI Error: Could not remove SCI handler >>> > >(20160930/evmisc-281) >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has >>> > >objects >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >>> > >VirtualBox 12/01/2006 >>> > >[0.188000] Call Trace: >>> > >[0.188000] ? dump_stack+0x5c/0x7d >>> > >[0.188000] ? kmem_cache_destroy+0x224/0x230 >>> > >[0.188000] ? acpi_sleep_proc_init+0x22/0x22 >>> > >[0.188000] ? acpi_os_delete_cache+0xa/0xd >>> > >[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >>> > >[0.188000] ? acpi_terminate+0x5/0xf >>> > >[0.188000] ? acpi_init+0x288/0x32e >>> > >[0.188000] ? __class_create+0x4c/0x80 >>> > >[0.188000] ? video_setup+0x7a/0x7a >>> > >[0.188000] ? do_one_initcall+0x4e/0x1b0 >>> > >[0.188000] ? kernel_init_freeable+0x194/0x21a >>> > >[0.188000] ? rest_init+0x80/0x80 >>> > >[0.188000] ? kernel_init+0xa/0x100 >>> > >[0.188000] ? ret_from_fork+0x25/0x30 >>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error. >>> So could you send us the handcrafted ACPI table or both the "acpidump -c >>> on" and "acpidump -c off" output? I modified FACP, FACS, APIC table in VirtualBox for Linux. Here are raw dumps of table. [0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX VBOXFACP 0001 ASL 0061) [0.00] FACP DUMP [0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20 [0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20 [0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41 [0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00 [0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00 [0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00 [0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00 [0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00 [0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF [0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00 [0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02 [0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01 [0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.00] 0x00F0: 00 00 00 00 [0.00] ACPI: FACS 0xDFFF0200 000
[PATCH] x86: kernel: fix unused variable warning in vm86_32.c
If CONFIG_TRANSPARENT_HUGEPAGE is not set in kernel config, a warning is shown
in vm86_32.c.
The warning is as follows:
>arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
>arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’
>[-Wunused-variable]
> struct vm_area_struct *vma = find_vma(mm, 0xA);
The vma variable is used to call split_huge_pmd() macro function, but
split_huge_pmd() is defined as a null macro when CONFIG_TRANSPARENT_HUGEPAGE is
not set in kernel config. Therefore, the compiler shows an unused variable
warning.
To remove this warning, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
include/linux/huge_mm.h | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a3762d4..912a763 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -123,15 +123,12 @@ void deferred_split_huge_page(struct page *page);
void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page);
-#define split_huge_pmd(__vma, __pmd, __address)
\
- do {\
- pmd_t *pmd = (__pmd); \
- if (pmd_trans_huge(*pmd)\
- || pmd_devmap(*pmd))\
- __split_huge_pmd(__vma, __pmd, __address, \
- false, NULL); \
- } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long address)
+{
+ if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
+ __split_huge_pmd(vma, pmd, address, false, NULL);
+}
void split_huge_pmd_address(struct vm_area_struct *vma, unsigned long address,
bool freeze, struct page *page);
@@ -241,9 +238,8 @@ static inline int split_huge_page(struct page *page)
return 0;
}
static inline void deferred_split_huge_page(struct page *page) {}
-#define split_huge_pmd(__vma, __pmd, __address)\
- do { } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long address) {}
static inline void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page) {}
static inline void split_huge_pmd_address(struct vm_area_struct *vma,
--
2.1.4
[PATCH] x86: kernel: fix unused variable warning in vm86_32.c
If CONFIG_TRANSPARENT_HUGEPAGE is not set in kernel config, a warning is shown
in vm86_32.c.
The warning is as follows:
>arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
>arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’
>[-Wunused-variable]
> struct vm_area_struct *vma = find_vma(mm, 0xA);
The vma variable is used to call split_huge_pmd() macro function, but
split_huge_pmd() is defined as a null macro when CONFIG_TRANSPARENT_HUGEPAGE is
not set in kernel config. Therefore, the compiler shows an unused variable
warning.
To remove this warning, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.
Signed-off-by: Seunghun Han
---
include/linux/huge_mm.h | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a3762d4..912a763 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -123,15 +123,12 @@ void deferred_split_huge_page(struct page *page);
void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page);
-#define split_huge_pmd(__vma, __pmd, __address)
\
- do {\
- pmd_t *pmd = (__pmd); \
- if (pmd_trans_huge(*pmd)\
- || pmd_devmap(*pmd))\
- __split_huge_pmd(__vma, __pmd, __address, \
- false, NULL); \
- } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long address)
+{
+ if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
+ __split_huge_pmd(vma, pmd, address, false, NULL);
+}
void split_huge_pmd_address(struct vm_area_struct *vma, unsigned long address,
bool freeze, struct page *page);
@@ -241,9 +238,8 @@ static inline int split_huge_page(struct page *page)
return 0;
}
static inline void deferred_split_huge_page(struct page *page) {}
-#define split_huge_pmd(__vma, __pmd, __address)\
- do { } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long address) {}
static inline void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page) {}
static inline void split_huge_pmd_address(struct vm_area_struct *vma,
--
2.1.4
[PATCH v2] acpi: acpica: fix acpi operand cache leak
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.
Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000] ? dump_stack+0x5c/0x7d
>[0.188000] ? kmem_cache_destroy+0x224/0x230
>[0.188000] ? acpi_sleep_proc_init+0x22/0x22
>[0.188000] ? acpi_os_delete_cache+0xa/0xd
>[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000] ? acpi_terminate+0x5/0xf
>[0.188000] ? acpi_init+0x288/0x32e
>[0.188000] ? __class_create+0x4c/0x80
>[0.188000] ? video_setup+0x7a/0x7a
>[0.188000] ? do_one_initcall+0x4e/0x1b0
>[0.188000] ? kernel_init_freeable+0x194/0x21a
>[0.188000] ? rest_init+0x80/0x80
>[0.188000] ? kernel_init+0xa/0x100
>[0.188000] ? ret_from_fork+0x25/0x30
When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function.
The function calls acpi_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).
But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.
This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.
To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.
I hope that this patch improves the security of Linux kernel.
Thank you.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
Changes since v1: move position of variables to remove compile warning.
drivers/acpi/acpica/nsutils.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..943702d 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -594,25 +594,20 @@ struct acpi_namespace_node
*acpi_ns_validate_handle(acpi_handle handle)
void acpi_ns_terminate(void)
{
acpi_status status;
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
ACPI_FUNCTION_TRACE(ns_terminate);
-#ifdef ACPI_EXEC_APP
- {
- union acpi_operand_object *prev;
- union acpi_operand_object *next;
+ /* Delete any module-level code blocks */
- /* Delete any module-level code blocks */
-
- next = acpi_gbl_module_code_list;
- while (next) {
- prev = next;
- next = next->method.mutex;
- prev->method.mutex = NULL; /* Clear the Mutex
(cheated) field */
- acpi_ut_remove_reference(prev);
- }
+ next = acpi_gbl_module_code_list;
+ while (next) {
+ prev = next;
+ next = next->method.mutex;
+ prev->method.mutex = NULL; /* Clear the Mutex (cheated)
field */
+ acpi_ut_remove_reference(prev);
}
-#endif
/*
* Free the entire namespace -- all nodes and all objects
--
2.1.4
[PATCH v2] acpi: acpica: fix acpi operand cache leak
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.
Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000] ? dump_stack+0x5c/0x7d
>[0.188000] ? kmem_cache_destroy+0x224/0x230
>[0.188000] ? acpi_sleep_proc_init+0x22/0x22
>[0.188000] ? acpi_os_delete_cache+0xa/0xd
>[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000] ? acpi_terminate+0x5/0xf
>[0.188000] ? acpi_init+0x288/0x32e
>[0.188000] ? __class_create+0x4c/0x80
>[0.188000] ? video_setup+0x7a/0x7a
>[0.188000] ? do_one_initcall+0x4e/0x1b0
>[0.188000] ? kernel_init_freeable+0x194/0x21a
>[0.188000] ? rest_init+0x80/0x80
>[0.188000] ? kernel_init+0xa/0x100
>[0.188000] ? ret_from_fork+0x25/0x30
When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function.
The function calls acpi_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).
But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.
This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.
To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.
I hope that this patch improves the security of Linux kernel.
Thank you.
Signed-off-by: Seunghun Han
---
Changes since v1: move position of variables to remove compile warning.
drivers/acpi/acpica/nsutils.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..943702d 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -594,25 +594,20 @@ struct acpi_namespace_node
*acpi_ns_validate_handle(acpi_handle handle)
void acpi_ns_terminate(void)
{
acpi_status status;
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
ACPI_FUNCTION_TRACE(ns_terminate);
-#ifdef ACPI_EXEC_APP
- {
- union acpi_operand_object *prev;
- union acpi_operand_object *next;
+ /* Delete any module-level code blocks */
- /* Delete any module-level code blocks */
-
- next = acpi_gbl_module_code_list;
- while (next) {
- prev = next;
- next = next->method.mutex;
- prev->method.mutex = NULL; /* Clear the Mutex
(cheated) field */
- acpi_ut_remove_reference(prev);
- }
+ next = acpi_gbl_module_code_list;
+ while (next) {
+ prev = next;
+ next = next->method.mutex;
+ prev->method.mutex = NULL; /* Clear the Mutex (cheated)
field */
+ acpi_ut_remove_reference(prev);
}
-#endif
/*
* Free the entire namespace -- all nodes and all objects
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.
Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000] ? dump_stack+0x5c/0x7d
>[0.188000] ? kmem_cache_destroy+0x224/0x230
>[0.188000] ? acpi_sleep_proc_init+0x22/0x22
>[0.188000] ? acpi_os_delete_cache+0xa/0xd
>[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000] ? acpi_terminate+0x5/0xf
>[0.188000] ? acpi_init+0x288/0x32e
>[0.188000] ? __class_create+0x4c/0x80
>[0.188000] ? video_setup+0x7a/0x7a
>[0.188000] ? do_one_initcall+0x4e/0x1b0
>[0.188000] ? kernel_init_freeable+0x194/0x21a
>[0.188000] ? rest_init+0x80/0x80
>[0.188000] ? kernel_init+0xa/0x100
>[0.188000] ? ret_from_fork+0x25/0x30
When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function.
The function calls acpi_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).
But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.
This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.
To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.
I hope that this patch improves the security of Linux kernel.
Thank you.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/nsutils.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..acb6099 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -597,22 +597,18 @@ void acpi_ns_terminate(void)
ACPI_FUNCTION_TRACE(ns_terminate);
-#ifdef ACPI_EXEC_APP
- {
- union acpi_operand_object *prev;
- union acpi_operand_object *next;
-
- /* Delete any module-level code blocks */
-
- next = acpi_gbl_module_code_list;
- while (next) {
- prev = next;
- next = next->method.mutex;
- prev->method.mutex = NULL; /* Clear the Mutex
(cheated) field */
- acpi_ut_remove_reference(prev);
- }
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
+
+ /* Delete any module-level code blocks */
+
+ next = acpi_gbl_module_code_list;
+ while (next) {
+ prev = next;
+ next = next->method.mutex;
+ prev->method.mutex = NULL; /* Clear the Mutex (cheated)
field */
+ acpi_ut_remove_reference(prev);
}
-#endif
/*
* Free the entire namespace -- all nodes and all objects
--
2.1.4
[PATCH] acpi: acpica: fix acpi operand cache leak
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.
Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000] ? dump_stack+0x5c/0x7d
>[0.188000] ? kmem_cache_destroy+0x224/0x230
>[0.188000] ? acpi_sleep_proc_init+0x22/0x22
>[0.188000] ? acpi_os_delete_cache+0xa/0xd
>[0.188000] ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000] ? acpi_terminate+0x5/0xf
>[0.188000] ? acpi_init+0x288/0x32e
>[0.188000] ? __class_create+0x4c/0x80
>[0.188000] ? video_setup+0x7a/0x7a
>[0.188000] ? do_one_initcall+0x4e/0x1b0
>[0.188000] ? kernel_init_freeable+0x194/0x21a
>[0.188000] ? rest_init+0x80/0x80
>[0.188000] ? kernel_init+0xa/0x100
>[0.188000] ? ret_from_fork+0x25/0x30
When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function.
The function calls acpi_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).
But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.
This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.
To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.
I hope that this patch improves the security of Linux kernel.
Thank you.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/nsutils.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..acb6099 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -597,22 +597,18 @@ void acpi_ns_terminate(void)
ACPI_FUNCTION_TRACE(ns_terminate);
-#ifdef ACPI_EXEC_APP
- {
- union acpi_operand_object *prev;
- union acpi_operand_object *next;
-
- /* Delete any module-level code blocks */
-
- next = acpi_gbl_module_code_list;
- while (next) {
- prev = next;
- next = next->method.mutex;
- prev->method.mutex = NULL; /* Clear the Mutex
(cheated) field */
- acpi_ut_remove_reference(prev);
- }
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
+
+ /* Delete any module-level code blocks */
+
+ next = acpi_gbl_module_code_list;
+ while (next) {
+ prev = next;
+ next = next->method.mutex;
+ prev->method.mutex = NULL; /* Clear the Mutex (cheated)
field */
+ acpi_ut_remove_reference(prev);
}
-#endif
/*
* Free the entire namespace -- all nodes and all objects
--
2.1.4
