> 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, y
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:
> > > 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 (whe
>
> 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/lk
> > 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 shoul
>
> 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'
>
> 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 buffe
ntersects 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
mmand
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 b
.
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
>
> 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
> 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
>
> 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 t
>
> > 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
&
>
> > 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
&
>
> 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
>
> > 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...@v
>
> 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 restor
>
> 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
> > 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:
> > > > >
> &
.
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
mmand
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
ntersects 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
>
> 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 g
>
> 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 th
> 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
>
> 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
>
> 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 conte
> > 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-
> > inte
>
> 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
>
> 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 mac
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 MSF
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 res
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_
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
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
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
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
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 acc
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
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
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_in
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 se
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
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(
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
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/ac
;= 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(+)
d
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(-)
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
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
>[
e, 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
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:
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:
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:
ght 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
>&g
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:
> [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
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. Wyso
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 :
>> >
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&quo
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 Rowaf
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 fil
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 wi
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 wi
65 matches
Mail list logo
